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

[Asgothian]

Auf Github ist die version 3.1.0 des Zigbee Adapters vorhanden. Dafür benötige ich freiwillige zum Testen. Da es eine massive Anpassung war gibt es durchaus ein Risiko von Abstürzen. Allerdings sind die Änderungen gegenüber 3.0.5 gering, so das ein zurückspielen der 3.0.5 immer gehen wird.

Installation via Github vom ioBroker repository.

Folgendes ist neu:
Synchronisation für Gruppen / Mitglieder

• Änderung eines Gruppen States (ack = false) => der Adapter versucht den Status der Mitglieder zu lesen. (Wichtig: Nur der in der Gruppe angepasste state wird gelesen - wichtig bei Gruppen von Leuchten, wenn via brightness eingeschaltet wird. (Hier kann es ggf. noch Timing-Probleme geben)

• Änderung eines Mitglieder States (ack = false) => der Adapter bewertet den Status aller Mitglieder und setzt den Gruppenstatus entsprechend (mit ack=true) Ansteuerung über den State stateupdate. Gültige Werte sind: 'off' - keine Synchronisation (default), 'mat' - match -> der Gruppenstatus ändert sich wenn alle Mitglieder den gleichen Status haben. 'avg' der Gruppenstatus wird auf den durchschnittlichen Status aller Mitglieder gesetzt, wobei bei true/false intern true=1, false=0 gerechnet wird, und beim setzen gilt true = avg>4.9999999, 'min' - Der Gruppenstatus entspricht dem 'geringsten' Mitgliederstatus. 'max' - Der Gruppenstatus entspricht dem 'höchsten' Mitgliederstatus

• Optional: automatisch ein device_query wenn ein Gerät sich neu am Netz meldet (und als 'pingable' gilt - Konfigurierbar über die Einstellungen)

• Optional: automatisch beim Start für alle 'pingable' Geräte ein Device-query absetzen (incl. Timeout in sekunden, min 0.5 sekunden, max 10 sekunden, default 1 Sekunde. - konfigurierbar über die Einstellungen / an/aus, timeout)

Improved device_query - Device_query liest jetzt mehr Werte, und wirft weniger Fehler
ZH 5.0.3

Admin: Wird das Pairing vom Tab aus gestartet, so kann es angehalten oder verlängert werden.
Admin: Die Funktionen 'firmware update', 'touchlink reset', 'pairing with code', 'gruppe erzeugen' sind nur noch im Zigbee-Tab zugänglich
Admin: Die Karte des Koordinators wird immer dargestellt wenn der Adapter gestartet wurde - auch wenn das Zigbee-Subsystem nicht läuft (mit begrenzter Info)
Admin: Die Koordinator-Karte zeigt die ZH/ZHC und Adapter version

ToDo:

• (Prio 2) optimierung bei den nicht unterstützten Gruppenstates
• (Prio 4) Umgang mit den 'color' states bei memberupdate und stateupdate
• 'no converter for' Meldungen beim anpassen von memberuptate und stateupdate Fixed 11.9.
• (Prio 3) Deaktivierte Geräte die in Gruppen sind werden aktuell nicht vom Leseversuch der States ausgenommen
• Lesen der States asynchron gestalten, sowie mit einer einstellbaren Verzögerung ausstatten Asynchron: done 11.9. Einstellbare Verzögerung - unnötig
• Bindings: Bindings aus dem Zigbee-Herdsman holen und damit synchronisieren
• (Prio 7) Umstieg zu Z2M: Export für Gruppen und Bindings, damit diese vor einem Umstieg nicht zwangsweise gelöscht werden müssen
• (Prio 1) Timing-Auffälligkeiten bei der Konfiguration von neuen Geräten.
• (Prio 6) Recall Map data Option
• (Prio 7) save map Data as png option

Über rege Mithilfe würde ich mich freuen.

Version 3.1.3: Es gibt weitere Neuigkeiten:

• Deaktivierte Geräte sind jetzt in den Objekten erkennbar:

Im Tab:

Im Objektbaum:

Debug Interface verbesserungen:

• Mehr Meldungen im Log
• Links um sich die Log Meldungen zu bestimmten events gezielt anschauen zu können (die blauen Icons links)
  
• Anzeige so das sie direkt kopiert und mit code tags und allem im Forum gepostet werden können
  

Da rauskopiert, hier einkopiert sieht das dann so aus:

I01: Zigbee Event of Type readResponse from device 0x00be44fffeab0b87, incoming event: {"type":"readResponse","data":{},"linkquality":163,"groupID":0,"cluster":"seMetering","meta":{"rawData":{"type":"Buffer","data":[8,14,1,1,0,134]},"zclTransactionSequenceNumber":14,"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0}},"endpoint_id":1}
I02: 1 converter available for 'E2206' '00be44fffeab0b87' with cluster 'seMetering' and type 'readResponse'
I03: message received '{"linkquality":163}' from device 00be44fffeab0b87 type 'E2206'
I04: value generated '163' from device 00be44fffeab0b87 for 'Link quality'
I02.1a: data: {} options: {} meta:{"deviceIEEE":"0x00be44fffeab0b87","logger":"StatesController","state":{"state":""}} result:{}
I02.1b: converter 1 : Cluster seMetering => payload : {}
I03-1: message received '{}' from device 00be44fffeab0b87 type 'E2206'
NOVAL: No value published for device 00be44fffeab0b87

A.

@Homoran - machst du den 3.0 Tester thread bitte zu ?

Nachtrag: Es gibt inzwischen eine 3.1.1, die die ZHC 25 integriert. Alle die die 3.1 installiert haben bitte ich auf die 3.1.1 zu aktualisieren. ! Es gibt inzwischen eine 3.1.2 - auch die nutzt ZHC25 und ZH 6, besitzt aber auch einen Fix für den Pairing bug.

[Asgothian]

Wobei ich insbesondere Tester brauche:

• Zeitverhalten beim memberupdate bei Gruppen mit leuchten von verschiedenen Herstellern.
• Saubere Erkennung der zu lesenden Datenpunkte bei Geräten von verschiedenen Herstellern - insbesondere Geräten mit mehr als einem 'state' (z.Bsp. Mehrfachsteckdosen)
• Sauberes Verhalten des stateupdate bei verschiedenen Gruppen mit möglichst unterschiedlichen Geräten
• Thema 'stateupdate' und 'memberupdate' im Zusammenspiel mit dimmen über brightness_move und colortemp_move
• Gruppen erzeugen, löschen, manipulieren
• ** Verifikation von ZH 6.x und ZHC 25.x**

Dringend : Ich brauche Tester mit EZSP und/oder Conbee II / III Koordinatoren. Es scheint Anpassungen gegeben zu haben die ich nicht nachvollziehen kann.

Wichtig - bei den Tests zum memberupdate sollten die betroffenen Geräte auf Debug gestellt sein (die Geräte, nicht der Adapter) so das Daten im Debug-Interface erscheinen.

Ich habe selber nur eine begrenzte Anzahl von Gerätetypen zum testen. Je mehr getestet werden desto besser.

Known Bugs et al:

• Version 3.1 Installiert vor Samstag 12.9. 17:35: Firmware update check crashed den Adapter (Fixed - 12.9.17:35)
• Gruppenstates werden teilweise doppelt auf der Kachel dargestellt.
• Gruppennamen die bei Erstellen der Gruppe angegeben werden werden nicht sauber übernommen Fixed 16.9.20:00

A.

[Homoran]

@asgothian sagte in Tester wanted - Zigbee Adapter 3.1:

@Homoran - machst du den 3.0 Tester thread bitte zu

durfte es auch der 3.x Thread sein? ;-)

[Asgothian]

@homoran sagte in Tester wanted - Zigbee Adapter 3.1:

durfte es auch der 3.x Thread sein?

Ja. Danke.

[dimaiv]

P.S.: Fixed.

Beim Uberprüfen auf Firmware Updates stürzt der Adapter ab.

2025-09-12 14:01:38.052 - info: zigbee.0 (248399) 20 devices are part of the network
2025-09-12 14:01:38.056 - info: zigbee.0 (248399) Zigbee started
2025-09-12 14:01:38.253 - info: zigbee.0 (248399) debug devices set to []
2025-09-12 14:01:55.422 - info: admin.0 (890) <== Disconnect system.user.admin from ::ffff:192.168.2.100
2025-09-12 14:03:02.582 - info: admin.0 (890) ==> Connected system.user.admin from ::ffff:192.168.2.100
2025-09-12 14:03:03.158 - info: zigbee.0 (248399) List of port: []
2025-09-12 14:03:10.168 - error: zigbee.0 (248399) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
2025-09-12 14:03:10.169 - error: zigbee.0 (248399) unhandled promise rejection: Cannot read properties of undefined (reading 'indexOf')
2025-09-12 14:03:10.508 - error: zigbee.0 (248399) TypeError: Cannot read properties of undefined (reading 'indexOf')
at getZbId (/opt/iobroker/node_modules/iobroker.zigbee/lib/utils.js:92:23)
at Ota.getDeviceForMessage (/opt/iobroker/node_modules/iobroker.zigbee/lib/ota.js:194:23)
at Ota.checkOtaAvail (/opt/iobroker/node_modules/iobroker.zigbee/lib/ota.js:56:35)
at Ota.onMessage (/opt/iobroker/node_modules/iobroker.zigbee/lib/ota.js:46:26)
at Zigbee.emit (node:events:536:35)
at Zigbee.emit (node:domain:489:12)
at change (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/src/lib/adapter/adapter.ts:11040:34)
at Immediate. (file:///opt/iobroker/node_modules/@iobroker/db-states-redis/src/lib/states/statesInRedisClient.ts:365:37)
at processImmediate (node:internal/timers:483:21)
2025-09-12 14:03:10.509 - error: zigbee.0 (248399) Cannot read properties of undefined (reading 'indexOf')
2025-09-12 14:03:10.533 - info: zigbee.0 (248399) Halting zigbee adapter. Restart delay is at least 30 seconds.
2025-09-12 14:03:10.534 - info: zigbee.0 (248399) cleaning everything up...
2025-09-12 14:03:10.540 - info: zigbee.0 (248399) Saved local configuration data
2025-09-12 14:03:10.907 - info: zigbee.0 (248399) Device zigbee.0.00124b0022571c92 is marked unavailable, skipping...
2025-09-12 14:03:10.982 - info: zigbee.0 (248399) Closing Zigbee network, 0 seconds remaining
2025-09-12 14:03:11.535 - warn: zigbee.0 (248399) Terminated (UNCAUGHT_EXCEPTION): Without reason
2025-09-12 14:03:12.124 - error: host.GartenIoB Caught by controller[1]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
2025-09-12 14:03:12.125 - error: host.GartenIoB Caught by controller[2]: TypeError: Cannot read properties of undefined (reading 'indexOf')
2025-09-12 14:03:12.125 - error: host.GartenIoB Caught by controller[2]: at getZbId (/opt/iobroker/node_modules/iobroker.zigbee/lib/utils.js:92:23)
2025-09-12 14:03:12.125 - error: host.GartenIoB Caught by controller[2]: at Ota.getDeviceForMessage (/opt/iobroker/node_modules/iobroker.zigbee/lib/ota.js:194:23)
2025-09-12 14:03:12.125 - error: host.GartenIoB Caught by controller[2]: at Ota.checkOtaAvail (/opt/iobroker/node_modules/iobroker.zigbee/lib/ota.js:56:35)
2025-09-12 14:03:12.125 - error: host.GartenIoB Caught by controller[2]: at Ota.onMessage (/opt/iobroker/node_modules/iobroker.zigbee/lib/ota.js:46:26)
2025-09-12 14:03:12.125 - error: host.GartenIoB Caught by controller[2]: at Zigbee.emit (node:events:536:35)
2025-09-12 14:03:12.126 - error: host.GartenIoB Caught by controller[2]: at Zigbee.emit (node:domain:489:12)
2025-09-12 14:03:12.126 - error: host.GartenIoB Caught by controller[2]: at change (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/src/lib/adapter/adapter.ts:11040:34)
2025-09-12 14:03:12.126 - error: host.GartenIoB Caught by controller[2]: at Immediate. (file:///opt/iobroker/node_modules/@iobroker/db-states-redis/src/lib/states/statesInRedisClient.ts:365:37)
2025-09-12 14:03:12.126 - error: host.GartenIoB Caught by controller[2]: at processImmediate (node:internal/timers:483:21)
2025-09-12 14:03:12.126 - error: host.GartenIoB instance system.adapter.zigbee.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
2025-09-12 14:03:12.127 - info: host.GartenIoB Restart adapter system.adapter.zigbee.0 because enabled
2025-09-12 14:03:17.768 - info: admin.0 (890) <== Disconnect system.user.admin from ::ffff:192.168.2.100
2025-09-12 14:03:42.865 - info: host.GartenIoB instance system.adapter.zigbee.0 in version "3.1.0" (non-npm: ioBroker/ioBroker.zigbee) started with pid 248418
2025-09-12 14:03:46.062 - info: zigbee.0 (248418) starting. Version 3.1.0 (non-npm: ioBroker/ioBroker.zigbee) in /opt/iobroker/node_modules/iobroker.zigbee, node: v20.19.4, js-controller: 7.0.7
2025-09-12 14:03:46.119 - info: zigbee.0 (248418) Adapter ready - starting subsystems. Adapter is running in info mode.

[Asgothian]

@dimaiv sagte in Tester wanted - Zigbee Adapter 3.1:

Beim Uberprüfen auf Firmware Updates stürzt der Adapter ab.

Lässt sich das auf bestimmte devices eingrenzen ?

Zum testen sollte es reichen die Devices über die Oberfläche zu deaktivieren.

[Homoran]

@dimaiv sagte in Tester wanted - Zigbee Adapter 3.1:

Beim Uberprüfen auf Firmware Updates stürzt der Adapter ab.

hatte ich auch früher schon, lag anscheinend am sentry-Modul.
Ich sehe bei dir im log, aber nicht die selben Meldungen.

Du kannst es ja mal abschalten

[dimaiv]

P.S.: Fixed.

@asgothian
Es ist egal, was und wie viele ich deaktiviere bis auf alle 20, kommt gleiche Fehler.

P.S.: Auch wenn ich sentry aus mache...

[arteck]

@homoran ne das ist nicht sentry

[Asgothian]

@arteck War nich sentry. Ist gefixed.

A.

[Shadowhunter23]

@asgothian
Bin mal auf 3.1.0, hab allerdings keine Lampen und Gruppen.

Bisher keine Probleme.

[Asgothian]

Es gibt wieder eine neue Version.

Man kann zusätzlich den Zeit-Abstand zwischen den Pings einstellen. Wobei diese Einstellung nicht fix ist, je nach Anzahl der anzueignenden Devices verändert der Adapter den Timeout um das Netz nicht zu sehr zu belasten.

[oxident]

Ich habe ein Test-Netz aufgebaut und möchte da mittelfristig meine (über 100) Geräte/Sensoren von Deconz rüberholen.

Daher kann ich ganz entspannt schon direkt ein paar Dinge mit dem latest Release testen.

Spontan aufgefallen ist mir, dass der iot-Adapter scheinbar versucht, benannte Farben in den Hex-Datenpunkt eine Hue-Lampe zu schreiben.

Bitte steinigt mich nicht, falls das die völlig falsche Baustelle ist ;-)

[Asgothian]

@oxident sagte in Tester wanted - Zigbee Adapter 3.1:

Ich habe ein Test-Netz aufgebaut und möchte da mittelfristig meine (über 100) Geräte/Sensoren von Deconz rüberholen.

Daher kann ich ganz entspannt schon direkt ein paar Dinge mit dem latest Release testen.

Spontan aufgefallen ist mir, dass der iot-Adapter scheinbar versucht, benannte Farben in den Hex-Datenpunkt eine Hue-Lampe zu schreiben.

bist du sicher ? der ist Adapter sollte aussschliesslich die im Screenshot markierten Datenpunkte erkennen:

Der Zigbee Adapter nutzt den color Datenpunkt aus der Vergangenheit und da z2m das so akzeptiert mir durchaus verschiedenen Formaten. Neben dem für den Zigbee Adapter einzigartigen named color format (dazu gibt es eine Liste von durch alle Web-Browser erkannte benannte Farben (die extended Colors)) werden noch die von Z2M akzeptierten Formate akzeptiert. Die Liste ist lang (kopiert von der Doku auf Z2M, z.Bsp. von diesem Gerät):

• color_xy: To control the XY color (CIE 1931 color space) publish a message to topic zigbee2mqtt/FRIENDLY_NAME/set with payload {"color": {"x": X_VALUE, "y": Y_VALUE}} (e.g. {"color":{"x":0.123,"y":0.123}}). To read the XY color send a message to zigbee2mqtt/FRIENDLY_NAME/get with payload {"color":{"x":"","y":""}}. Alternatively it is possible to set the XY color via RGB:
  {"color": {"r": R, "g": G, "b": B}} e.g. {"color":{"r":46,"g":102,"b":150}}
{"color": {"rgb": "R,G,B"}} e.g. {"color":{"rgb":"46,102,150"}}
{"color": {"hex": HEX}} e.g. {"color":{"hex":"#547CFF"}}
• color_hs: To control the hue/saturation (color) publish a message to topic zigbee2mqtt/FRIENDLY_NAME/set with payload {"color": {"hue": HUE, "saturation": SATURATION}} (e.g. {"color":{"hue":360,"saturation":100}}). To read the hue/saturation send a message to zigbee2mqtt/FRIENDLY_NAME/get with payload {"color":{"hue":"","saturation":""}}. Alternatively it is possible to set the hue/saturation via:
  HSB space (hue, saturation, brightness): {"color": {"h": H, "s": S, "b": B}} e.g. {"color":{"h":360,"s":100,"b":100}} or {"color": {"hsb": "H,S,B"}} e.g. {"color":{"hsb":"360,100,100"}}
  HSV space (hue, saturation, value):{"color": {"h": H, "s": S, "v": V}} e.g. {"color":{"h":360,"s":100,"v":100}} or {"color": {"hsv": "H,S,V"}} e.g. {"color":{"hsv":"360,100,100"}}
  HSL space (hue, saturation, lightness){"color": {"h": H, "s": S, "l": L}} e.g. {"color":{"h":360,"s":100,"l":100}} or {"color": {"hsl": "H,S,L"}} e.g. {"color":{"hsl":"360,100,100"}}

Jedes Format X das im Payload hinter {"color":X} akzeptiert wird kann auch im DP color benutzt werden.
Z2M unterscheided dabei Geräte die mit color_xy und/oder color_hs arbeiten. Der Zigbee-Adapter macht das auch, die Datenpunkte unter color_hs gibt es nur wenn z2m auch color_hs meldet. Mir sind keine Geräte bekannt die color_hs unterstützen, color_xy aber nicht.

Damit ist der iot Adapter überfordert. Deswegen gibt es die mit den entsprechenden Rollen versehenen Datenpunkte die ich im Screenshot markiert habe. All diese Datenpunkte machen letztendlich nichts anderes als den color Datenpunkt mit entsprechenden Werten zu füttern, damit diese dann an Z2M geschickt werden.

Auf der Kachel im Zigbee-Adapter wird immer nur die 'named' Farbe angeboten - das ist die einzige Möglichkeit wie ich da Farbe bei dem begrenzten Platz überhaupt auswählbar machen kann. Code-Technisch wird da mediumvioletred angezeigt wenn im DP color keine der korrekten named Colors drin steht.

Bitte steinigt mich nicht, falls das die völlig falsche Baustelle ist ;-)

Eine falsche Baustelle gibt es nicht. (aber da du danach gefragt hast, nimm dies hier 🪨 :) )

A.
Edit: Quelle hinzugefügt.

[Asgothian]

Es gibt inzwischen eine 3.1.1

Bitte auf die 3.1.1 aktualisieren und normale Gerätefunktion testen. Ich habe auf die ZHC 25 umgestellt, bei der vor breaking changes gewarnt wurde. Was ich gefunden hab habe ich umgestellt. Ob ich alles gefunden habe weiss ich aber nicht!

Wichtig: Bitte vor der Installation den Zigbee Adapter anhalten !!!

A.

[Shadowhunter23]

@asgothian
Hab eben von GitHub installiert, Version bleibt bei 3.1.0.

[Asgothian]

@shadowhunter23 Bitte nochmal installieren - da ist was mit der Version schief gegangen. Jetzt sollte es 3.1.1 sein

A.

[Asgothian]

@oxident Eine Frage,

hast du beim Anlernen der Leichen Probleme gehabt ? Mit der 3.1.0 ?

Was ist mit der 3.1.1 ? Geht da das Anlernen genau so gut ?

Ich hab hier vereinzelt seltsames Verhalten welches ich mit dem Debugger nicht v erfolgen kann da sich dadurch das Timing ändert.

A.

[oxident]

@asgothian Habe ehrlich gesagt nur eine einzelne Hue-Lampe angelernt. Da gab es keine Probleme bei der 3.0.1

[Asgothian]

Inzwischen gibt es eine 3.1.2 - der Pairing bug ist gefunden und behoben (hoffentlich) - Es war alter Code der früher wohl mal notwendig war, heute aber Probleme macht.

Dieser musste mit ZHC25 entfernt werden.

A.