cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany

[Blockmove]

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

Ich würde mich unheimlich über euer Feedback freuen und natürlich über Fragen, Anregungen und allgemeinen Input.

Jetzt muss ich mal ein dickes Lob aussprechen.
Schnelle, problemlose Lieferung und anschließend eine einfache Inbetriebnahme dank ner guten Doku und einer sehr übersichtlichen Weboberfläche. Top!

Eine Anregung hätte ich:
Der Coordinator kommt bei mir in die Verteilung. Ein Adapter für die Hutschienenmontage des Gehäuses wäre schön

VG
Dieter

[pmayer]

@blockmove Vielen vielen Dank!

Hutschiene ginge in einer Metallverteilung aber dann nur mit Antenne mit Kabel.... wenn ich mal Zeit habe, designe ich mal was. Finde ich grundliegend aber eine gute Idee.

[Blockmove]

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

@blockmove Vielen vielen Dank!

Hutschiene ginge in einer Metallverteilung aber dann nur mit Antenne mit Kabel.... wenn ich mal Zeit habe, designe ich mal was. Finde ich grundliegend aber eine gute Idee.

Antennen habt ihr ja im Shop
Dann würde vielleicht noch ein 5V Hutschienennetzteil (Meanwell) und ein passendes Spannungsversorgungskabel dafür ins Shop-Sortiment passen.

[Fabio]

@pmayer ich habe ein paar Fragen.

Kannst du mir bitte erklären was NVRAM löschen bedeutet und was da passiert?
Was bedeutet Flash-Modus?
Was ist der Unterschied von der kleinen (Standard) und großen Antenne?
Habt ihr da Vorteile und Nachteile entdecken können?
Habt ihr ein Testsetup bei euch und wenn ja mit wieviel ZugBee Geräten?
Gibt es eine NVBACK Datei?

Herzliche Grüße
Fabio

[arteck]

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

Kannst du mir bitte erklären was NVRAM löschen bedeutet und was da passiert?

im NVRAM liegen die verbundenen Gerätedaten. damit der Coordinator weisst mit wem der quatschen darf (Verschlüsselung)
die Antenne ist wumpe.. Zigbee lebt von Routing.. wobei ist die zu gross kann zur Problemem führen die zwar der Coordinator die Geräte sieht aber die Geräte den coordinator nicht (sprichwort Sendeleistung)

der rest darf @pmayer beantworten

[Fabio]

@arteck vielen Dank und was passiert wenn ich den lösche?

Herzliche Grüße
Fabio

[arteck]

@fabio dann wird der wen die NVBACK datei exisiert wieder geladen.. das wird ehh immer nach neu flashen gemacht.
deshalb dauert der start nach dem flashen immer länger

ist die datei nicht da werden die adapter Einstellungen eingespielt..
und ab da kannst du alles neu anlernen

[Fabio]

@arteck dann lassen wir mal da die Finger von.

[pmayer]

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 die coordinator_backup.json zurü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-mismatch

Lieg ich hier fasch?
@arteck, du kannst doch sicher was dazu sagen.

Gruß,
Patrik

[Asgothian]

@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 die coordinator_backup.json zurü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-mismatch

Lieg ich hier fasch?
@arteck, du kannst doch sicher was dazu sagen.

Gruß,
Patrik

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

[pmayer]

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

[arteck]

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