Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[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..

[bilberry]

Für die interessierten Mitlesenden möchte ich abschließend noch mal zusammenfassen:
Die eigentliche Ursache für das aufgetretene Phänomen hat @asgothian in diesem Post erläutert.

Hab dann recherchiert. Und tatsächlich:
Mein Nachbar auf der gegenüberliegenden Straßenseite hat auch ein Zigbee-Netzwerk und nutzt dafür den gleichen Sonoff-Stick mit Zigbee2MQTT im HA. Offensichtlich hatte er bereits vergleichbare Beobachtungen gemacht und auch ständig unbekannte Geräte auf seine "Blockliste" gesetzt. Bei einem Abgleich stellten wir amüsiert fest, dass ich seine und er meine Geräte ständig rauswerfen musste. 🤣

Wir haben uns dann auf neue IDs und Kanäle verständigt. Seit dem keine Probleme mehr.