cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany
-
Moin,
mal ne Frage: Bei mir häufen sich die Supportanfragen, ob man am Coordinator auch die IEEE Adresse ändern kann.
Ja, das kann man aber wieso?Die Leute sagen man müsste das machen, wenn man von nem anderen Coordinator (zstack) auf unseren Coordinator umziehen will - um das Neuanlernen zu vermeiden.
Meines wissens reicht es doch die gleiche PanID/ExtPanID zu haben mit der (unser) Coordinator läuft? Und wenn nicht, braucht man nur das NVRAM am Coordinator löschen damit die diecoordinator_backup.jsonzurückgespielt werden kann.Zur Info: Wir testen den Coordinator natürlich und da nehmen wir die default PanID. Wenn man eine andere nutzt musst man das NVRAM löschen.
https://docs.codm.de/zigbee/faq/#startup-failed-configuration-adapter-mismatchLieg ich hier fasch?
@arteck, du kannst doch sicher was dazu sagen.Gruß,
Patrik -
@pmayer sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Moin,
mal ne Frage: Bei mir häufen sich die Supportanfragen, ob man am Coordinator auch die IEEE Adresse ändern kann.
Ja, das kann man aber wieso?Die Leute sagen man müsste das machen, wenn man von nem anderen Coordinator (zstack) auf unseren Coordinator umziehen will - um das Neuanlernen zu vermeiden.
Meines wissens reicht es doch die gleiche PanID/ExtPanID zu haben mit der (unser) Coordinator läuft? Und wenn nicht, braucht man nur das NVRAM am Coordinator löschen damit die diecoordinator_backup.jsonzurückgespielt werden kann.Zur Info: Wir testen den Coordinator natürlich und da nehmen wir die default PanID. Wenn man eine andere nutzt musst man das NVRAM löschen.
https://docs.codm.de/zigbee/faq/#startup-failed-configuration-adapter-mismatchLieg ich hier fasch?
@arteck, du kannst doch sicher was dazu sagen.Gruß,
PatrikHallo Patrick,
du liegst da zum Teil falsch. Allerdings ist das ein "user" Problem.
Vorab - ich gehe fest davon aus das ihr nach eurem Test das NVRam löscht ?
Wenn die User die bisher im Adapter vorgesehene Standard-PanID (16x D) nicht umstellen, dann wird bei Koordinatoren die eine IEEE besitzen deren IEEE als ExtPanID genutzt (abweichend von der Konfiguration). Das bedeutet das sich dann im NVRam (auf dem Koordinator sowie auf der Sicherung im Adapter) eine andere ExtPanID befindet als in der Adapter-Konfiguration angegeben ist. Da diese in dieser Situation Hardwarespezifisch ist kann das natürlich zu Problemen führen, insbesondere wenn man die Hardware austauschen will.
Die korrekte Gegenmassnahme ist das eintragen einer eigenen ExtPanID un der Adapter Konfiguration. Wenn Das Kind bereits im Brunnen ist - sprich der Adapter schon mit 16D und einem modernen Koordinator läuft - muss man die im NVRam eingetragene ExtPanID ermitteln und diese im Adapter eintrage. Das iobroker Diag Skript kann diese ausgeben. Auch ein Blick in die nvbackup.json zeigt diesen Wert.
Bei der (in Entwicklung befindlichen) 2.0 des Adapters wird der Adapter mit einer zufälligen Zeichenfolge vor-initialisiert, so das dieser Effekt weg sein sollte.
Insgesamt sehe ich nicht das es notwendig ist die Hardware IEEE des Koordinators umstellen zu können.
A.
-
Vielen Dank für deine detailierte Erklärung!!
Bin eher bei zigbee2mqtt zu Hause und da lief es immer ohne die IEEE neu zu schreiben.@asgothian sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Vorab - ich gehe fest davon aus das ihr nach eurem Test das NVRam löscht ?
Aktuell noch nicht. Wird aber bald kommen - wir müssen das noch in unser Testscript rein packen, damit über den Call aus dem Webinterface seit der 2.0er Firmware das NVRAM gelöscht wird.
Die IEEE unseres Coordinators kann mit dem ZigStar-GW-Multitool geändert werden. Die Kunden die ich im Support hatte haben sich aber, nachdem sie das NVRAM gelöscht haben, nie wieder gemeldet - weswegen ich davon ausgehe, dass es funktioniert hat.
Die meisten Kunden nutzen die default PanID wo es dann sowieso nicht zu Problemen kommt.Egal wie, wir müssen das NVRAM leeren nachdem wir getestet haben.
Danke dir!
Gruß,
Patrik -
@pmayer sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Aktuell noch nicht. Wird aber bald kommen - wir müssen das noch in unser Testscript rein packen, damit über den Call aus dem Webinterface seit der 2.0er Firmware das NVRAM gelöscht wird.
das hab ich schon vor Wochen aber auch bemängelt.. ich dachte das habt ihr durch....
-
@arteck sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
das hab ich schon vor Wochen aber auch bemängelt.. ich dachte das habt ihr durch....
Nein.... weil wir das mit dem 2.1er FW Update machen wollten und hier gerade zum Anfang des Jahres alle krank sind.
Die 2.1 FW ist ja auch noch nicht fertig....Wird zeitnah kommen
-
So,
NVRAM wird seit gestern nach unserem Funktionstest geleert.
Gruß,
p -
Wie kann ich eigentlich den Coordinator auf die neue Firmware aktualisieren, wenn dieser per USB direkt am Homeassistant angeschlossen und betrieben wird? In diesem Falle habe ich ja keine IP-Adresse und Zugriff auf das Webinterface?
-
@mf19862 Am ioBroker direkt nicht.
Du kannst ihn einfach per USB-C an den Computer anschließen und mit dem Webflasher die neue Firmware aufspielen: -
@mf19862 sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
In diesem Falle habe ich ja keine IP-Adresse und Zugriff auf das Webinterface?
und was hindert dich dazu.. den mal eben per LAN anzuschlissen ?
-
-
@mf19862 was hat das rine mit dem anderen zu tun?
zigbee läuft über USBdann kannst du doch auf das Webinterface des Coordinators unabhängig davon über LAN zugreifen!??
-
@homoran Genau das war ja meine Frage, ob mit dem aktivieren der USB-Schnittstelle (siehe https://docs.codm.de/zigbee/coordinator/#taster) die LAN-Schnittstelle deaktiviert wird bzw. die Kommunikation zum Gerät dann nur noch über USB läuft.
-
@mf19862 sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
@homoran Genau das war ja meine Frage, ob mit dem aktivieren der USB-Schnittstelle (siehe https://docs.codm.de/zigbee/coordinator/#taster) die LAN-Schnittstelle deaktiviert wird bzw. die Kommunikation zum Gerät dann nur noch über USB läuft.
du mischst schon wieder zwei Dinge
die Zigbee Kommunikation läuft weiter über USB, solange du nichts umkonfigurierst.
Das müsstest du im Webinterface machen.
Also kommst du da auch so drauf!
-
@homoran Ich habe den Coordinator lediglich mittels des Tasters auf den USB Modus umgestellt, auf dem Webinterface habe ich im Voraus nichts verstellt.
Es geht bei meiner Frage um die Kommunikation des Hosts-Systems und dem Coordinator (USB oder LAN). Aber so wie es scheint (danke für den Screenshot!), wechselt er das Interface.
Edit: Okay der Zugriff aufs Webinterface scheint möglich, auch wenn der USB Modus aktiv ist. Glaube ich habs jetzt verstanden. Danke für die Antworten
-
Hui,
hätte ich doch gestern mal hier reingeguckt
Also, mit dem USB-Modus - egal ob über Taster oder WebIf aktiviert - wird der ESP in einen Proxy-Modus geschaltet der den FTDI (USB-C) an TX/RX vom CC2652P7 über den ESP verbindet.
Das heißt der ESP läuft auch im USB-Modus komplett weiter. Das Webinterface funktioniert also auch weiterAnsonsten gäbe es natürlich auch noch die Mäglichkeit per USB den CC2652P7 zu flashen indem man den Knopf über 5 Sekunden hält. Damit wird der CC2652P7 in den Bootloater (BSL) gebracht und kann per USB geflasht werden (cc2538-bsl, zigstar multitool, etc.)
Siehe auch https://docs.codm.de/zigbee/coordinator/#taster
...aber es ging ja um die ESP-FirmwareGruß,
Patrik
