NEWS
ZigBee neue Version 1.4.4
-
@gelberlemmy sagte in ZigBee neue Version 1.4.4:
@asgothian so jetzt ist der Adapter wieder grün. Habe den Haken unter Einstellungen "Zigbee-herdsman Debug-Info " ausversehen gesetzt. Aber das der dann gar nicht mehr läuft ? Jetzt ist der Adapter wieder grün. Kann aber keine Geräte anmelden. Aus dem LOG werde ich nicht schlau.
zigbee.0 2021-02-24 21:33:01.283 debug (30770) sendTo "getBinding" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:33:01.282 debug (30770) getBinding result: [] zigbee.0 2021-02-24 21:33:01.244 debug (30770) sendTo "getExclude" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:33:01.236 debug (30770) getExclude result: [] zigbee.0 2021-02-24 21:33:01.111 debug (30770) sendTo "getDevices" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:33:01.111 debug (30770) getDevices result: [{"_id":"0x00124b00219fba18","icon":"img/unknown.png","paired":true,"info":{"type":"device","device":{"ID":1,"_type":"Coordinator","_ieeeAddr":"0x00124b00219fba18","_network zigbee.0 2021-02-24 21:33:01.098 debug (30770) sendTo "listUart" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:33:01.097 debug (30770) List of ports: [{"comName":"/dev/ttyACM0"},{"comName":"/dev/ttyACM1"},{"comName":"/dev/ttyUSB0"},{"comName":"/dev/ttyACM2"},{"comName":"/dev/ttyAMA0"}] zigbee.0 2021-02-24 21:33:01.047 debug (30770) sendTo "getMap" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:33:01.046 debug (30770) getMap result: {"lqis":[],"routing":[]} zigbee.0 2021-02-24 21:33:01.046 debug (30770) Get map succeeded [] zigbee.0 2021-02-24 21:33:01.046 debug (30770) Routing table succeeded for 'Coordinator' zigbee.0 2021-02-24 21:33:01.045 debug (30770) Routing for 'Coordinator': {"table":[]} zigbee.0 2021-02-24 21:33:01.038 debug (30770) LQI succeeded for 'Coordinator' zigbee.0 2021-02-24 21:33:01.037 debug (30770) sendTo "getGroups" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:33:01.036 debug (30770) getGroups result: {} zigbee.0 2021-02-24 21:33:01.035 debug (30770) sendTo "getCoordinatorInfo" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:33:01.034 debug (30770) getCoorinatorInfo result: {"installSource":"iobroker.zigbee@1.4.4","channel":"14","port":"/dev/ttyACM0","type":"zStack3x0","revision":20210120,"version":"2-1.2.7.1."} zigbee.0 2021-02-24 21:33:01.023 debug (30770) sendTo "getLibData" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:32:59.264 debug (30770) system.adapter.admin.0: logging true zigbee.0 2021-02-24 21:31:03.800 debug (30770) sendTo "getExclude" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:31:03.745 debug (30770) sendTo "getBinding" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:31:03.744 debug (30770) getBinding result: [] zigbee.0 2021-02-24 21:31:03.742 debug (30770) getExclude result: [] zigbee.0 2021-02-24 21:31:03.641 debug (30770) sendTo "listUart" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:31:03.640 debug (30770) List of ports: [{"comName":"/dev/ttyACM0"},{"comName":"/dev/ttyACM1"},{"comName":"/dev/ttyUSB0"},{"comName":"/dev/ttyACM2"},{"comName":"/dev/ttyAMA0"}] zigbee.0 2021-02-24 21:31:03.530 debug (30770) sendTo "getDevices" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:31:03.528 debug (30770) getDevices result: [{"_id":"0x00124b00219fba18","icon":"img/unknown.png","paired":true,"info":{"type":"device","device":{"ID":1,"_type":"Coordinator","_ieeeAddr":"0x00124b00219fba18","_networ zigbee.0 2021-02-24 21:31:03.505 debug (30770) sendTo "getMap" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:31:03.504 debug (30770) getMap result: {"lqis":[],"routing":[]} zigbee.0 2021-02-24 21:31:03.504 debug (30770) Get map succeeded [] zigbee.0 2021-02-24 21:31:03.503 debug (30770) Routing table succeeded for 'Coordinator' zigbee.0 2021-02-24 21:31:03.502 debug (30770) Routing for 'Coordinator': {"table":[]} zigbee.0 2021-02-24 21:31:03.496 debug (30770) LQI succeeded for 'Coordinator' zigbee.0 2021-02-24 21:31:03.494 debug (30770) sendTo "getGroups" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:31:03.493 debug (30770) getGroups result: {} zigbee.0 2021-02-24 21:31:03.493 debug (30770) sendTo "getCoordinatorInfo" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:31:03.492 debug (30770) getCoorinatorInfo result: {"installSource":"iobroker.zigbee@1.4.4","channel":"14","port":"/dev/ttyACM0","type":"zStack3x0","revision":20210120,"version":"2-1.2.7.1."} zigbee.0 2021-02-24 21:31:03.486 debug (30770) sendTo "getLibData" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:30:49.362 debug (30770) system.adapter.admin.0: logging false zigbee.0 2021-02-24 21:28:35.401 debug (30770) system.adapter.admin.0: logging true zigbee.0 2021-02-24 21:28:27.651 debug (30770) User stateChange zigbee.0.info.pairingMode {"val":false,"ack":false,"ts":1614198507640,"q":0,"from":"system.adapter.zigbee.0","user":"system.user.admin","lc":1614095083475} zigbee.0 2021-02-24 21:28:27.596 info (30770) Zigbee: stop joining zigbee.0 2021-02-24 21:27:27.809 debug (30770) system.adapter.admin.0: logging false zigbee.0 2021-02-24 21:27:26.333 debug (30770) sendTo "letsPairing" to system.adapter.admin.0 from system.adapter.zigbee.0: Start pairing! zigbee.0 2021-02-24 21:27:26.331 info (30770) Zigbee: allowing new devices to join. zigbee.0 2021-02-24 21:27:24.113 debug (30770) sendTo "getExclude" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:27:24.048 debug (30770) getExclude result: [] zigbee.0 2021-02-24 21:27:24.045 debug (30770) sendTo "getBinding" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:27:24.045 debug (30770) getBinding result: [] zigbee.0 2021-02-24 21:27:24.022 debug (30770) sendTo "listUart" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:27:24.021 debug (30770) List of ports: [{"comName":"/dev/ttyACM0"},{"comName":"/dev/ttyACM1"},{"comName":"/dev/ttyUSB0"},{"comName":"/dev/ttyACM2"},{"comName":"/dev/ttyAMA0"}] zigbee.0 2021-02-24 21:27:23.868 debug (30770) sendTo "getDevices" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:27:23.867 debug (30770) getDevices result: [{"_id":"0x00124b00219fba18","icon":"img/unknown.png","paired":true,"info":{"type":"device","device":{"ID":1,"_type":"Coordinator","_ieeeAddr":"0x00124b00219fba18","_networ zigbee.0 2021-02-24 21:27:23.833 debug (30770) sendTo "getMap" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:27:23.831 debug (30770) getMap result: {"lqis":[],"routing":[]} zigbee.0 2021-02-24 21:27:23.830 debug (30770) Get map succeeded [] zigbee.0 2021-02-24 21:27:23.829 debug (30770) Routing table succeeded for 'Coordinator' zigbee.0 2021-02-24 21:27:23.827 debug (30770) Routing for 'Coordinator': {"table":[]} zigbee.0 2021-02-24 21:27:23.812 debug (30770) LQI succeeded for 'Coordinator' zigbee.0 2021-02-24 21:27:23.808 debug (30770) sendTo "getGroups" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:27:23.807 debug (30770) getGroups result: {} zigbee.0 2021-02-24 21:27:23.805 debug (30770) sendTo "getCoordinatorInfo" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:27:23.803 debug (30770) getCoorinatorInfo result: {"installSource":"iobroker.zigbee@1.4.4","channel":"14","port":"/dev/ttyACM0","type":"zStack3x0","revision":20210120,"version":"2-1.2.7.1."} zigbee.0 2021-02-24 21:27:23.788 debug (30770) sendTo "getLibData" to system.adapter.admin.0 from system.adapter.zigbee.0 zigbee.0 2021-02-24 21:27:04.643 debug (30770) system.adapter.admin.0: logging true zigbee.0 2021-02-24 21:27:00.401 info (30770) Zigbee started zigbee.0 2021-02-24 21:27:00.399 info (30770) Currently no devices. zigbee.0 2021-02-24 21:27:00.391 info (30770) --> transmitPower : high zigbee.0 2021-02-24 21:27:00.390 info (30770) Unable to disable LED, unsupported function. zigbee.0 2021-02-24 21:27:00.388 debug (30770) Zigbee network parameters: {"panID":6562,"extendedPanID":"0xaddddfddcddddddc","channel":14} zigbee.0 2021-02-24 21:27:00.380 info (30770) Coordinator firmware version: {"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20210120}} zigbee.0 2021-02-24 21:27:00.379 debug (30770) zigbee-herdsman started zigbee.0 2021-02-24 21:26:58.607 debug (30770) Backup /opt/iobroker/iobroker-data/zigbee_0/backup_2021_02_24-21_26_57.tar.gz success zigbee.0 2021-02-24 21:26:58.595 info (30770) Installed Version: iobroker.zigbee@1.4.4 zigbee.0 2021-02-24 21:26:58.047 debug (30770) Starting zigbee-herdsman... zigbee.0 2021-02-24 21:26:58.045 info (30770) Starting Zigbee npm ... zigbee.0 2021-02-24 21:26:57.990 debug (30770) Using zigbee-herdsman with settings: {"network":{"panID":6562,"extendedPanID":[220,221,221,205,221,223,221,173],"channelList":[14],"networkKey":[1,3,5,7,9,11,13,15,0,2,4,6,8,10,12,13]},"datab zigbee.0 2021-02-24 21:26:57.944 info (30770) starting. Version 1.4.4 in /opt/iobroker/node_modules/iobroker.zigbee, node: v14.15.4, js-controller: 3.2.16 zigbee.0 2021-02-24 21:26:57.402 debug (30770) statesDB connected zigbee.0 2021-02-24 21:26:57.401 debug (30770) States connected to redis: 127.0.0.1:9000 zigbee.0 2021-02-24 21:26:57.362 debug (30770) States create User PubSub Client zigbee.0 2021-02-24 21:26:57.360 debug (30770) States create System PubSub Client zigbee.0 2021-02-24 21:26:57.287 debug (30770) Redis States: Use Redis connection: 127.0.0.1:9000 zigbee.0 2021-02-24 21:26:57.284 debug (30770) objectDB connected zigbee.0 2021-02-24 21:26:57.269 debug (30770) Objects connected to redis: 127.0.0.1:9001 zigbee.0 2021-02-24 21:26:57.039 debug (30770) Objects client initialize lua scripts zigbee.0 2021-02-24 21:26:57.037 debug (30770) Objects create User PubSub Client zigbee.0 2021-02-24 21:26:57.035 debug (30770) Objects create System PubSub Client zigbee.0 2021-02-24 21:26:56.928 debug (30770) Objects client ready ... initialize now zigbee.0 2021-02-24 21:26:56.747 debug (30770) Redis Objects: Use Redis connection: 127.0.0.1:9001 zigbee.0 2021-02-24 21:26:51.936 info (30389) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason zigbee.0 2021-02-24 21:26:51.934 info (30389) terminating zigbee.0 2021-02-24 21:26:51.596 info (30389) Zigbee: disabling joining new devices. zigbee.0 2021-02-24 21:26:51.594 info (30389) cleaned everything up... zigbee.0 2021-02-24 21:26:51.592 info (30389) Got terminate signal TERMINATE_YOURSELF zigbee.0 2021-02-24 21:32:59.264 debug (30770) system.adapter.admin.0: logging trueDanke für Euren Support André
Guten Morgen,
so nach ein paar Tests, habe Ich festgestellt, dass zum Teil ein anlernen nur noch mit dem einen Taster auf dem Cc26x2r1 funktioniert. How ever. Hat das jemand schon einmal gehabt. Nach dem anlernen kann ich die Geräte nur ab und an Steuern. Auch sind sie irgendwann ohne Verbindung. Wobei sie direkt neben dem Cc26x2r1. Auch passiert es gelegentlich, dass der ComPort belegt ist und der Adapter nicht funktioniert. Neues flashen des Cc26x2r1 hat auch nichts gebracht. Ich habe mich entschieden den Cc26x2r1 umzutauschen, da ich nicht glauben kann, das es woanders dran liegt. Grundeinstellung in dem Adapter sind jetzt ja recht einfach. Er hat ja am Anfang tadellos funktioniert. Auch Adapter Neuinstallation hatte nichts gebracht.@gelberlemmy stell mal den "channel":"14" auf 15..manche Geräte mögen die Sonderkanäle nicht..
zigbee hab ich, zwave auch, nuc's genauso und HA auch
-
@klassisch Gut.. ja.. und danke dir. Ich spiel mal etwas mit rum.. und berichte meine Erfahrungen.
Sonst versauen wir hier den Thread
-
@gelberlemmy stell mal den "channel":"14" auf 15..manche Geräte mögen die Sonderkanäle nicht..
@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.
-
@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.umgestiegen von Proxmox auf Unraid
-
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.@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.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
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.@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.
-
@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.
@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. -
@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.
@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?
-
@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.
@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.
-
@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.
@asgothian habe das soeben mal durchgeführt, jedoch finde ich keine "warn" Meldungen "ELEVATED ..."
umgestiegen von Proxmox auf Unraid
-
@asgothian habe das soeben mal durchgeführt, jedoch finde ich keine "warn" Meldungen "ELEVATED ..."
-
0x00158d0002fd50oder muss ich das "0x"weglassen?
Edit: ohne "0x" funktioniert es
zigbee.0 2021-03-02 19:01:22.821 warn (7934) ELEVATED publishToState: value generated 'true' from device 00158d0002fd50c5 for 'Time from last motion' zigbee.0 2021-03-02 19:01:22.821 warn (7934) ELEVATED publishToState: value generated 'true' from device 00158d0002fd50c5 for 'Occupancy' zigbee.0 2021-03-02 19:01:22.820 warn (7934) ELEVATED publishToState: message received '{"occupancy":true}' from device 00158d0002fd50c5 type 'RTCGQ11LM' zigbee.0 2021-03-02 19:01:22.811 warn (7934) ELEVATED publishToState: value generated '49' from device 00158d0002fd50c5 for 'Link quality' zigbee.0 2021-03-02 19:01:22.811 warn (7934) ELEVATED publishToState: message received '{"linkquality":49}' from device 00158d0002fd50c5 type 'RTCGQ11LM' zigbee.0 2021-03-02 19:01:22.803 warn (7934) ELEVATED publishToState: value generated '79' from device 00158d0002fd50c5 for 'Illuminance' zigbee.0 2021-03-02 19:01:22.802 warn (7934) ELEVATED publishToState: value generated 'true' from device 00158d0002fd50c5 for 'Time from last motion' zigbee.0 2021-03-02 19:01:22.801 warn (7934) ELEVATED publishToState: value generated 'true' from device 00158d0002fd50c5 for 'Occupancy' zigbee.0 2021-03-02 19:01:22.800 warn (7934) ELEVATED publishToState: message received '{"occupancy":true,"illuminance":79,"illuminance_lux":79}' from device 00158d0002fd50c5 type 'RTCGQ11LM' zigbee.0 2021-03-02 19:01:22.796 warn (7934) ELEVATED publishToState: value generated '47' from device 00158d0002fd50c5 for 'Link quality' zigbee.0 2021-03-02 19:01:22.795 warn (7934) ELEVATED publishToState: message received '{"linkquality":47}' from device 00158d0002fd50c5 type 'RTCGQ11LM' -
@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.
@asgothian sagte in ZigBee neue Version 1.4.4:
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.
Problem ist nicht speziell bei Rules, habe soeben auch mal mit nem Blockly getestet, da erfolgt ebenfalls die Ausgabe doppelt.
letzteres "oder der Wert sich geändert hat." ist ja eher contraproduktiv
umgestiegen von Proxmox auf Unraid
-
Hatte heute einen seltsamen Effekt: Beim Betrachten der Vernetzungskarte binkte ein Synfonisk rotary encoder ständig Dauerfeuer. Wie ein bubbling idiot.
Auch die Objekte wurden ständig aktualisiert.
Drehen am encode hat nichts geändert.
Nach Neustart des Adapters war Ruhe.
Im log habe ich nichts Verdächtiges gefunden. -
@asgothian sagte in ZigBee neue Version 1.4.4:
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.
Problem ist nicht speziell bei Rules, habe soeben auch mal mit nem Blockly getestet, da erfolgt ebenfalls die Ausgabe doppelt.
letzteres "oder der Wert sich geändert hat." ist ja eher contraproduktiv
@crunchip sagte in ZigBee neue Version 1.4.4:
letzteres "oder der Wert sich geändert hat." ist ja eher contraproduktiv
Nein, das ist notwendig. Es gibt durchaus zigbee Geräte die auf einem State mehrere Unterschiedliche Informationen ablegen, so das wenn überhaupt nur "gleiche" Meldungen nicht wiederholt werden sollten.
A.
Und ja, das 0x musste weg
A.
-
Hallo zusammen, ich hätte da vielleicht für den einen oder anderen eine merkwürdige Anfrage, ist es möglich die Farben der offline Geräte oder der Online Geräte auf der Netzwerkkarte zu ändern?
Hintergrund ist dabei das ich Farbenblind bin vor allem bei Grün und Rot. Ich sehe somit keine Unterschiede zwischen den Geräten die verfügbar und Geräte die nicht verfügbar sind.
Mfg
David -
Hallo zusammen, ich hätte da vielleicht für den einen oder anderen eine merkwürdige Anfrage, ist es möglich die Farben der offline Geräte oder der Online Geräte auf der Netzwerkkarte zu ändern?
Hintergrund ist dabei das ich Farbenblind bin vor allem bei Grün und Rot. Ich sehe somit keine Unterschiede zwischen den Geräten die verfügbar und Geräte die nicht verfügbar sind.
Mfg
David@david83 Machst du damit bitte einen Issue auf Github auf ?
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch.
Support us
419
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge