Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Asgothian]

@docsnyder7 sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:

@Asgothian OK... hat somit der cod.m als Standalone Coordinator eine merklich höhere Reichweite als der Conbee II?

Jein.

Durch eine bessere Platzierbarkeit und eine justierbare Antenne lässt er sich besser an die Umgebung anpassen als der Conbee mit seiner LP Antenne und USB Anschluss, der dann doch per Nabelschnur am Server hängt.

Ansonsten gilt: Reichweite hängt immer von beiden Teilehmern ab. Es bringt nix, wenn du auf der einen Seite einen 1000W Scheinwerfer benutzt, wenn die andere Seite mit einer 2 Watt Funzel zurück leuchtet.

A.

[pmayer]

So, dann grad noch ein Update hinterher. V2.1.0 mit folgenden (kleinen) Änderungen:

• Fixed project versioning: the last release should have been a minor update, not a patch.
• The power LED now remains permanently on in router mode.
• Fixed a bug where incorrect information was displayed during CC update.

Wichtigster Punkt: Die grüne LED blinkt nicht ständig im Routermodus.
Happy updating.

[Fabio]

@pmayer vielen Dank, 2.1.0 lief perfekt durch. ;-)
Herzliche Grüße

[Peter V.]

@pmayer sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:

Als nächstes steht dann Thread/Matter auf der Liste.

Ich bin schon länger stiller Mitleser, nutze bisher den Sonoff Dongle-E / Zigbee und bin damit ganz zufrieden, läuft.
Jetzt soll aber noch die Matter/Thread unterstützung dazu kommen, macht mich hellhörig.
Ich bin schon länger am überlegen, ob ich mir den OTBR antun soll, oder doch auf eine fertige Lösung hoffen kann.
Wenn ihr das zum laufen bekommt, habt ihr einen Anwender/Kunden/Käufer mehr.
Danke für eure Bemühungen.

[FredF]

@pmayer @asgothian
Ich habe den Zigbee Coordinator aus Dummheit zusätzlich bei HA integrieren wollen...
Seitdem habe ich diese Meldung

2025-12-18 22:34:01.607 - warn: zigbee.0 (83572) Network parameters in Config : panID=6754 channel=11 extendedPanID=d7b8aa1c004b1200
2025-12-18 22:34:01.608 - warn: zigbee.0 (83572) Network parameters on Coordinator: panID=65534 channel=0 extendedPanID=d7b8aa1c004b1200

und bekomme (klar) den Adapter nicht mehr grün.

Ich habe bereits das NVRAM über die Debug Konsole gelöscht.
Auch auf Werkseinstellung zu reseten habe ich schon versucht. (Edit: beim cod.m)

Den Zigbee Adapter v3.1.5 habe ich installiert.

Ich bin etwas ratlos...

Edit: Auch das NVRAM Backup über den Adapter zu löschen hat nicht geholfen
Edit2: Auf dem cod.m ist die Firmware V2.1.0

[peterfido]

Da hat HA wohl die panID auf 65534 und den Kanal auf 0 gesetzt. Vielleicht kann HA das auf 6754 und Kanel 11 zurückändern.

[Asgothian]

@FredF Was meldet er danach noch - sprich mit welcher Fehlermeldung verweigert er das aufbauen des Netzes ?

A.

[pmayer]

Kannst du sicherstellen, dass du irgendwo noch eine Verbindung hast?
Und ja, Log wäre wichtig.

[FredF]

@Asgothian @pmayer Hier der Log

2025-12-19 19:07:21.284 - warn: zigbee.0 (106550) Network parameters in Config : panID=6754 channel=11 extendedPanID=d7b8aa1c004b1200
2025-12-19 19:07:21.285 - warn: zigbee.0 (106550) Network parameters on Coordinator: panID=65534 channel=0 extendedPanID=d7b8aa1c004b1200
2025-12-19 19:07:21.306 - error: zigbee.0 (106550) Starting zigbee-herdsman problem : network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby (Error: AREQ - ZDO - stateChangeInd after 60000ms
at Object.start (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/waitress.ts:68:23)
at ZnpAdapterManager.beginCommissioning (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:362:31)
at processTicksAndRejections (node:internal/process/task_queues:105:5)
at ZnpAdapterManager.start (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:90:21)
at ZStackAdapter.start (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:155:16)
at Controller.start (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/controller.ts:133:29)
at ZigbeeController.start (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:220:28)
at Zigbee.doConnect (/opt/iobroker/node_modules/iobroker.zigbee/main.js:451:28))
2025-12-19 19:07:21.306 - error: zigbee.0 (106550) Failed to start Zigbee: no message given

[FredF]

@peterfido Leider nein, in HA kann ich nur den Kanal ändern

[Asgothian]

@FredF was du versuchen kannst:

• antenne des Koordinators (ggf. sogar den ganzen cod.m in Alufolie einwickeln. Sicherstellen das er keines deiner Geräte erreichen kann.
• Netzwerk starten. (Ohne gültiges NVBackup) Hoffen das es durch geht
• Netzwerk anhalten.
• nvBackup vom letzten Lauf vor dem Versuch mit HA widerherstellen
• Netzwerk starten - hoffen das es durch geht
• Wenn es durch geht, netzwerk anhalten, Alufolie von der Antenne nehmen, Netzwerk wieder starten.

Dann sollte es wieder laufen.

A.

[FredF]

@Asgothian Danke
Nach Punkt 2 Netzwerk starten wird der Adapter grün, schon mal gut.
Allerdings keine Geräte mehr, ok.

Wo bekomme ich das nvBackup vor dem HA Versuch her?

[Asgothian]

@FredF sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:

Wo bekomme ich das nvBackup vor dem HA Versuch her?

Na ja - ich war davon ausgegangen das du die Datei vor dem Löschen gesichert hast.

Hast du nicht ? - dann nicht gut.

Was du versuchen kannst:
der Adapter sichert die Dateien in einem internen Backup - jeweils beim erfolgreichen Start. Auf die kannst du mittels dieses Buttons in der Konfiguration der Version 3.3.0 zugreifen (
Da im Dateinamen des Backups der Zeitpunkt der Entstehung drin steht kannst du also das letzte backup vor deinem HA debakel versuchen zurück zu spielen.

Hast du nicht Adapter 3.3.0 - dann musst du da manuell ran - die Dateien liegen im gleichen Verzeichnis wie die shepherd.db. Es sind .tgz dateien. via tar -xzf <dateiname> kannst du die in dem verzeichnis auspacken wo du den Befehl absetzt (linux/macos only - keine Ahnung wie das bei windows ist)

A.

Nachtrag:

@FredF sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:

Allerdings keine Geräte mehr, ok.

Was hast du denn alles gelöscht als es nicht ging ?
A.

[FredF]

@Asgothian
Läuft wieder.
Nachdem der Adapter Grün geworden ist und alle Geräte weg waren, habe ich ein Restore vom letzten Backup vor dem HA Fehler gemacht.
Deine Antwort kam parallel.
Vielen Dank für deine Hilfe.

[FredF]

@pmayer
Was mich noch wundert ist, dass das löschen des NVRAMs über die Konsole "anscheinend" nicht funktioniert hat.

Oder unterliege ich einem Irrtum?

[Asgothian]

Na ja - wenn der Adapter ein nvram backup hat, und erkennt das im nvram nix drin steht, dann schiebt er das da rein - deswegen dauert bei sowas der erste start auch etwas länger.

[pmayer]

@FredF Die Config.json liegt im Dateisystem. Der kleinste Block ist 8kb - das passt so.

NVRAM ist im CC2652P7. Das hat nichts mit dem Dateisystem des Coordinators (ESP32) zu tun,

[arteck]

hat sich erledigt

[MartinP]

Zur Frage der Antennenqualität auf beiden Seiten einer Strecke zwischen Koordinator und Endgerät und die Auswirkungen noch eine Anmerkung: Die bessere Qualität der Antenne wirkt sich, wenn man sich an die Regularien hält eher auf der Empfangsseite des Koordinators aus. Da sorgt der Antennengewinn dafür, dass über die Antennenbuchse ein stärkeres Signal vom Endgerät hereinkommt.

In Senderichtung muss der Koordinator an seiner Antennenbuchse die HF Leistung entsprechend dem Antennengewinn abschwächen, um nicht eine EIRP (Äquivalent Rundstrahlerleistung) zu erreichen, die über dem Erlaubten liegt.

Aber auch da gilt, wo kein Kläger, da kein Richter.

Es ist noch niemand wegen Frixtender Antennen an der Fritzbox, oder einer Stummelantenne an seiner ESP32 CAM belangt worden.

[pmayer]

@FredF Anscheinend hab ich da gestern zu schnell geantwortet.
Eventuell ist das ein Bug, dass der Status des NVRAM nach dem leeren nicht korrekt ausgelesen wird.
Ich hab mal ein Ticket aufgemacht.