Ist großes Zigbee Update von 1.9.5 auf 3 riskant?
-
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.
-
Ja, anschließend den Adapter neu gestartet. Der Adapter hat dann alles eingelesen und etwaige Änderungen, die ich danach in den Kacheln vorgenommen habe, wieder schön in die Overrides eingepflegt. So gesehen sieht das aus meiner Laiensicht gut aus.
Was wohl auch funktioniert hätte:
- Ändern im Objektbaum -> Die Änderungen werden in den Kacheln angezeigt
- Kacheln öffnen -> "Edit" Bearbeitung öffnen
- im Kacheleditor speichern. Dann ändert der Adapter auch die Overrides
-
@pmayer Alles gut.
Es geht darum das die serielle Verbindung über TCP/IP empfindlich darauf reagiert wenn es im TCP/IP zu Paketverlust oder 'out of order' Paketen kommt.
Dabei kam die Frage auf wie gross der Puffer ist, über den die in den TCP/IP Paketen beinhalteten Daten seriell an den Chip weiter geleitet werden, und ob man diese Grösse konfigurieren kann.
A.
-
Ah. Danke!
Das reagiert sehr empfindlich. Deswegen empfehlen wir nicht den Betrieb über WLAN.
Es gibt für ZigBee kein Protokoll zwischen Coordinator und zigbee-adapter. Da wird plain die serielle Verbindung auf TCP übersetzt.Mir schwebt schon seit längerem vor, da ein Protokoll zu implementieren. Es gab auch schon Anstengungen vor ein paar Jahren im Home Assistant Universum....
Wäre was für die Zukunft. Dann könnte man ZigBee auch über WLAN machen. -
Das passt zu meinen Erfahrungen. Ich habe an anderen Stellen negative Erfahrungen mit serieller Kommunikation via TCP/IP machen müssen - das hat im industirellen Umfeld am Ende nie sauber funktioniert weswegen die Firma bei der ich Arbeite davon Abstand genommen hat. 99.9% Stabilität reicht im industirellen Umfeld einfach nicht aus.
Aus meiner Sicht macht es leider wenig Sinn da ein Zwischen-protokoll zu etablieren nur um den Betrieb via WLan zu ermöglichen. Der Aufwand dafür ist signifikant, und ich gehe nicht davon aus das die Möglichkeit den Koordinator via WLan zu nutzen dazu führt das die Kunden einen höheren Preis akzeptieren. Ich habe regelmässig in Diskussionen feststellen müssen das lieber die billigste Hardware aus China bestellt wird als das man sich um Details wie vernünftigen Support, etc. Gedanken macht. Da kommt dann gerne die Aussage das wird doch sowieso alles in China hergestellt, warum soll ich dann die teurere Variante kaufen.
Das Risiko welches ich bei einem Zwischenprotokoll sehe ist das es letztendlich ja einen vollen seriellen Kommunikationszyklus zwischen Koordinator und Adapter abbilden muss. Da sind aber Grössen, Zeitverhalten und Latenzen schon interessant. Wobei ich halt auch skeptisch bin ob man damit wirklich alle Instabilitäten heraus bekommt.
A.
-
Bin ich bei dir. Aber genaugenommen muss nur ein Layer dazwischen. Finde das in Python von Home Assistant gerade nicht. Aber es gibt schon Grundlagen.
Tasmota macht das über MQTT... da wandert aber die komplette Hostapplikation auf den ESP. Unser CZC wird dort auch schon untertstützt.
Damit hat man das Problem, falls man es denn hat, auch gelöst aber eben weniger ZigBee Hardware, die unterstützt wird.Und ja... dass Leute sagen: "Geht doch schon viel günstiger" sehe ich oft genug im WLED Umfeld.
Bin ich auch hier (https://forum.iobroker.net/topic/84526/wled-grundlagen-von-smarterkram-olli-erklärt-von-mir) drauf eingengangen.
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 Anmelden567
Online32.9k
Benutzer83.2k
Themen1.3m
Beiträge