Neues YouTube-Video: Visualisierung im Devices-Adapter

[Homoran]

@klassisch sagte:

Was ist denn derzeit ein guter, gängiger und zukunftssicherer Coordinator.

Läuft einfach immer rund

Updates über GUI, keine Probleme bisher.
Kann per LAN oder USB angeschlossen werden, stromanschluss über USB oder POE (optionale Ausstattung)

[BananaJoe]

Ich stelle bei mir gerade nach für nach um auf die Sonoff:

https://www.amazon.de/dp/B0FMJH4DPN

Ob die nun besser sind. Auf jeden Fall einfacher als was ich sonst so hatte

[Dan.Master]

Dazu melde ich mich auch mal.
Ich habe den Umzug von Sonoff Zigbee 3.0-P Stick auf einen SLZB-MR1 gemacht.
Zuerst sollte Zigbee umziehen und dann für später für die Zukunft noch Thread ( mit OTBR) an Board haben über zwei Antennen und zwei "eignen" Sendern. Derzeit aber noch kein Thread device kommt aber über kurz oder lang nochmal.
Der Umzug hat mit Hilfe des Videos von Simon42 perfekt geklappt. Alles in dem Video hier:
https://www.youtube.com/watch?v=7CvP5lnK-fI

Das einzige was ich machen musste sind ein paar Zigbee Geräte aus und wieder einschalten.
Alles wurde übernommen musste keine Skripte keine Geräte neu anlernen etc.
Also die SLZB Geräte kann man auch empfehlen.
Angebunden über Websocket von vorher serial.
Mein ganzes IOBroker Smarthome läuft auf Docker, daher musste man noch die Ports des SLZB auf die Zigbee2MQTT öffnen und dann läuft es. (Das braucht man ja nicht wenn man ohne Docker unterwegs ist.

Gruß
DerDani

[Asgothian]

@Dan.Master sagte:

Der Umzug hat mit Hilfe des Videos von Simon42 perfekt geklappt. Alles in dem Video hier:
https://www.youtube.com/watch?v=7CvP5lnK-fI

Dieses Video passt zum Original Thema nicht - es geht um den Umzug mit Zigbee2mqtt, während der OP den Zigbee Adapter im Einsatz hat.

Äpfel und Birnen.

A.

[klassisch]

Vielen Dank, @asgothian , @homoran , @BananaJoe, @dan.master
Derzeit nutze ich ja TI cc2652P Stick, den ich auf Eth umgefrickelt habe, weil es damals noch nichts Fertiges für LAN gab. Und die Sache läuft ja seit Jahren problemlos. Wenn das Wohnungslicht dran hängt, dann merkt man das. Jetzt schleiche ich halt vorsichtig auf dem Update Pfad.
@asgothian , @Homoran
Cod.M haben CC2652P7 Texas Instruments Multiprotokoll 2.4GHz Funkmodul. Klingt für mich vertraut und bewährt. Scheint ein Update des CC2652 zu sein. Ich erinnere mich noch, als TI um 2005 Chipcon aufgekauft und das HF-Transceiver Feld gepusht hat. Die wissen wohl was die tun.
Und ESP32 als Serial<-> LAN Converter wird wohl auch funktionieren und wird es auch ermöglichen, daß man zum Update nicht wieder (temporär) auf USB umstellen muß.

@BananaJoe
Die Sonoff haben EFR32MG24 als Zigbee-Chip. Welcher Hersteller steckt dahinter? Hat das Vor-/Nachteile im Vergleich zum TI

@Dan.Master
SLZB-MR1 basiert auf "CC2652P7 und EFR32MG21". Wieso haben die zwei ZigBee-Chips? Gibt das nicht ein Kuddelmuddel? Oder wie wird das gehandhabt?
Das referenzierte Vid bezieht sich auf Homeassistant und nicht auf ioBroker.

[Homoran]

@klassisch sagte:

Scheint ein Update des CC2652 zu sein

Ja!
Gibt von cod.m auch eine Firmwarevariante als Thread Border Router dazu.

Hab die Entwicklung allerdings aus den Augen verloren.

@klassisch sagte:

wird es auch ermöglichen, daß man zum Update nicht wieder (temporär) auf USB umstellen muß.

Definitiv!
Ich hab ganz zu Beginn einmal die Firmware manuell runterladen müssen um zu flashen, seitdem geht das auch automatisch in einem Zug.
Aber alles per LAN! Die Anbindung per USB hab ich noch nie benötigt

[Dan.Master]

@klassisch sagte:

@Dan.Master
SLZB-MR1 basiert auf "CC2652P7 und EFR32MG21". Wieso haben die zwei ZigBee-Chips? Gibt das nicht ein Kuddelmuddel? Oder wie wird das gehandhabt?
Das referenzierte Vid bezieht sich auf Homeassistant und nicht auf ioBroker.

Ja im Grunde könnten beide Zigbee der EFR32MG21 ist mit der SMLight OS für Matter over Thread. Also machst du mit dem CC das Zigbee Netzwerk und mit dem EFR das Matter over Thread. Da muss nur der Betriebsmodus "eingestellt" werden.

Sorry Ich bin wohl ein bisschen am Thema vorbei.
Bei dem Video geht es um HA aber das Umziehen von einem Stick auf den anderen habe ich so gemacht. Bin selber auch nur mit IO-Broker unterwegs.

Mir ging es um den Schwerpunkt wenn man was neues will geht das Easy.
Kauft man was neues:

• Dann was fertiges
• Über LAN sogar auch POE
• oder USB seriell
• Multiband Router (Zigbbe und Thread) auf 2 verschiedenen MCUs damit sich nichts in die quere kommt.

Gruß
DerDani

[Asgothian]

@klassisch sagte:

Die Sonoff haben EFR32MG24 als Zigbee-Chip. Welcher Hersteller steckt dahinter? Hat das Vor-/Nachteile im Vergleich zum TI

Der EFR ist von Silicon Labs - also auch einem Nahmhaften Hersteller.

Die Vor- und Nachteile sind letztendlich eher gering - die Firmware ist neuer, die Unterstützung des EFR im ZH / ZHC (der Basis auf der der Zigbee Adapter und Zigbee2MQTT mit der Hardware kommunizieren) ist noch nicht ganz so weit wie beim TI, aber das ist in Entwicklung.

In Deinem Fall relevant ist aber:

• Ein Umzug der database von einem TI Chip auf einen anderen TI Chip kann gehen sofern sich die Transportverschlüsselung nicht ändert.
• Ein Umzug von einem TI Chip auf einen EFR Chip geht ausschliesslich mit neuanlernen aller Geräte.

Ein Wichtiger Punkt noch zu den per Lan angebundenen Koordinatoren - diese haben oft intern ein NVRam, in dem sich ab Werk bereits eine ExtPanID befindet - es kann also zu problemen kommen wenn man nach meiner Anleitung den Wechsel von Koordinator A auf Koordinator B durchfürt. Um das stabil zu können muss der Koordinator die Option bieten das NVRam zu löschen. Der Cod.M tut das, bei den Sonoff und SLZB bin ich da unsicher.

Zum Thema Multiprotokoll: Ich persönlich nutze das lieber nicht. Wenn ich ein System haben will welches matter via Thread macht, dann nutze ich dafür lieber ein eigenes Gerät als einen 2. Chip in einem Gerät was parallel dazu das Zigbee Netz aufmacht. Das hat etwas mit redundanz und Querbeeinflussung zu tun. Dementsprechend würde ich die Liste von @dan.master so anpassen:

Kauft man was neues, dann:

• Was fertiges
• Anbindung via LAN, ggf. auch mit POE (sofern man POE hat)
• alternativ anbindung via USB
• Keine Multibandrouter mit 2 MCUs, um die Geräte zur Not auch örtlich getrennt betreiben zu können.

Nebenbei: Auch bei der Anbindung via LAN ist die eigentliche Kommunikation seriell ! Es also serielle kommunikation via USB ode seriell via LAN. Das ist auch der Grund dafür warum die Kommunikation zur Thread / Zigbee Firmware bei minimalen Netzproblemen gerne mal abbricht. Serielle Kommunikation über LAN reagiert extrem empfindlich auf Packetverlust oder out of order Packets, die bei Netzproblemen gerne mal auftreten.

A.

[klassisch]

@Asgothian sagte:

In Deinem Fall relevant ist aber:

• Ein Umzug der database von einem TI Chip auf einen anderen TI Chip kann gehen sofern sich die Transportverschlüsselung nicht ändert.
• Ein Umzug von einem TI Chip auf einen EFR Chip geht ausschliesslich mit neuanlernen aller Geräte.

Vielen Dank! Entscheidende Info.

Ein Wichtiger Punkt noch zu den per Lan angebundenen Koordinatoren - diese haben oft intern ein NVRam, in dem sich ab Werk bereits eine ExtPanID befindet - es kann also zu problemen kommen wenn man nach meiner Anleitung den Wechsel von Koordinator A auf Koordinator B durchfürt. Um das stabil zu können muss der Koordinator die Option bieten das NVRam zu löschen. Der Cod.M tut das, bei den Sonoff und SLZB bin ich da unsicher.

Auch das ein extrem wichtiger Punkt

Zum Thema Multiprotokoll: Ich persönlich nutze das lieber nicht. Wenn ich ein System haben will welches matter via Thread macht, dann nutze ich dafür lieber ein eigenes Gerät als einen 2. Chip in einem Gerät was parallel dazu das Zigbee Netz aufmacht.

Das handhabe ich auch so. Bei Systemen, die (asynchron) weiterentwickelt werden, halte ich eine Verschmelzung für zu früh. Bei Systemen, die einen stabilen Zustand erreicht haben und allenfalls synchron weiterentwickelt werden, kann man fusionieren.

... Liste von @dan.master so anpassen:

Kauft man was neues, dann:

• Was fertiges
• Anbindung via LAN, ggf. auch mit POE (sofern man POE hat)
• alternativ anbindung via USB
• Keine Multibandrouter mit 2 MCUs, um die Geräte zur Not auch örtlich getrennt betreiben zu können.

Vielen Dank an die Contributoren, schöne Liste

Nebenbei: Auch bei der Anbindung via LAN ist die eigentliche Kommunikation seriell ! Es also serielle kommunikation via USB oder seriell via LAN.

Ja, so habe ich die Teile ja auch umgebastelt. Den CH340 im Signalpfad durch LAN<->serial converter ersetzt. Kann das aber wieder fürs FW Update umstecken. Soweit ich mich erinnere, hatte das FW Update via LAN nicht funktioniert. Bei RFLink ist das auch so. Das habe ich auch umgebastelt, und das Update geht auch nicht via LAN.

Das ist auch der Grund dafür warum die Kommunikation zur Thread / Zigbee Firmware bei minimalen Netzproblemen gerne mal abbricht.
Serielle Kommunikation über LAN reagiert extrem empfindlich auf Packetverlust oder out of order Packets, die bei Netzproblemen gerne mal auftreten.

Ab und an habe ich kurze Verzögerungen, die aber auch auf eine verspätete Reaktion eines Bewegungsmelders zurückzuführen sein könnten.

Zwei oder dreimal im Jahr hängt der Coordinator und ich muß ihn kurz stromlos machen.
Meine sonstigen serial<-> LAN Converter (RFLInk, RS485-Modbus-Stromzähler, RS485-mME-Auslesung laufen aber immer durch).

Updates der Fritzbox können schon mal Überraschungen bringen. Auch bei meinem Zigbee-Netz. Vielleicht vorher den ioBroker runter fahren oder den ZigBee-Adapter pausieren?

[Meister Mopper]

@Asgothian sagte:

Das ist auch der Grund dafür warum die Kommunikation zur Thread / Zigbee Firmware bei minimalen Netzproblemen gerne mal abbricht. Serielle Kommunikation über LAN reagiert extrem empfindlich auf Packetverlust oder out of order Packets, die bei Netzproblemen gerne mal auftreten.

Weißt du, ob man da bei den Einstellungen der Schnittstelle (z. B. USR-TCPxxx) einen "Buffer" einbauen kann? Das Problem des Komminikationsverlusts habe ich nämlich auch.
Der Adapter geht nach mehreren Kontakt-Verlusten in die Knie und ich muss ihn stoppen, die Stromzufuhr zum Koordinator für 30 Sekunden kappen und danach den Adapter starten, dann funktioniert es wieder.

[klassisch]

@Meister-Mopper sagte:
Weißt du, ob man da bei den Einstellungen der Schnittstelle (z. B. USR-TCPxxx) einen "Buffer" einbauen kann?

Ich nutze einen Kanal des USR-TCP232-E2 und bei dem kann man keinen Buffer einstellen. Lediglich "Poll Timeaout", die bei mir auf 200ms steht.
Das könnte aber bei den Cod.M anders sein, den die nutzen ja einen ESP32 als serial<-> LAN Konverter. Vielleicht kann @homoran etwas dazu sagen? Ein NVM haben die bereits.

Das Problem des Komminikationsverlusts habe ich nämlich auch.

Bei mir läuft es seit Jahren recht stabil. Allerdings hängt das Teil auch direkt an der Fritte (weshalb PoE mir keinen Vorteil bringt).

[Homoran]

@klassisch sagte:

Vielleicht kann @homoran etwas dazu sagen

Leider nein 😢

Das müsste man @pmayer fragen.

[Asgothian]

@Meister-Mopper sagte:

Weißt du, ob man da bei den Einstellungen der Schnittstelle (z. B. USR-TCPxxx) einen "Buffer" einbauen kann? Das Problem des Komminikationsverlusts habe ich nämlich auch.
Der Adapter geht nach mehreren Kontakt-Verlusten in die Knie und ich muss ihn stoppen, die Stromzufuhr zum Koordinator für 30 Sekunden kappen und danach den Adapter starten, dann funktioniert es wieder.

Mir ist keine stelle bekannt wo man die Puffergrösse einstellen kann. Das ist aber auch eher kritisch, da die Puffergrösse auch auf das Zeitverhalten des Systems einfluss hat. Dazu kommt die Frage wie gross ein serielles Telegramm ist. Da muss man durchaus vorsichtig sein.

Generell ist aber immer ein Puffer dabei - eine serial via TCP Verbindung ohne Puffer ist auch bei gutem Netz nicht Stabil.

A.

[pmayer]

Öhm. Da müsst ihr mich kurz abholen. Worum geht es?

[BananaJoe]

@Asgothian sagte:

Ein Wichtiger Punkt noch zu den per Lan angebundenen Koordinatoren - diese haben oft intern ein NVRam, in dem sich ab Werk bereits eine ExtPanID befindet - es kann also zu problemen kommen wenn man nach meiner Anleitung den Wechsel von Koordinator A auf Koordinator B durchfürt. Um das stabil zu können muss der Koordinator die Option bieten das NVRam zu löschen. Der Cod.M tut das, bei den Sonoff und SLZB bin ich da unsicher.

Wäre das hier das passende beim Sonoff?

[Asgothian]

@BananaJoe sagte:

@Asgothian sagte:

Ein Wichtiger Punkt noch zu den per Lan angebundenen Koordinatoren - diese haben oft intern ein NVRam, in dem sich ab Werk bereits eine ExtPanID befindet - es kann also zu problemen kommen wenn man nach meiner Anleitung den Wechsel von Koordinator A auf Koordinator B durchfürt. Um das stabil zu können muss der Koordinator die Option bieten das NVRam zu löschen. Der Cod.M tut das, bei den Sonoff und SLZB bin ich da unsicher.

Wäre das hier das passende beim Sonoff?

Ja

[klassisch]

Habe jetzt die FW des Coordinators auf
Konfiguration nun
• type:ZStack3x0
• version:2-1.2.7.1.
• revision:20250321
upgedatet.
Jetzt sind aber wieder alle Namen gelöscht. Ist das normal?

[Asgothian]

@klassisch Eigentlich nicht. Wie hast du die Namen geändert ? Über das Zigbee UI oder im Objektbaum ? Auch - was steht in deiner localOverrides.json (liegt unter /opt/iobroker/iobroker-data/zigbee_0

A.

[klassisch]

Vielen Dank! Geändert habe ich im Objektbaum.
In den Overrides steht großteils die gelöschten Namen bzw. die types und nicht die von mir gegebenen Namen.

Was ist best practice, damit es persistent wird?

Edit: Ich sehe, daß die Overrides geändert werden, wenn ich die Namen in den Adapterkacheln ändere.
Aber nicht, wenn ich im Objektbaum ändere, was aber für mich besser funktioniert, weil die Reihenfolge mit der zuvor erzeugten Liste übereinstimmt.

[Asgothian]

@klassisch sagte:

Edit: Ich sehe, daß die Overrides geändert werden, wenn ich die Namen in den Adapterkacheln ändere.
Aber nicht, wenn ich im Objektbaum ändere, was aber für mich besser funktioniert, weil die Reihenfolge mit der zuvor erzeugten Liste übereinstimmt.

Das wird in der 3.5 erst wieder gehen - ich hab da an einzelnen Stellen Probleme wegen der Auto-Benennung aus den Converters.

Ist bekannt, und in Arbeit. Technisch einfach - die Logik klemmt etwas

A.