Ist großes Zigbee Update von 1.9.5 auf 3 riskant?
-
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.@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).
-
@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).
-
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.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.
-
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.
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?
ioBroker@Ubuntu 24.04 LTS (VMware) für: >260 Geräte, 5 Switche, 7 AP, 10 IP-Cam, 1 NAS 42TB, 1 ESXi 15TB, 4 Proxmox 1TB, 1 Hyper-V 48TB, 14 x Echo, 5x FireTV, 5 x Tablett/Handy VIS || >=160 Tasmota/Shelly || >=95 ZigBee || PV 8.1kW / Akku 14kWh || 2x USV APC 750W kaskadiert || Creality CR-10 SE 3D-Drucker
-
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?
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
-
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? -
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. -
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.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.
-
Das heißt, ich muß jetzt in den Kacheln ändern?
Objektbaum und overrides erledigt dann der Adapter? -
Ich habe jetzt mit Python die LocalOverrides aus meinen xls Daten generiert. Scheint so weit zu gehen.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden266
Online32.9k
Benutzer83.0k
Themen1.3m
Beiträge