ZigBee neue Version 1.4.4
-
@gelberlemmy USB Probleme kann man im Log gut erkennen...
schau dir mal vom booten an alle Meldungen mit dmesg an... da hab ich auch schon viele Fehler gefunden..
-
@klassisch Gut.. ja.. und danke dir. Ich spiel mal etwas mit rum.. und berichte meine Erfahrungen.
Sonst versauen wir hier den Thread
-
@ilovegym sagte in ZigBee neue Version 1.4.4:
@gelberlemmy USB Probleme kann man im Log gut erkennen...
schau dir mal vom booten an alle Meldungen mit dmesg an... da hab ich auch schon viele Fehler gefunden..
Super danke für den Tipp. Com Port Probleme schaue ich mir mal an. Aber all die anderen Probleme dürften da eventuell nicht von stammen, oder? Das teste ich noch einmal.
Sagt mal, wenn ich den Adapter Zigbee vorab lösche, werden alle Daten des Adapters im System auf meinem Raspi gelöscht? Würde dann alles komplett frisch aufsetzen wollen. -
@gelberlemmy nimm dir ne zweite SD Karte für das neu aufsetzen, so kannst du im Notfall nochmal zurück und nachschauen, wie die Konfig war, falls doch was ist.
System mit Node und iobroker ist ja schnell aufgesetzt.
Ja, wenn du die Instanz löschst, dann ist die Konfig auch weg. Mach dir Screenshots.
-
@ilovegym aktuell ist kein Gerät angemeldet, von daher alles gut. Ich glaube aufgrund der Grösse meines IObrkoer, werde ich mir ein Testsystem mit eigenem Pi aufsetzen bevor es dann in den Livebetrieb geht.
-
@ilovegym sagte in ZigBee neue Version 1.4.4:
wenn der erste ausfällt, dann wird beim ersten das Netzteil vom Strom getrennt, und beim zweiten das Netzteil mit Strom versorgt.
Vergiss den shutdown Befehl nicht.
-
@gelberlemmy stell mal den "channel":"14" auf 15..manche Geräte mögen die Sonderkanäle nicht..
-
@ilovegym das währe schon wenn ihr dafür einen neuen Beitrag eröffnen würdet
-
@arteck sagte in ZigBee neue Version 1.4.4:
@gelberlemmy stell mal den "channel":"14" auf 15..manche Geräte mögen die Sonderkanäle nicht..
Ich hatte schon ein zwei mal den Kanal gewechselt. Welcje sind denn die Sonderkanäle? Werde nächste Woche mir mal einen Abend gönnen und ganz in Ruhe noch einmal schauen. Können es auch Spannungsprobleme sein? Habe noch zwei andere USB Sticks (Zwave und Enocean) am Pi. Der Pi hat ein original Netzteil. Hatte ich immer ausgeschlossen, da der cc26x2r1 ja auch schon lief und ich ungern einen aktiven USB Hub nutzen möchte.
-
-
@thomas-braun alles klar. Ich bin gespannt was da so raus kommt. Danke für Euren Support
-
Frage in die Runde
Im Zusammenhang mit javascript Rules ist mir beim script aufgefallen, das der aquara BWM doppelt auslöst. Siehe
https://github.com/ioBroker/ioBroker.javascript/issues/783
Kann das jemand bestätigen oder liegt das am BWM.closed Rules: sayit falsche Ausgabe #783
-
@crunchip
Es ist denkbar das das seit einiger Zeit so ist. Hintergrund:Einige Aqara BWM verschlucken sich beim Aktualisieren der Helligkeit wenn Helligkeit und Bewegung "gleichzeitig" aktualisiert werden soll. Ob das auf der herdsman Seite oder auf der BWM Seite passiert ist (mir) dabei noch nicht klar. Aus diesem Grund hat es eine Anpassung gegeben das der BWM immer dann wenn der Wert für die Helligkeit aktualisiert wird auch eine Bewegung auslöst. Sollte der BWM den Du hast sich dabei nicht verschlucken bekäme der Zigbee Adapter die Nachricht "Bewegung erkannt" doppelt.
Wie kann man das (am einfachsten) nachweisen ?
- die aktuelle GitHub version des Zigbee Adapters installieren 1.4.5
- im State "zigbee.x.info.debugmessages" einen Teil der IEEE Adresse eines BWM eintragen
- Im log nach "warn" Meldungen "ELEVATED ..." Ausschau halten.
Der Eintrag in dem State wird als "filter" genutzt. Dabei wird der String zunächst an ';' in einzelne Einträge aufgespalten. In der Folge wird bei bestimmten Meldungen geschaut ob die IEEE Adresse des betroffenen Gerätes einen der Einträge beinhaltet. Wenn ja werden bestimmte Meldungen dieses Geräts als Warnung an das Log weiter reicht. Damit können die Nachrichten für ein einzelnes (oder auch eine Gruppe von) Device(s) überwacht werden ohne das Log mit den vollen Debug Meldungen des Adapters zu fluten.
A.
Nachtrag: Wenn dieses Verhalten für die Rules zu einem Problem wird kann darüber nachgedacht werden eine Entstellung im Zigbee-Adapter vorzusehen, bei der States nur dann aktualisiert werden wenn die letzte Aktualisierung mehr als x ms zurück liegt oder der Wert sich geändert hat.
-
@crunchip sagte in ZigBee neue Version 1.4.4:
Kann das jemand bestätigen
Ja, siehe auch jenen Beitrag Habe mir dafür einen debouncer gebaut.
-
@asgothian ok und danke für die Ausführliche Information.
Wie geschrieben, hab das gestern abend mit einem BWM , der am Schreibtisch steht, getestet. Daten geloggt und paar mal ne Bewegung ausgelöst. Auf die Helligkeit habe ich natürlich nicht geachtet.
Werde mir das heute Nachmittag ansehen. -
@asgothian sagte in ZigBee neue Version 1.4.4:
Aus diesem Grund hat es eine Anpassung gegeben das der BWM immer dann wenn der Wert für die Helligkeit aktualisiert wird auch eine Bewegung auslöst.
Bedeutet das, daß bei aktualisierter Helligkeit jetzt das Licht angeht, weil "Bewegung erkannt" vorgetäuscht wird?
-
@ilovegym sagte in ZigBee neue Version 1.4.4:
@klassisch stimmt, der andere Adapter ist die nächste Instanz, also stimmen die Pfade nicht mehr..
Gut, dann kommt Plan B dran
Ich clone den Raspi, lass den zweiten ausgeschaltet mit absolut gleicher Config wie der erste, wenn der erste ausfällt, dann wird beim ersten das Netzteil vom Strom getrennt, und beim zweiten das Netzteil mit Strom versorgt.
Somit startet der zweite dann mit gleichem Namen ( ok die Mac und IP ist anders..) und mit der gleichen instanz.Klar, die beiden sollten dann nebeneinander stehen, das ist von den Örtlichkeiten kein Problem.
Sorry das ich darauf erst jetzt antworte. Ich hatte viel um die Ohren weswegen das so lange gedauert hat.
Leider wirst Du mit deinem Plan B wahrscheinlich keinen Erfolg haben es sei denn du schiebst den Zigbee-Stick vom einen zum anderen System.
Hintergrund:
- Alle Teilnehmer im Zigbee Netzwerk kennen "ihren" Koordinator.
- In jedem Zigbee Netz darf es nur einen Koordinator geben
- in der shepherd.db ist die IEEE Addresses des Koordinators mit hinterlegt. Ich bin unsicher was passiert wenn ein baugleicher Koordinator mit einer anderen IEEE Adresse und dieser shepherd.db verwendet wird.
- Ein "neuer" Koordinator der versucht ein Zigbee Netz aufzumachen welches die gleiche Verschlüsselung wie ein bestehendes Netzwerk besitzt sollte die Kollision bemerken und das aufmachen des Netzes unterbinden. Das ist soweit ich das erinnere bei der Firmware für die "grossen" TI chips (CC2538, CC1352-P2 CC26X2R1) der Fall. Der CC2531 verifiziert das nachweislich NICHT. In einigen Fällen ist es gelungen das Netz wieder aufzubauen, allerdings war dabei die Hardware-ID des "neuen" Koordinators die gleiche wie die des alten - die identische hardware war neu geflasht worden.
- Ein Gerät welches das Zigbee Protokoll sauber implementiert wird den Austausch des Koordinators im bestehenden Netz nicht akzeptieren. Das ist zumindest bei den Hue Lampen die ich habe der Fall.
- Geräte die per "configure" an einen bestehenden Koordinator gebunden wurden und nicht bei jedem Start neu konfiguriert werden werden ihre Meldungen an die IEEE des alten Koordinators senden.
Insgesamt stellt sich das Thema "failover" bei Zigbee (leider) deutlich komplexer dar. Es reicht halt nicht die im ioBroker hinterlegte Konfiguration zu duplizieren.
A.
-
@asgothian Dankeschön!
Kein Thema, ist ja nix kritisches, sondern nur Gedankengänge, wie ich mein Produktives System mit bald mehr als 140 Zigbee devices irgendwie absichern könnte. Das zeigt, dass so ein Netzwerk doch ganz gut abgesichert ist.
-
@asgothian habe das soeben mal durchgeführt, jedoch finde ich keine "warn" Meldungen "ELEVATED ..."
-
@crunchip
Zeig mal wie du das in info.debugmessages eingetragen hast
