Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[BananaJoe]

@bilberry Also ich würde das mit den Nachbarn nicht ausschließen. Ich sehe auch oft diverse Geräte meiner Nachbarn, mindestens einer hat eine WLAN-Tasmotasteckdose die verzweifelt nach jemanden sucht der diese Konfiguriert.

Mein zweiter heißer Tipp: Ich habe hier eine ganze Eurobox die ich mit "Zigbee + RF" beschriftet habe und in der ich allen möglichen Spielkram lagere den ich gerade nicht benutze. Da meldet sich auch ab und zu was heraus obwohl ich da nicht bewusst Batterien eingelegt oder den Plastikstreifen entfernt hatte.
Und manchmal sind es Geräte die man nicht als solches Erkannt hätte. Die Stehlampe z.B. hat auch ZigBee.
TS0601 Geräte habe ich übrigens auch eine Menge, bei mir sind das aber Thermometer/Hygrometer, zumeist mit LCD-Display

[bilberry]

Ich danke Euch schon mal für die ausführlichen Tipps! Werde mich am Wochenende damit beschäftigen.

EDIT 06.12.2025: Habe soeben v3.2.5 installiert und anschließend die empfohlenen Schritte durchgeführt. Werde weiter beobachten.

[bilberry]

Heute auf frische Tat erwischt!
Schon wieder ein (angebliches) Heizungsthermostat:
ieee:0x28dba7fffe741692
nwk:27820 (0x6cac)
model:TRVZB

Ist sogar noch erreichbar und ich könnte es steuern. Nimmt Werte an. Sonst wurden die Geräte ja immer als offline angezeigt.

EDIT:
muss gestern reingekommen sein: am 15.12.2025 um 9:03 Uhr
zigbee.0.info.pairingMessage: New device joined '0x28dba7fffe741692' model TRVZB

Da war ich gar nicht zu Hause!

Mit den Angaben konnte ich auch mal das Log durchsuchen - ist zugleich der erste Zigbee-Eintrag des Tages:

Spoiler

2025-12-15 08:57:14.258 - error: zigbee.0 (666615) Unknown getDevStates:0x00124b002a1afe01: Model "Coordinator" not found for Device 0x00124b002a1afe01
2025-12-15 08:57:48.216 - warn: zigbee.0 (666615) Ignored interview for 'undefined' because the network is closed
2025-12-15 08:57:53.735 - warn: zigbee.0 (666615) Device '0x28dba7fffe741692' announced itself, trying to read its status
2025-12-15 08:58:48.364 - error: zigbee.0 (666615) Unknown resoveEntity0x28dba7fffe741692: Resolve Entity did not manage to find a mapped device for 0x28dba7fffe741692 of type undefined
2025-12-15 08:58:48.368 - error: zigbee.0 (666615) Failed to interview '0x28dba7fffe741692', device has not successfully been paired. Try again !!!!!!!!!!
2025-12-15 09:03:46.431 - warn: zigbee.0 (666615) Ignored interview for 'undefined' because the network is closed
2025-12-15 09:03:46.534 - warn: zigbee.0 (666615) Device '0x28dba7fffe741692' announced itself, trying to read its status
2025-12-15 09:03:50.917 - info: zigbee.0 (666615) Successfully interviewed '0x28dba7fffe741692', device has successfully been paired
2025-12-15 09:03:50.917 - info: zigbee.0 (666615) Device '0x28dba7fffe741692' is supported, identified as: SONOFF Zigbee thermostatic radiator valve (TRVZB)
2025-12-15 09:03:50.927 - info: zigbee.0 (666615) Configuring 0x28dba7fffe741692 TRVZB
2025-12-15 09:03:50.960 - info: zigbee.0 (666615) downloading https://www.zigbee2mqtt.io/images/devices/TRVZB.png to img/TRVZB.png
2025-12-15 09:03:51.423 - info: zigbee.0 (666615) downloaded https://www.zigbee2mqtt.io/images/devices/TRVZB.png to img/TRVZB.png.
2025-12-15 09:03:53.025 - warn: zigbee.0 (666615) State value for 28dba7fffe741692.timer_mode_target_temp has value "0" less than min "4".
2025-12-15 09:03:57.528 - info: zigbee.0 (666615) DeviceConfigure successful 0x28dba7fffe741692 TRVZB

[Asgothian]

• Hast du andere Sonoff Geräte im Zigbee Netz ? (Insbesondere Router) ?
• es ist schon auffällig das das Gerät trotz geschlossenem Netz dazu kommen konnte - da muss dem jemand die Verschlusselung 'gepetzt' haben.

Ich kann Dir eine Sonder-Version bauen, die Geräte die ein Interview bei geschlossenem Netz versuchen hart aus dem Netzwerk wirft - incl. force. Dauert aber bis zum Wochenende.

A.

[bilberry]

Hallo @asgothian, vielen Dank für Dein Angebot - das weiß ich sehr zu schätzen! Du machst bereits tolle Arbeit für die ganze Community. Bitte investiere nicht noch Zeit in eine Sonderlösung nur für mich allein.
Da ich offenbar der einzige mit vergleichbarem Phänomen bin, sollte ich die Ursache auch in meiner Umgebung finden und beheben.

Ich habe nur einen Router im Netz und bin mir inzwischen ziemlich sicher, dass die Fremdgeräte von Außerhalb kommen. Wahrscheinlich muss ich mich da auch an die eigene Nase fassen!
Die ExtPanID habe ich ziemlich sicher mal bei einem Netzumbau geändert. Bei PanID und TransportKey bin ich mir nicht so sicher. In der naiven Annahme, ich sei der einzige "Nerd" in meiner unmittelbaren Wohngegend, hab ich dem bislang wenig Beachtung geschenkt. Falls die wirklich noch auf Standard-Werten stehen, könnte sich das nun rächen und wäre eine plausible Erklärung.

Kannst Du mir bitte noch mal kurz erklären (oder Link schicken) für welche Funktion welcher der drei Schlüssel relevant ist? Möchte das gern besser verstehen.

[Asgothian]

Vielen Dank für das Verständnis - allerdings ist da ggf. ein generelles Problem, wesegen ich trotzdem darüber nachdenke die Option zum Ausschluss von solchen Geräten einzubauen.

Zum Thema Schlüssel - es gibt 3:

PanID - ein 16 bit Wert der ähnlich zur SSID von WLAN benutzt wird. Dieser wird zwischen allen Geräten im Netzwerk geteilt.
ExtPanID - ein 128 bit Wert der parallel zur PanID benutzt wird. Dieser wird oft von der Hardware-ID des Koordinators abgeleitet, so das nur die PanID 'user configurable' ausgeführt werden muss
Transport Key - ein 128 bit Wert, der die eigentliche Netzwerkverschlüsselung darstellt. Dieser war in der Anfangszeit des Adapters mit einem festen Wert vorgegeben und wurde eigentlich von niemandem angepasst. ich denke das hier auch für Deinen Fall der Schlüssel versteckt ist - offensichtlich war das TRV mit einem legacy Zigbee Netzwerk (Zigbee Adapter oder Zigbee2mqtt.io vor version 1.33) verbunden und hat damit die Verschlüsselung gespeichert. Damit kann das Gerät prinzipiell mit dem Netzwerk kommunizieren / die Netzwerknachrichten lesen. Das es in den Pairing modus geht und das an den Koordinator meldet ist aber entgegen der Spezifikation. Siehe auch hier: https://www.zigbee2mqtt.io/advanced/zigbee/03_secure_network.html

A.

[bilberry]

Hallo @asgothian

Brau'mal bitte dringed Deine Unterstützung bei Wiederaufbau.

@Asgothian sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:

Wenn das nicht hilft musst du das gesamte Netz neu aufbauen:

alle Geräte nacheinander aus dem Netz werfen bis es leer ist
Netz anhalten wie oben
Hard Reset durchführen (der 5. Button in der Button-Reihe)
eine neu PanID und extPanID vergeben
das Netz starten (wieder der Button mit dem Pfeil)
alles neu anlernen.

Hab nun alles gelöscht. Wenn ich das Netz anhalte, lässt sich der Reset-Button nicht anklicken. Ist das ein Fehler? Wie kann ich die PanID und extPanID vom Stick zurücksetzen?

[Asgothian]

Ist ein bug - einfach den Button bei gestarteten Netz nutzen - der Adapter sollte das Netz erst anhalten.

Ansonsten bei angehaltenem Netz via Dateisystem nvbackup und Shepherd.dB löschen.

A.

[bilberry]

Danke, hab mein Netz (weitestgehend) mit neuen IDs und Key wieder aufgebaut. Nun ist mir aber aufgefallen, dass in der nvbackup.json (/opt/iobroker/iobroker-data/zigbee_0/) immer noch Geräte stehen, die da nicht rein gehören. Manuelles rauslöschen hat nichts gebracht. Genauso wenig wie komplettes Löschen der Datei.
Offensichtlich wird die nvbackup.json immer neu angelegt, wenn das Netzwerk gestoppt wird. Aber wo kommen die Daten darin her und wie kann ich erzwingen, das meine manipulierte/bereinigte nvbackup.json eingelesen wird?

Haben die Buttons "NVRAM" damit was zu tun? Für was genau sind die gut? Wann benutzt man die für was genau? In der Doku hab ich das noch nicht gefunden

[bilberry]

@asgothian, kannst du mir bitte 'ne kurze Rückmeldung zu meinem letzten Post geben? Danke!

[Asgothian]

Sorry - das war mir durchgerutscht.

Abhängig was du für einen Koordinator hast wird auf dem Koordinator im NVRam etwas gespeichert. Das wird via NVBackup.json gesichert, damit man es auf einen anderen Koordinator übertragen kann. Allerdings hängt es dann vom Koordinator ab ob er das überschreiben lassen kann. So wies ich das bei Dir darstellt geht es bei Deinem nicht. Wenn es ein USB Koordinator ist, dann hilft es zumeist eine neue Firmware zu flashen (oder die alte nochmal) Dabei immer den Haken setzen das der Flash Speicher vollständig gelöscht wird.. Bei Lan-Koordinatoren ist die Sache komplizierter. Da kocht jeder sein eigenes Süppchen.

A.

[bilberry]

OK, danke dir @asgothian! Ich habe einen SONOFF Zigbee 3.0 USB Dongle P (mit CC2652P) So wie du das beschreibst verstehe ich es so:

• ich müsste die nvbackup.json von Hand bereinigen
• einen neu geflashten Koordinator einstecken
• dieser zieht der sich dann die "initiale Betankung" des NVRam aus der bereinigten nvbackup.json

Demnach holen sich die Koordinatoren immer nur einmal nvbackup.json? Aber was ist dann der Trigger dafür?

Ich will auf alle Fälle vermeiden, mein Netz noch mal neu aufzubauen. Bis alle Geräte wieder liefen, hat mich die letztem beiden Tage deutlich mehr Zeit gekostet als ich schon großzügig geschätzt hatte.

[Asgothian]

Zu 100%ig bin ich aktuell nicht sicher - da müsste ich tief im herdsman Code graben wie das genau verschachtelt ist.

Ich gehe aber davon aus das du mit dem Ablauf den du beschrieben hast sauber bist.

A.

[arteck]

@bilberry sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:

Demnach holen sich die Koordinatoren immer nur einmal nvbackup.json?

ja und bei jedem beenden des adapter wird diese neu geschrieben..

Aber was ist dann der Trigger dafür?

das nicht aufmachen des Netzwerks..

[bilberry]

Vielen Dank, @arteck, das hilft mir!
Noch mal eine Verständnisfrage hierzu an Dich: Du schriebst, "das Aufmachen des Netzwerks" triggert das Einlesen der nvbackup.json. Was genau ist unter "Aufmachen" in dem Zusammenhang zu verstehen? Der erfolgreiche Start des Adapters oder was einmaliges internes?
Es muss ja offenbar einen Unterschied geben, da mein Koordinator die nvbackup.json offenbar nicht (mehr) einliest, aber beim Stopp jedes Mal erstellt.

[Homoran]

@bilberry sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:

Du schriebst, "das Aufmachen des Netzwerks"

nein! er schrieb

@arteck sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:

das nicht aufmachen des Netzwerks..

[bilberry]

Au peinlich! Wer lesen kann… Danke.

[arteck]

Ein Zigbee Netzwerk ist immer da und funkt wenn mindestenst ein Router oder ein Coordinator oder beide da sind.
wenn nur ein Router da ist übernimmt er die Rolle des coordinators, du hannst das dann nur nicht steuern da dieser Teil fehlt dem Router, also muss ein Coordinator her.

wenn der Coordinator Einstellungen zum Netzwerk hat (egal welche) dann erstellt der herdsman (die Software) auch ein nvbackup.. die Software weiss nicht ob es das richtige Netzwerk ist oder nicht..