UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[martinschm]

@asgothian said in Tester für Zigbee Adapter 2.0.x gesucht:

@martinschm 'die' ist gut. 6 von 70 geräten. Gib denen Zeit.

A.

Wenn ich auf den Pairing Button klicke bekomme ich noch diese MEldung

Error: Failed to open the network: AssertionError [ERR_ASSERTION]: Cannot permit join for more than 254 seconds.
    at Controller.permitJoin (/opt/iobroker/node_modules/zigbee-herdsman/dist/controller/controller.js:245:39)
    at ZigbeeController.permitJoin (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:659:33)
    at Commands.letsPairing (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:217:31)
    at Commands.onMessage (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:63:34)
    at Zigbee.<anonymous> (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:20:48)
    at Zigbee.emit (node:events:530:35)
    at change (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/build/cjs/lib/adapter/adapter.js:7262:20)
    at Immediate._onImmediate (file:///opt/iobroker/node_modules/@iobroker/db-states-redis/build/esm/lib/states/statesInRedisClient.js:291:37)
    at process.processImmediate (node:internal/timers:483:21). undefined

[arteck]

@martinschm sagte in Tester für Zigbee Adapter 2.0.x gesucht:

@asgothian said in Tester für Zigbee Adapter 2.0.x gesucht:

@martinschm 'die' ist gut. 6 von 70 geräten. Gib denen Zeit.

A.

Wenn ich auf den Pairing Button klicke bekomme ich noch diese MEldung

Error: Failed to open the network: AssertionError [ERR_ASSERTION]: Cannot permit join for more than 254 seconds.
    at Controller.permitJoin (/opt/iobroker/node_modules/zigbee-herdsman/dist/controller/controller.js:245:39)
    at ZigbeeController.permitJoin (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:659:33)
    at Commands.letsPairing (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:217:31)
    at Commands.onMessage (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:63:34)
    at Zigbee.<anonymous> (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:20:48)
    at Zigbee.emit (node:events:530:35)
    at change (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/build/cjs/lib/adapter/adapter.js:7262:20)
    at Immediate._onImmediate (file:///opt/iobroker/node_modules/@iobroker/db-states-redis/build/esm/lib/states/statesInRedisClient.js:291:37)
    at process.processImmediate (node:internal/timers:483:21). undefined

im ernst... stell de timer auf 240.. dann läuft es

[Pedder007]

@asgothian + @arteck danke für das Update und die ganze Pflege die ihr hier am Adapter leistet!
Ich kann gut verstehen, dass ihr den Adapter mehr 'Standardisieren' (ZigBee-Herdsmann) wolltet.

Ich hatte das Update lange vor mir her geschoben, einfach aus Sorge, dass die Nacharbeit dann ggf. zu aufwändig wird (>100 Devices in meinem ZigBee Netz) - neben anderen (außerhalb ioBroker) Baustellen ;-)

Aber heute war's mal schön ruhig :last_quarter_moon_with_face:

Also noch ein letztes schnelles Backup und dann ran.
Was soll ich sagen: Perfekt gelaufen, oben die Änderungen / Vorgehensweise und neue Funktionalitäten super erklärt und die Nacharbeit war, danke größtenteils verwendeten Aliasen, überschaubar :+1:

Für anderer Nutzer; folgende Devices musste ich wegen veränderter Datenpunkte bei mir nacharbeiten:
IKEA E1524/E1810: https://www.zigbee2mqtt.io/devices/E1524_E1810.html
OSRAM AC0251100NJ/AC0251600NJ/AC0251700NJ: https://www.zigbee2mqtt.io/devices/AC0251100NJ_AC0251600NJ_AC0251700NJ.html
Aqara WXKG11LM: https://www.zigbee2mqtt.io/devices/WXKG11LM.html
Aqara WXCJKG13LM: https://www.zigbee2mqtt.io/devices/WXCJKG13LM.html
Xiaomi GZCGQ01LM: https://www.zigbee2mqtt.io/devices/GZCGQ01LM.html
Tuya LCZ030: https://www.zigbee2mqtt.io/devices/LCZ030.html

Bei einigen wenigen Aqara Öffnungssensoren standen in der ZigBee Übersicht wieder die Originalnamen, aber das war auch schnell erledigt.

Etwas mehr Arbeit waren meine Heimann Sirenen. Da bin ich nun zunächst wieder (per Blockly) auf die SendToDevice-Payload Funktion gegangen, da sich die Datenpunkte nicht mehr einfach so per Wertzuweisung ansprechen ließen. Aber die waren auch bei der Ersteinrichtung seiner Zeit schon etwas sperrig ;-)

Lampen und Plugs waren alle völlig unproblematisch :-)

Bei der Karte würde ich mir - ich glaube irgendwann schonmal angesprochen ;-) - noch wünschen, dass die Geräte, wenn man sie verschiebt, einfach an der entsprechenden Stelle bleiben und sich nicht sofort wieder verschieben wenn man den Partner anfasst.

Also nochmals Danke für die tolle Arbeit und schöne Feiertage :-)

[Asgothian]

@pedder007 um Thema Karte - mach Mal die Einstellungen auf - da gibts nen Punkt ‘deactivate physics’ oder ähnlich.

A.

[Pedder007]

@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:

mach Mal die Einstellungen auf - da gibts nen Punkt ‘deactivate physics’

Danke, jap, genau das meine ich, war ich nur nicht drauf gekommen, dass das damit gemeint ist ;-)
Aber: Leider ist das beim nächsten Öffnen (Neuladen der Seite) wieder alles weg, bzw. man fängt von vorne an, was bei >100 Devices auch keine Freude macht ;-)
Kann man dem Adapter beibringen das er sich die Einstellung und die ggf. selber angeordnete Karte merkt?
Ich frage lieber hier vorher nach, bevor ich da in Git was für aufmache :-)

[Asgothian]

@pedder007 nein. Ist auch nicht geplant. Die Karte und die Position der Geräte darauf wird automatisch erstellt und nicht gespeichert. Für eine nur als Momentaufnahme interessante Funktion ist der Aufwand viel zu how’s umzusetzen.

A.

Nachtrag: Du bist herzlich eingeladen das zu implementieren und als PR zur Verfügung zu stellen. Ansonsten wirst du ohne diese Funktion leben müssen

[Ro75]

Hallo. Ich bin immer noich auf der 1.10.3 und bisher auch alles OK. Allerdings muss ich nun handeln, da ja schon an der 3.x gearbeitet wird. Damit die Schere die weiter auseinander geht, muss ich nun.

Kurze Frage, für den Fall das es "schief" geht. Sichern sollte ich mir

aus /opt/iobroker/iobroker-data/zigbee_0

dev_names.json
shepherd.db

sowie die Adapterkonfiguration.

Damit sollte ein Notfall-Rücksprung möglich sein?

Ro75.

[Asgothian]

@ro75 am besten du sicherst das ganze Verzeichnis.

A.

[Ro75]

@asgothian Danke für die schnelle Antwort. Also praktisch das hier:

Ro75.

EDIT:

Das Update von der 1.10.3 auf die 2.0.5 verlief OHNE Probleme. Die Datenstruktur ist bis auf ein Gerät geblieben, also nur minimale Änderungen.

Nur hier muss ich die Auswertung ändern. Vielen Dank für die Entwicklung und dem Support. Ein schönes OSterwochenende.

Ro75.

[martinschm]

@arteck said in Tester für Zigbee Adapter 2.0.x gesucht:

@martinschm sagte in Tester für Zigbee Adapter 2.0.x gesucht:

@asgothian said in Tester für Zigbee Adapter 2.0.x gesucht:

@martinschm 'die' ist gut. 6 von 70 geräten. Gib denen Zeit.

A.

Wenn ich auf den Pairing Button klicke bekomme ich noch diese MEldung

Error: Failed to open the network: AssertionError [ERR_ASSERTION]: Cannot permit join for more than 254 seconds.
    at Controller.permitJoin (/opt/iobroker/node_modules/zigbee-herdsman/dist/controller/controller.js:245:39)
    at ZigbeeController.permitJoin (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:659:33)
    at Commands.letsPairing (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:217:31)
    at Commands.onMessage (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:63:34)
    at Zigbee.<anonymous> (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:20:48)
    at Zigbee.emit (node:events:530:35)
    at change (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/build/cjs/lib/adapter/adapter.js:7262:20)
    at Immediate._onImmediate (file:///opt/iobroker/node_modules/@iobroker/db-states-redis/build/esm/lib/states/statesInRedisClient.js:291:37)
    at process.processImmediate (node:internal/timers:483:21). undefined

im ernst... stell de timer auf 240.. dann läuft es

Ja im Ernst. Verstehe den Kommentar ehrlicherweise auch gar nicht.

Mir, wird an einer Stelle, an der dies bisher nicht auftrat eine für technische Laien kryptische Fehlermeldung gebraucht. Die hab ich hier gemeldet und nach einer Lösung gefragt.

Nicht mehr nicht weniger. Es war auch keine Kritik dabei oder eine Forderung nach einem sofortigen Fix.

Da stell ich mir im Ernst die Frage ob das der richtige Ton im Forum ist.

[Ro75]

@martinschm hast du denn den Wert geändert? Mit welchem Ergebnis?

Ro75.

[Homoran]

@martinschm sagte in Tester für Zigbee Adapter 2.0.x gesucht:

eine für technische Laien kryptische Fehlermeldung gebraucht.

meinst du die hier?

@martinschm sagte in Tester für Zigbee Adapter 2.0.x gesucht:

Cannot permit join for more than 254 seconds.

und die Antwort von @arteck

@arteck sagte in Tester für Zigbee Adapter 2.0.x gesucht:

stell de timer auf 240

zielt doch genau darauf ab.

bezieht sich auf deinen Screenshot https://forum.iobroker.net/post/1265206

Der die Ursache der Meldung zeigt

[Duffy]

Hat sich wie von Geisterhand erledigt. Deshalb gelöscht.

Sorry.

LG Duffy und frohe Ostern

[Ro75]

@duffy Schade warum gelöscht? Vielleicht dazugeschrieben was du gemacht hast, dass es plötzlich geht.

Ro75.

[Duffy]

@ro75

Ich weis ja nicht mal was ich gemacht habe.
Der Punkt was das bei meinem Lichtsensor keine Daten mehr kamen (Punkt war orange)
Es war auch kein anderer Punkt da.
Doch plötzlich war ein neuer Datenpunkt für Lux da, ich habe aber nichts gemacht, zumindest nicht wissentlich :-(

[Pedder007]

@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:

Nachtrag: Du bist herzlich eingeladen das zu implementieren und als PR zur Verfügung zu stellen. Ansonsten wirst du ohne diese Funktion leben müssen

Alles klar, danke für Deine Rückmeldung :-)
Da der Aufwand mich da überhaupt einzuarbeiten, bei meinen ganzen anderen Hobbies, zeitlich wahrscheinlich völlig überfordern würde (habe in meinem Leben ja nie professionell SW entwickelt und bin froh das es sowas wie Blockly gibt), werde ich dann wohl eher ohne leben ;-)

Bei der Gelegenheit aber evtl. ein anderer Punkt:
Wir oder ich mit @arteck (ich weiß es nicht mehr) hatten vor ca. 1-2 Jahren abends mal einen Discord Call zu irgendeinem Device. However, dabei fiel die Idee, es evtl. über den Adapter zu ermöglichen, Devices (z. B. einen Switch und eine Lampe) direkt miteinander zu koppeln. Ich hatte das damals so verstanden, dass man dann, bei einem Server/ioBroker-Ausfall, diese Funktion (Lampe an/aus) trotzdem noch nutzen könnte.
Ist da evtl. noch etwas geplant?

PS.
Ich hatte das gerade mal über die 'Binding' Funktion im Adapter probiert (mit einer TRADFRI remote control und einem SA-003-Zigbee Switch, bzw einem A1Z Plug), hat aber nicht geklappt. Da werden in der Auswahl jeweils auch nicht alle Datenpunkte, bzw. auch lange nicht alle Devices, angezeigt.

[Asgothian]

@pedder007 sagte in Tester für Zigbee Adapter 2.0.x gesucht:

Ich hatte das gerade mal über die 'Binding' Funktion im Adapter probiert (mit einer TRADFRI remote control und einem SA-003-Zigbee Switch, bzw einem A1Z Plug), hat aber nicht geklappt. Da werden in der Auswahl jeweils auch nicht alle Datenpunkte, bzw. auch lange nicht alle Devices, angezeigt.

Das könnte ein Bedienfehler gewesen sein. Binding ist genau die Lösung für das Problem. Allerdings geht Binding aktuell nur wenn bestimmte Cluster im Zigbee unterstützt werden. Man kann zwar über den Experten-Modus auch andere Bindings erstellen, das erfordert aber maximales Expertenwissen. Da das nicht 'mal eben' End-Nutzerfreundlich in einen Dialog giessbar.

Zeig doch mal das Log von dem Zeitraum wo du das Binding versucht hast.

A.

[Asgothian]

@pedder007 sagte in Tester für Zigbee Adapter 2.0.x gesucht:

Alles klar, danke für Deine Rückmeldung
Da der Aufwand mich da überhaupt einzuarbeiten, bei meinen ganzen anderen Hobbies, zeitlich wahrscheinlich völlig überfordern würde (habe in meinem Leben ja nie professionell SW entwickelt und bin froh das es sowas wie Blockly gibt), werde ich dann wohl eher ohne leben

Kann ich nachvollziehen. Geht mir in dem Fall aber ähnlich - ich müsste mich dafür ganz tief in eine externe Bibliothek einarbeiten, die diese Fähigkeit eigentlich nicht hat, und die dann da 'anflanschen'. Da steht Aufwand (für mich) in keinem Verhältnis zum Nutzen.

A.

[pk68]

Hallo, nach dem Update macht bei mir der Xiaomi Lichtsensor GZCGQ01LM Probleme.

Zunächst hat er das Log im Minutentakt vollgeschrieben:

2025-04-21 09:07:28.804 - info: zigbee.0 (12177) Configure on Message for 0x04cf8cdf3c7b59db
2025-04-21 09:07:28.805 - info: zigbee.0 (12177) Configuring 0x04cf8cdf3c7b59db GZCGQ01LM
2025-04-21 09:07:38.831 - info: zigbee.0 (12177) Timeout trying to configure 0x04cf8cdf3c7b59db GZCGQ01LM (-142).
2025-04-21 09:08:13.527 - info: zigbee.0 (12177) checking configure on message : next attempt in -4696 seconds
2025-04-21 09:08:13.527 - info: zigbee.0 (12177) Configure on Message for 0x04cf8cdf3c7b59db
2025-04-21 09:08:13.528 - info: zigbee.0 (12177) Configuring 0x04cf8cdf3c7b59db GZCGQ01LM
2025-04-21 09:08:23.550 - info: zigbee.0 (12177) Timeout trying to configure 0x04cf8cdf3c7b59db GZCGQ01LM (-143).
2025-04-21 09:08:28.438 - info: zigbee.0 (12177) checking configure on message : next attempt in 25112 seconds
2025-04-21 09:08:43.354 - info: zigbee.0 (12177) checking configure on message : next attempt in 10196 seconds
2025-04-21 09:09:23.115 - info: zigbee.0 (12177) checking configure on message : next attempt in -29565 seconds
2025-04-21 09:09:23.116 - info: zigbee.0 (12177) Configure on Message for 0x04cf8cdf3c7b59db

Ich habe es zunächst, wie oben beschrieben, mit Reconfigure probiert. Hat nicht funktioniert. Muss man dazu den Sensor in den Pairing Mode versetzen?

Danach habe ich den Sensor aus der Zigbee Konfig gelöscht (mit force) und neu angelernt:

2025-04-21 11:31:28.714 - info: zigbee.0 (12177) Opening zigbee Network for 240 seconds
2025-04-21 11:31:42.531 - info: zigbee.0 (12177) Starting interview of '0x04cf8cdf3c7b59db'
2025-04-21 11:31:43.189 - info: zigbee.0 (12177) Device '0x04cf8cdf3c7b59db' announced itself
2025-04-21 11:31:44.184 - info: zigbee.0 (12177) Successfully interviewed '0x04cf8cdf3c7b59db', device has successfully been paired
2025-04-21 11:31:44.184 - info: zigbee.0 (12177) Device '0x04cf8cdf3c7b59db' is supported, identified as: Xiaomi Mi light sensor (GZCGQ01LM)

Ergebnis: die interessanten Datenpunkte wie illuminance_raw werden nicht aktualisiert. Nur die Datenpunkte available = true, link_quality = 10 und msg_from_zigbee wurden beschrieben.

msg_from_zigbee enthält:

{"type":"commandQueryNextImageRequest","data":{"fieldControl":0,"manufacturerCode":4718,"imageType":9096,"fileVersion":21},"linkquality":57,"groupID":0,"cluster":"genOta","meta":{"zclTransactionSequenceNumber":5,"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0}},"endpoint_id":1}

Hat jemand einen Rat?

[Asgothian]

@pk68 Solange wie im msg_from_zigbee nur commandQueryNextImageRequest Messages auftauchen sendet das Gerät keine Daten auf 'normale' Art.

Dafür kann es mehrere Gründe geben. Diese Meldungen kommen nach dem neu Anlernen oft weil die ZHC versuchen festzustellen ob es eine neue Firmware gibt.

Als erstes würde ich abwarten und schauen ob es auch nachrichten mit anderem type unter msg_from_zigbee gibt.

Das Thema mit den configure-messages ist (leider) bekannt und wird erst in der 3.0 behoben sein. Es gibt einzelne Geräte die auf die Konfigurationsversuche nicht sauber reagieren und deswegen im Configure-on-Message subsystem fest stecken. Die übliche Gegenmassnahme ist ein manuelles wach-halten des Gerätes damit die Konfiguration sauber durch läuft. Das geschieht zumeist durch drücken des Knopfes der das Gerät bei langem Halten auch in den Pairing mode bringt.

A.