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

[MeisterQ 0]

@Asgothian

Bei mir kommt immer Folgendes beim Starten.

Ich habe ja den shellygen4 Externen converter laufen.
Welche herdsman converter version läuft da jetzt im Adapter?

zigbee.0
	2025-04-18 18:01:38.492	info	Ignoring converter from module: /opt/iobroker/iobroker-data/zigbee_0/shellygen4.js - see warn messages for reason
zigbee.0
	2025-04-18 18:01:38.491	error	Sandbox error: Cannot find module '../zigbee-herdsman-converters/dist/dist/lib/reporting' Require stack: - /opt/iobroker/node_modules/iobroker.zigbee/main.js
zigbee.0
	2025-04-18 18:01:38.491	warn	trying to add "reporting = require(../zigbee-herdsman-converters/dist/dist/lib/reporting)" to sandbox
zigbee.0
	2025-04-18 18:01:38.491	error	Sandbox error: Cannot find module '../zigbee-herdsman-converters/dist/dist/lib/exposes' Require stack: - /opt/iobroker/node_modules/iobroker.zigbee/main.js
zigbee.0
	2025-04-18 18:01:38.491	warn	trying to add "exposes = require(../zigbee-herdsman-converters/dist/dist/lib/exposes)" to sandbox
zigbee.0
	2025-04-18 18:01:38.491	error	Sandbox error: Cannot find module '../zigbee-herdsman-converters/dist/dist/converters/toZigbee' Require stack: - /opt/iobroker/node_modules/iobroker.zigbee/main.js
zigbee.0
	2025-04-18 18:01:38.491	warn	trying to add "tz = require(../zigbee-herdsman-converters/dist/dist/converters/toZigbee)" to sandbox
zigbee.0
	2025-04-18 18:01:38.491	error	Sandbox error: Cannot find module '../zigbee-herdsman-converters/dist/dist/converters/fromZigbee' Require stack: - /opt/iobroker/node_modules/iobroker.zigbee/main.js
zigbee.0
	2025-04-18 18:01:38.490	warn	trying to add "fz = require(../zigbee-herdsman-converters/dist/dist/converters/fromZigbee)" to sandbox
zigbee.0
	2025-04-18 18:01:38.490	error	Sandbox error: Cannot find module '../zigbee-herdsman-converters/dist/dist/lib/modernExtend' Require stack: - /opt/iobroker/node_modules/iobroker.zigbee/main.js
zigbee.0
	2025-04-18 18:01:38.490	warn	trying to add "m = require(../zigbee-herdsman-converters/dist/dist/lib/modernExtend)" to sandbox

[Asgothian]

@meisterq-0 welche Version läuft steht im log beim Start.

Nimm mal das /dist aus dem Pfad heraus, das fügt der Adapter (anscheinend in deinem Fall falsch) hinzu.

A.

[MeisterQ 0]

@asgothian

Das scheint geholfen zu haben. Aber ich sehe gerade, dass er den Converter von vor 2 Tagen nimmt. Greift er jetzt immer auf die aktuellste Version zu beim Start?

Weil er mir sagt er läuft 23.29.0. Das wäre eine ZHC Version von vor 2 Tagen.

Damit kann ich meinen Converter dann auch löschen...

[Asgothian]

@meisterq-0 sagte in Tester Zigbee Adapter 3.x gesucht:

@asgothian

Das scheint geholfen zu haben. Aber ich sehe gerade, dass er den Converter von vor 2 Tagen nimmt. Greift er jetzt immer auf die aktuellste Version zu beim Start?

Weil er mir sagt er läuft 23.29.0. Das wäre eine ZHC Version von vor 2 Tagen.

Damit kann ich meinen Converter dann auch löschen...

Solange die Version im latest ist nimmt sie die latest zhc, aber immer nur bei Installation

[MeisterQ 0]

@asgothian Interessant zu wissen.

Das heißt nur beim Update bekomme ich immer die neuste ZHC Version?

Kann man nicht sporadisch (täglich) ggf den Adapter die ZHC Version prüfen und aktualisieren lassen bei Bedarf? Meinetwegen auch per Button in den Instanzeinstellungen oder so.

So kann man viel schneller für Gerätesupport sorgen

[Asgothian]

@meisterq-0 sagte in Tester Zigbee Adapter 3.x gesucht:

@asgothian Interessant zu wissen.

Das heißt nur beim Update bekomme ich immer die neuste ZHC Version?

Kann man nicht sporadisch (täglich) ggf den Adapter die ZHC Version prüfen und aktualisieren lassen bei Bedarf? Meinetwegen auch per Button in den Instanzeinstellungen oder so.

So kann man viel schneller für Gerätesupport sorgen

Nein. Kann man nicht.

Und in dem Moment wo die 3.x soweit kommt das sie ins Stable soll wird sie auch auf eine bestimmte ZH/ZHC Kombination fest geschrieben. Das Risiko das eine Änderung in. ZH/ZHC plötzlich Änderungen am Adapter erfordert ist zu gross. Siehe das Problem mit deinem externen Konverter. Ich dachte ich hätte das so umgebaut das beide Versionen sauber geprüft werden - das hat aber leider nicht so funktioniert wie ich das wollte.

Und das zusätzliche /dist in den ZHC ist irgendwann innerhalb der 23.x dazu gekommen.

A.

[MeisterQ 0]

@asgothian Schade. Naja ich weiß ja jetzt, dass ich die ZHC fast 1:1 in den Adapter als Externe Konverter übernehmen kann bis sie dann beim Update vom Adapter unterstützt werden.

War nur so ein Gedankengang um den Usern zu ermöglichen schneller Gerätesupport bieten zu können.

[Asgothian]

@meisterq-0 sagte in Tester Zigbee Adapter 3.x gesucht:

@asgothian Schade. Naja ich weiß ja jetzt, dass ich die ZHC fast 1:1 in den Adapter als Externe Konverter übernehmen kann bis sie dann beim Update vom Adapter unterstützt werden.

War nur so ein Gedankengang um den Usern zu ermöglichen schneller Gerätesupport bieten zu können.

In der Theorie korrekt
In der Praxis nicht, da die ZHC mehr sind als die Gerätedefinitionen.

Dazu kommt das es sein kann das sich einzelne converter nicht als externe Konverter in den Adapter übernehmen lassen - wenn sie neue oder angepasste Funktionen aus dem backend der ZHC benutzen.

A.

[locito09]

@asgothian
Die Flower Sensoren funktionieren immer noch nicht und heute hatte ich diese Fehlermeldung im LOG evtl bringst dir was.

zigbee.0
2025-04-19 10:41:18.783	warn	ELEVATED:I02 (92be) value generated '0' from device 00124b00226296fc for 'Link quality'

zigbee.0
2025-04-19 10:41:18.783	warn	ELEVATED:I01 (92be) message received '{"linkquality":0}' from device 00124b00226296fc type 'DIYRuZ_Flower'

zigbee.0
2025-04-19 10:41:18.783	warn	ELEVATED:I02 (92be) value generated 'false' from device 00124b00226296fc for 'Available'

zigbee.0
2025-04-19 10:41:18.782	warn	ELEVATED:I01 (92be) message received '{"available":false}' from device 00124b00226296fc type 'DIYRuZ_Flower'

[arteck]

@locito09 s

Die Flower Sensoren funktionieren immer noch nicht und heute hatte ich diese Fehlermeldung im LOG evtl bringst dir was.

nö.. das Gerät ist nicht da.. schon mal Batterie getauscht.. ?

[mickemup]

@asgothian

Danke vorab für den tollen Adapter.

Ich habe bei mir einige IKEA Parasolls (Fensterkontaktsensoren) installiert.
Diese lieferten beim initialen pairing auch den Batteriestatus (Anzeige in %)
Dieser wurde bei mir aber anschliessend nie mehr aktualisiert.
Mittels Entwicklertab habe ich es nun hingekriegt ein "Anfrage" auszulösen um den Batteriestatus zu aktualisieren.

Ist es auch möglich eine solche Anfrage via Skript/Blockly auszulösen?
Denn ich müsste ja auch eine Statusänderung des Fenstersensors triggern können, damit dieser auch wach ist.

Grüsse

[Meister Mopper]

@mickemup sagte in Tester Zigbee Adapter 3.x gesucht:

Ist es auch möglich eine solche Anfrage via Skript/Blockly auszulösen?

Schau mal hier.

[mickemup]

@meister-mopper

Danke aber entweder stehe ich auf dem Schlauch oder dein Link entspricht nicht meinem Vorhaben.

Es geht darum einen "Zigbee" Befehl abzusetzen, um den Batteriestatus in den Objekten aktualisieren zu können.
Das andere (Vis usw.) könnte dann nachher folgen, macht aber bei mir ja noch nicht wirklich Sinn, wenn die Bat-States nicht aktuell sind....

[gelberlemmy]

@mickemup guten Morgen, da hänge ich mich ran, da ich auch einige Geräte habe, die den Batteriestatus aktuell nicht übertragen.

[Asgothian]

@mickemup Prinzipiell geht das. Ob das aber auf Dauer funktioniert ist mindestens Fraglich. Dazu später Dazu gibt es 2 Optionen, die prinzipiell unterschiedlich sind.

Option A geht ausschliesslich direkt Skript / Blockly. Dazu muss via sendTo an den Zigbee Adapter die Funktion sendToZigbee mit dem Payload gefüttert werden der auch im Developer drin steht, wenn man sich das JSON anzeigen lässt (Haken bei 'Expert Mode'). Es gibt dafür (absichtlich) keinen Datenpunkt.

Option B geht "auch" direkt über einen Datenpunkt, und kann dadurch von anderen Logik-Maschinen und / oder einer Visualisierung getriggert werden. Dazu muss der Payload { "read": { "cluster": "<the_cluster_id>", "attributes": ["<the_attribute_id>","<another attribute_id>"] }}
in den Datenpunkt send_payload vom Device geschrieben werden. Cluster und Attribute entsprechen dabei denen die auch im Developer-Modus ausgewählt sein müssen.

Was einzutragen ist und ob es prinzipiell geht hängt von der Firmware des Gerätes ab.

Aber
Das Zigbee-Netzwerk erfordert keine dauerhafte Verbindung zwischen Geräten und Koordinatoren. Es ist zulässig das Geräte 'schlafen' und nur bei Bedarf Nachrichten an den Koordinator senden. Diese 'Pause' bei den Geräten darf beliebig lang sein. Üblich sind bei den 'Endgeräten' Pausen von 24h für das Versenden z.Bsp. des Batteriezustandes.

Mit dazu gehört das die Batteriebetriebenen Geräte gerade nicht auf Nachrichten aus dem Netzwerk lauschen um Energie zu sparen.

Die Anfrage vom Koordinator nach dem Batteriezustand wird also im Zweifelsfall unbeantwortet bleiben, es sei denn sie erfolgt wenn das Gerät wach ist.

A.

[AlexHaxe]

@mickemup said in Tester Zigbee Adapter 3.x gesucht:

Ich habe bei mir einige IKEA Parasolls (Fensterkontaktsensoren) installiert.
Diese lieferten beim initialen pairing auch den Batteriestatus (Anzeige in %)
Dieser wurde bei mir aber anschliessend nie mehr aktualisiert.

bei meinen Parasolls wird der Batteriestand regelmäßig aktualisiert, d.h. ohne mein Zutun vom Gerät gemeldet. Die Meldung erfolgt mehrere Stunden auseinander, könnte also sein, dass sie nur ein- bis zweimal täglich erfolgt (eines meiner Geräte hat einen Aktualisierungsstand des Batteriewertes von gestern 21 Uhr). Das mag auch von der Benutzung abhängen, d.h. ein Sensor der nicht durch ein "Öffnen"-Ereignis geweckt wird, dürfte länger warten bis er meldet, im Vergleich zu einem der permanent auf- und zugeht. Über das Batteriestands-Meldeintervall habe ich bislang keine Statistik geführt, ich weiß aber, dass die Geräte ca. alle 10 Minuten ihre link_quality melden (sofern nicht der "device availability check" im Adapter ausgeschaltet ist, dann dürften sie sich nur melden bei einem Ereignis).

Bei allen Ikea Geräten ist es (nach meiner Erfahrung) wichtig nach dem erfolgreichen Pairing über die Kachel ein "Re-Configure" auszulösen. Erst danach werden die Werte richtig gesendet und auch der Batteriestand übermittelt. Beim Rekonfigurieren muss das Gerät natürlich "wach" sein. Eine Möglichkeit dazu wäre den Magnet-Kontakt zyklisch auszulösen (beim Parasoll). Ein andere Möglichkeit ist es auf den Timeout in der Oberfläche zu warten, um dann am Gerät einmal die Batterie raus und wieder einzusetzen. Die Logdatei sollte dann ein erfolgreiches "configure" zum Gerät melden. Rekonfigurationen werden in eine Art Warteschlange gestellt, so dass keine Eile besteht zum Gerät zu flitzen, um den richtigen Moment nicht zu verpassen (die Physik sieht ja meistens ein bisschen schwieriger aus, wenn die Geräte schon verbaut sind).

[gelberlemmy]

@asgothian ich hatte immer die Vision, das bei einem Melden oder Auslösen eines Batteriebetriebenen Gerätes der Batteriestand übertragen wird. Ist dem nicht so ? Solch Problem habe ich auch bei meinem ZWave Geräten. Ich finde diese Informationen des Batteriestandes sehr wichtig. Blöd wenn man erst merkt, das das Gerät nicht funktioniert, wenn man eine Auslösung erwartet. Das mich dem Reconfigure werde ichveinmal ausprobieren bei einem Gerät was den Batteriestand nicht meldet.

[Asgothian]

@gelberlemmy sagte in Tester Zigbee Adapter 3.x gesucht:

@asgothian ich hatte immer die Vision, das bei einem Melden oder Auslösen eines Batteriebetriebenen Gerätes der Batteriestand übertragen wird. Ist dem nicht so ? Solch Problem habe ich auch bei meinem ZWave Geräten. Ich finde diese Informationen des Batteriestandes sehr wichtig. Blöd wenn man erst merkt, das das Gerät nicht funktioniert, wenn man eine Auslösung erwartet. Das mich dem Reconfigure werde ichveinmal ausprobieren bei einem Gerät was den Batteriestand nicht meldet.

Das hängt von der Firmware des Gerätes ab. Wenn du das im Detail wissen willst musst du die RAW Nachrichten Mitschreiben und analysieren. Diese kannst du per trigger auf wurde geändert auf den DP msg_from_zigbee abgreifen. Da einfach mal ein Skript dran hängen und schauen ob da was mit 'batt' rein kommt.

A.

[mickemup]

@asgothian

Super, danke für die ausführliche Antwort.
Werde ich heute Abend mal mit Option A probieren.
Das die Geräte schlafen öfters schlafen ist mir bewusst.
Darum würde ich auf den Open/Closed State triggern. So funktionierte es auch bei meinem Test. (Fenster kurz auf und zu und dann habe ich im Dev Tab den request gesendet.

Das Blockly werde ich so "basteln" das nicht bei jedem Open/Closed State Wechsel nachgefragt wird, sondern nur wenn eine bestimmte Zeit verstrichen ist (zu Beginn nehme ich mal 24h)

Das JSON im Expert Modus habe ich gesehen und werde es hier dann reinstellen, falls jemand ähnliche "Troubles" hat.

[mickemup]

@alexhaxe sagte in Tester Zigbee Adapter 3.x gesucht:

Über das Batteriestands-Meldeintervall habe ich bislang keine Statistik geführt, ich weiß aber, dass die Geräte ca. alle 10 Minuten ihre link_quality melden (sofern nicht der "device availability check" im Adapter ausgeschaltet ist, dann dürften sie sich nur melden bei einem Ereignis).

Saugt dier das nicht die Batterie leer der Parasolls wenn die alle 10min was senden "müssen"?

Das mit dem Re-Configure werde ich ebenfalls mal probieren.
Bei den Raw messages kommt bei mir jedenfalls der Bat-Level momentan nie mit (Alle Bat Level hatten die letzte Aktualisierung am Tag der Einrichtung im Feb)