NEWS
Tester Zigbee Adapter 3.x gesucht
Tester Zigbee Adapter 3.x gesucht
-
@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_qualitymelden (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).
@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) -
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 sagte in Tester Zigbee Adapter 3.x gesucht:
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.
Könntest Du dann das Blockly hier posten? Ich bin leider nicht so tief drinne, dass ich das mal so eben hinbekomme. Das wäre super
-
@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)@mickemup said in Tester Zigbee Adapter 3.x gesucht:
@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"?
Allgemein: Es mag durchaus sein, dass man ohne die regelmäßigen Meldungen ein paar Tage oder gar Wochen mehr Laufzeit rausholen kann, aber ich bevorzuge die Möglichkeit diese Updates zur Überwachung der Geräte nutzen zu können, im Gegensatz zu rein Ereignis-basierten Lebenszeichen. Ich habe bislang keine Gegenprobe angestellt, wie lange ein Gerät ohne die "device availability checks" durchhält, und um wie viel später man die Abwesenheit eines Gerätes bemerkt, wenn man keine regelmäßigen / verlässlichen Updates über die Link Quality erhält. Denn obwohl die batteriebetriebenen Geräte
batteryoderbattery_lowDatenpunkte haben (und diese mal mehr und mal weniger verlässlich melden), kommt es immer mal wieder vor, dass ein Gerät einfach keinen Pieps mehr sagt, weil die Batterie überraschend leer ist.Für Parasolls im speziellen: Die Parasoll sind bekannt dafür Batterien zu verschlingen. Ich bin nicht auf dem letzten Stand der Erkenntnisse, weil ich die entsprechenden Threads nicht aktiv verfolge, habe aber ein paar eigene Beobachtungen angestellt und Gegenmaßnahmen entwickelt. Ein Konsenz aus den Diskussionen ist die Parasolls mit Akkus zu betreiben. Meine Erfahrung kann das zumindest teilweise bestätigen: anfangs hatte ich normale Batterien eingesetzt und diese waren nach ca. 3-4 Tagen regelmäßig leer gesaugt. Mit Akkus komme ich mehrere Monate ohne Wechsel durch.
Allerdings gibt es dabei eine "kleine" Komplikation: alle 3-4 Tage fangen die Geräte an wie verrückt Updates zu senden. Manchmal sind es nurlink_qualityUpdates, manchmal sind esdevice announcements. Diese Updates haben eine deutlich höhere Frequenz (ca. all 10-30 Sekunden) im Vergleich zu den regulären Updates (alle 10 Minuten). Sobald die Geräte in diesen Modus verfallen sind sie nicht mehr wirklich funktionsbereit und senden keine Tür-Ereignisse mehr. Was dann hilft ist ein Reboot des Gerätes, sprich wenn mein Script erkennt, dass ein Gerät in diesen Zustand verfallen ist, dann bekomme ich eine Nachricht, gehe dann ans Gerät, entferne die Batterie für eine Sekunde und setze sie wieder ein. Danach "lebt" es wieder, und arbeitet wie gewohnt weiter. Das ist sicherlich keine dauerhafte Lösung, aber zumindest bekomme ich es mit, wenn ein Gerät den Abgang macht.
Ob die Update-Intervalle von 10 Minuten tatsächlich ursächlich für den regelmäßigen Schluckauf sind kann ich nicht 100% ausschließen, gfs. werde ich mal auf einen Custom-Converter setzen, der ein größeres Intervall für die Parasoll-Pings vorsieht.
Interessanterweise sind die Parasolls die einzigen Geräte, die diese Problematik entwickeln, Vallhorn, Somrig oder Badring haben solch ein Verhalten noch nicht an den Tag gelegt.Die Beobachtung (und die Benachrichtigungen) habe ich erst nach Wechsel auf Akkus gemacht, es ist sehr gut möglich, dass dies auch mit ein Grund für das Leersaugen von normalen Batterien ist. Möglicherweise würden diese auch länger durchhalten, wenn man den Problemzustand rechtzeitig bemerkt und durch Reboot gegenwirkt. Andererseits werden vom Hersteller Akkus empfohlen, könnte also auch gut sein, dass die Elektronik von normalen Batterien leicht verwirrt wird und zu falschen Ergebnissen kommt. Zumindest könnte das ebenfalls eine Rolle spielen, eventuell addieren sich die Effekte auch. Genaueres könnte man nur nach weiteren Experimenten sagen.
Vielleicht untersuche ich das mal näher, sobald das regelmäßig Rebooten der Sensoren anfängt mich zu nerven, und ich Zeit dafür finde.
-
@mickemup said in Tester Zigbee Adapter 3.x gesucht:
@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"?
Allgemein: Es mag durchaus sein, dass man ohne die regelmäßigen Meldungen ein paar Tage oder gar Wochen mehr Laufzeit rausholen kann, aber ich bevorzuge die Möglichkeit diese Updates zur Überwachung der Geräte nutzen zu können, im Gegensatz zu rein Ereignis-basierten Lebenszeichen. Ich habe bislang keine Gegenprobe angestellt, wie lange ein Gerät ohne die "device availability checks" durchhält, und um wie viel später man die Abwesenheit eines Gerätes bemerkt, wenn man keine regelmäßigen / verlässlichen Updates über die Link Quality erhält. Denn obwohl die batteriebetriebenen Geräte
batteryoderbattery_lowDatenpunkte haben (und diese mal mehr und mal weniger verlässlich melden), kommt es immer mal wieder vor, dass ein Gerät einfach keinen Pieps mehr sagt, weil die Batterie überraschend leer ist.Für Parasolls im speziellen: Die Parasoll sind bekannt dafür Batterien zu verschlingen. Ich bin nicht auf dem letzten Stand der Erkenntnisse, weil ich die entsprechenden Threads nicht aktiv verfolge, habe aber ein paar eigene Beobachtungen angestellt und Gegenmaßnahmen entwickelt. Ein Konsenz aus den Diskussionen ist die Parasolls mit Akkus zu betreiben. Meine Erfahrung kann das zumindest teilweise bestätigen: anfangs hatte ich normale Batterien eingesetzt und diese waren nach ca. 3-4 Tagen regelmäßig leer gesaugt. Mit Akkus komme ich mehrere Monate ohne Wechsel durch.
Allerdings gibt es dabei eine "kleine" Komplikation: alle 3-4 Tage fangen die Geräte an wie verrückt Updates zu senden. Manchmal sind es nurlink_qualityUpdates, manchmal sind esdevice announcements. Diese Updates haben eine deutlich höhere Frequenz (ca. all 10-30 Sekunden) im Vergleich zu den regulären Updates (alle 10 Minuten). Sobald die Geräte in diesen Modus verfallen sind sie nicht mehr wirklich funktionsbereit und senden keine Tür-Ereignisse mehr. Was dann hilft ist ein Reboot des Gerätes, sprich wenn mein Script erkennt, dass ein Gerät in diesen Zustand verfallen ist, dann bekomme ich eine Nachricht, gehe dann ans Gerät, entferne die Batterie für eine Sekunde und setze sie wieder ein. Danach "lebt" es wieder, und arbeitet wie gewohnt weiter. Das ist sicherlich keine dauerhafte Lösung, aber zumindest bekomme ich es mit, wenn ein Gerät den Abgang macht.
Ob die Update-Intervalle von 10 Minuten tatsächlich ursächlich für den regelmäßigen Schluckauf sind kann ich nicht 100% ausschließen, gfs. werde ich mal auf einen Custom-Converter setzen, der ein größeres Intervall für die Parasoll-Pings vorsieht.
Interessanterweise sind die Parasolls die einzigen Geräte, die diese Problematik entwickeln, Vallhorn, Somrig oder Badring haben solch ein Verhalten noch nicht an den Tag gelegt.Die Beobachtung (und die Benachrichtigungen) habe ich erst nach Wechsel auf Akkus gemacht, es ist sehr gut möglich, dass dies auch mit ein Grund für das Leersaugen von normalen Batterien ist. Möglicherweise würden diese auch länger durchhalten, wenn man den Problemzustand rechtzeitig bemerkt und durch Reboot gegenwirkt. Andererseits werden vom Hersteller Akkus empfohlen, könnte also auch gut sein, dass die Elektronik von normalen Batterien leicht verwirrt wird und zu falschen Ergebnissen kommt. Zumindest könnte das ebenfalls eine Rolle spielen, eventuell addieren sich die Effekte auch. Genaueres könnte man nur nach weiteren Experimenten sagen.
Vielleicht untersuche ich das mal näher, sobald das regelmäßig Rebooten der Sensoren anfängt mich zu nerven, und ich Zeit dafür finde.
-
@asgothian said in Tester Zigbee Adapter 3.x gesucht:
@alexhaxe frage dazu - welche Firmware haben die parasols ? Gibt es ggf. Ein Firmware Update?
alle mit 1.0.19. Bislang gibt es keine Updates, zumindest wird keines angeboten, wenn man "check firmware updates" im Adapter auslöst und das Gerät entsprechend wach hält. Ich konnte auch noch keinen Hinweis darauf finden, dass es eine neuere Version gibt.
-
@mickemup said in Tester Zigbee Adapter 3.x gesucht:
@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"?
Allgemein: Es mag durchaus sein, dass man ohne die regelmäßigen Meldungen ein paar Tage oder gar Wochen mehr Laufzeit rausholen kann, aber ich bevorzuge die Möglichkeit diese Updates zur Überwachung der Geräte nutzen zu können, im Gegensatz zu rein Ereignis-basierten Lebenszeichen. Ich habe bislang keine Gegenprobe angestellt, wie lange ein Gerät ohne die "device availability checks" durchhält, und um wie viel später man die Abwesenheit eines Gerätes bemerkt, wenn man keine regelmäßigen / verlässlichen Updates über die Link Quality erhält. Denn obwohl die batteriebetriebenen Geräte
batteryoderbattery_lowDatenpunkte haben (und diese mal mehr und mal weniger verlässlich melden), kommt es immer mal wieder vor, dass ein Gerät einfach keinen Pieps mehr sagt, weil die Batterie überraschend leer ist.Für Parasolls im speziellen: Die Parasoll sind bekannt dafür Batterien zu verschlingen. Ich bin nicht auf dem letzten Stand der Erkenntnisse, weil ich die entsprechenden Threads nicht aktiv verfolge, habe aber ein paar eigene Beobachtungen angestellt und Gegenmaßnahmen entwickelt. Ein Konsenz aus den Diskussionen ist die Parasolls mit Akkus zu betreiben. Meine Erfahrung kann das zumindest teilweise bestätigen: anfangs hatte ich normale Batterien eingesetzt und diese waren nach ca. 3-4 Tagen regelmäßig leer gesaugt. Mit Akkus komme ich mehrere Monate ohne Wechsel durch.
Allerdings gibt es dabei eine "kleine" Komplikation: alle 3-4 Tage fangen die Geräte an wie verrückt Updates zu senden. Manchmal sind es nurlink_qualityUpdates, manchmal sind esdevice announcements. Diese Updates haben eine deutlich höhere Frequenz (ca. all 10-30 Sekunden) im Vergleich zu den regulären Updates (alle 10 Minuten). Sobald die Geräte in diesen Modus verfallen sind sie nicht mehr wirklich funktionsbereit und senden keine Tür-Ereignisse mehr. Was dann hilft ist ein Reboot des Gerätes, sprich wenn mein Script erkennt, dass ein Gerät in diesen Zustand verfallen ist, dann bekomme ich eine Nachricht, gehe dann ans Gerät, entferne die Batterie für eine Sekunde und setze sie wieder ein. Danach "lebt" es wieder, und arbeitet wie gewohnt weiter. Das ist sicherlich keine dauerhafte Lösung, aber zumindest bekomme ich es mit, wenn ein Gerät den Abgang macht.
Ob die Update-Intervalle von 10 Minuten tatsächlich ursächlich für den regelmäßigen Schluckauf sind kann ich nicht 100% ausschließen, gfs. werde ich mal auf einen Custom-Converter setzen, der ein größeres Intervall für die Parasoll-Pings vorsieht.
Interessanterweise sind die Parasolls die einzigen Geräte, die diese Problematik entwickeln, Vallhorn, Somrig oder Badring haben solch ein Verhalten noch nicht an den Tag gelegt.Die Beobachtung (und die Benachrichtigungen) habe ich erst nach Wechsel auf Akkus gemacht, es ist sehr gut möglich, dass dies auch mit ein Grund für das Leersaugen von normalen Batterien ist. Möglicherweise würden diese auch länger durchhalten, wenn man den Problemzustand rechtzeitig bemerkt und durch Reboot gegenwirkt. Andererseits werden vom Hersteller Akkus empfohlen, könnte also auch gut sein, dass die Elektronik von normalen Batterien leicht verwirrt wird und zu falschen Ergebnissen kommt. Zumindest könnte das ebenfalls eine Rolle spielen, eventuell addieren sich die Effekte auch. Genaueres könnte man nur nach weiteren Experimenten sagen.
Vielleicht untersuche ich das mal näher, sobald das regelmäßig Rebooten der Sensoren anfängt mich zu nerven, und ich Zeit dafür finde.
@alexhaxe sagte in Tester Zigbee Adapter 3.x gesucht:
Was dann hilft ist ein Reboot des Gerätes, sprich wenn mein Script erkennt, dass ein Gerät in diesen Zustand verfallen ist, dann bekomme ich eine Nachricht, gehe dann ans Gerät, entferne die Batterie für eine Sekunde und setze sie wieder ein. Danach "lebt" es wieder, und arbeitet wie gewohnt weiter. Das ist sicherlich keine dauerhafte Lösung, aber zumindest bekomme ich es mit, wenn ein Gerät den Abgang macht.
Könntest du diese Skript zur Verfügung stellen?
Meine scheinen dem Batterieverschleiss Problem noch nicht verfallen zu sein, aber man weiss ja nie.
Betreibe meine bisher 3 Sensoren auch mit Akkus.
Bevor ich aufstocke, möchte ich aber sicher sein, dass die so tun wie ich will (Batstate updates usw) -
@alexhaxe sagte in Tester Zigbee Adapter 3.x gesucht:
Was dann hilft ist ein Reboot des Gerätes, sprich wenn mein Script erkennt, dass ein Gerät in diesen Zustand verfallen ist, dann bekomme ich eine Nachricht, gehe dann ans Gerät, entferne die Batterie für eine Sekunde und setze sie wieder ein. Danach "lebt" es wieder, und arbeitet wie gewohnt weiter. Das ist sicherlich keine dauerhafte Lösung, aber zumindest bekomme ich es mit, wenn ein Gerät den Abgang macht.
Könntest du diese Skript zur Verfügung stellen?
Meine scheinen dem Batterieverschleiss Problem noch nicht verfallen zu sein, aber man weiss ja nie.
Betreibe meine bisher 3 Sensoren auch mit Akkus.
Bevor ich aufstocke, möchte ich aber sicher sein, dass die so tun wie ich will (Batstate updates usw)@mickemup sagte in Tester Zigbee Adapter 3.x gesucht:
Meine scheinen dem Batterieverschleiss Problem noch nicht verfallen zu sein, aber man weiss ja nie.
welche Firmware hast du ?
-
@alexhaxe sagte in Tester Zigbee Adapter 3.x gesucht:
Was dann hilft ist ein Reboot des Gerätes, sprich wenn mein Script erkennt, dass ein Gerät in diesen Zustand verfallen ist, dann bekomme ich eine Nachricht, gehe dann ans Gerät, entferne die Batterie für eine Sekunde und setze sie wieder ein. Danach "lebt" es wieder, und arbeitet wie gewohnt weiter. Das ist sicherlich keine dauerhafte Lösung, aber zumindest bekomme ich es mit, wenn ein Gerät den Abgang macht.
Könntest du diese Skript zur Verfügung stellen?
Meine scheinen dem Batterieverschleiss Problem noch nicht verfallen zu sein, aber man weiss ja nie.
Betreibe meine bisher 3 Sensoren auch mit Akkus.
Bevor ich aufstocke, möchte ich aber sicher sein, dass die so tun wie ich will (Batstate updates usw)@mickemup said in Tester Zigbee Adapter 3.x gesucht:
Könntest du diese Skript zur Verfügung stellen?
Da ich meine Skripte in Haxe schreibe und erst vor dem Hochladen in iobroker zu Javascript kompiliere, ist der generierte Code nicht sonderlich übersichtlich oder lesbar, und damit für eine Anpassung an andere Systeme ungeeignet.
Ich plane meinen Haxe Code irgendwann mal als Bibliothek auf Github zu veröffentlichen, aber soweit ist er noch nicht ausgereift. -
@mickemup sagte in Tester Zigbee Adapter 3.x gesucht:
Meine scheinen dem Batterieverschleiss Problem noch nicht verfallen zu sein, aber man weiss ja nie.
welche Firmware hast du ?
@asgothian
date code:20230516
build:1.0.19 -
@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
sendToan den Zigbee Adapter die FunktionsendToZigbeemit 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 Datenpunktsend_payloadvom 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.
Mit folgenden JSON konnte ich den DP battery vom Parasoll aktualisieren.
{ "devId": "zigbee.0.d44867fffeb45110", "ep": "1", "cid": "genPowerCfg", "cmd": "read", "cmdType": "foundation", "zclData": { "batteryPercentageRemaining": {} }, "cfg": null }Methode: Fenster auf/zu zurück an Laptop und dann Triggern im Entwickler Tab.
Mit Blockly kriege ich es nicht hin, er schmeisst einige Fehler.
Obiges JSON habe ich per CopyPaste eingefügt.
Siehst grad den Fehler?
zigbee.0 2025-04-25 18:01:52.546 error Cannot read properties of undefined (reading 'replace') zigbee.0 2025-04-25 18:01:52.546 error TypeError: Cannot read properties of undefined (reading 'replace') at Developer.sendToZigbee (/opt/iobroker/node_modules/iobroker.zigbee/lib/developer.js:90:45) at Developer.onMessage (/opt/iobroker/node_modules/iobroker.zigbee/lib/developer.js:49:26) at Zigbee.emit (node:events:530:35) at Zigbee.emit (node:domain:489:12) at change (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/src/lib/adapter/adapter.ts:10953:34) at Immediate.<anonymous> (file:///opt/iobroker/node_modules/@iobroker/db-states-redis/src/lib/states/statesInRedisClient.ts:368:37) at processImmediate (node:internal/timers:483:21) zigbee.0 2025-04-25 18:01:52.480 error unhandled promise rejection: Cannot read properties of undefined (reading 'replace') zigbee.0 2025-04-25 18:01:52.480 error 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(). -
Mit folgenden JSON konnte ich den DP battery vom Parasoll aktualisieren.
{ "devId": "zigbee.0.d44867fffeb45110", "ep": "1", "cid": "genPowerCfg", "cmd": "read", "cmdType": "foundation", "zclData": { "batteryPercentageRemaining": {} }, "cfg": null }Methode: Fenster auf/zu zurück an Laptop und dann Triggern im Entwickler Tab.
Mit Blockly kriege ich es nicht hin, er schmeisst einige Fehler.
Obiges JSON habe ich per CopyPaste eingefügt.
Siehst grad den Fehler?zigbee.0 2025-04-25 18:01:52.546 error Cannot read properties of undefined (reading 'replace') zigbee.0 2025-04-25 18:01:52.546 error TypeError: Cannot read properties of undefined (reading 'replace') at Developer.sendToZigbee (/opt/iobroker/node_modules/iobroker.zigbee/lib/developer.js:90:45) at Developer.onMessage (/opt/iobroker/node_modules/iobroker.zigbee/lib/developer.js:49:26) at Zigbee.emit (node:events:530:35) at Zigbee.emit (node:domain:489:12) at change (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/src/lib/adapter/adapter.ts:10953:34) at Immediate.<anonymous> (file:///opt/iobroker/node_modules/@iobroker/db-states-redis/src/lib/states/statesInRedisClient.ts:368:37) at processImmediate (node:internal/timers:483:21) zigbee.0 2025-04-25 18:01:52.480 error unhandled promise rejection: Cannot read properties of undefined (reading 'replace') zigbee.0 2025-04-25 18:01:52.480 error 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().@mickemup Versuch mal bitte die andere Variante - mit dem Cluster und Attribute via read im send_payload. Es ist denkbar das die SendToZigbee Funktion buggy ist in der 2.x/3.x.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@mickemup Versuch mal bitte die andere Variante - mit dem Cluster und Attribute via read im send_payload. Es ist denkbar das die SendToZigbee Funktion buggy ist in der 2.x/3.x.
A.
@asgothian sagte in Tester Zigbee Adapter 3.x gesucht:
@mickemup Versuch mal bitte die andere Variante - mit dem Cluster und Attribute via read im send_payload. Es ist denkbar das die SendToZigbee Funktion buggy ist in der 2.x/3.x.
A.
mit diesem Payload funktioniert es
{ "read": { "cluster": "genPowerCfg", "attributes": ["batteryPercentageRemaining"] }}Danke für die rege Diskussion und die ganzen Tipps da lerne ich jeden Tag dazu
-
Hallo, ich habe vor kurzen auf 3.0 geupdatet und gerade auf 3.0.1 funktioniert auch alles mit ein paar Anlaufschwierigkeiten. Allerdings wollte ich einen Bewegungssensor den ich zum Test gekoppelt habe wieder entfernen.
zigbee.0 2025-04-25 20:27:17.997 error Failed to remove Error: AREQ - ZDO - mgmtLeaveRsp after 10000ms at Object.start (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/waitress.ts:67:23) at func (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:423:47) at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:36:20) at ZStackAdapter.sendZdoInternal (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:428:43) at ZStackAdapter.sendZdo (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:305:16) at Device.removeFromNetwork (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/model/device.ts:1125:30) at ZigbeeController.remove (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:736:21)
Kann ihn nicht mehr löschen.
-
Hallo, ich habe vor kurzen auf 3.0 geupdatet und gerade auf 3.0.1 funktioniert auch alles mit ein paar Anlaufschwierigkeiten. Allerdings wollte ich einen Bewegungssensor den ich zum Test gekoppelt habe wieder entfernen.
zigbee.0 2025-04-25 20:27:17.997 error Failed to remove Error: AREQ - ZDO - mgmtLeaveRsp after 10000ms at Object.start (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/waitress.ts:67:23) at func (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:423:47) at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:36:20) at ZStackAdapter.sendZdoInternal (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:428:43) at ZStackAdapter.sendZdo (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:305:16) at Device.removeFromNetwork (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/model/device.ts:1125:30) at ZigbeeController.remove (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:736:21)Kann ihn nicht mehr löschen.
-
@markus397 du musst den schon aufwecken damit du den so löschen kannst. Sonst gibt’s den Haken bei ‚löschen erzwingen#
A.
-
@asgothian Danke hat geklappt, hatte ich schon mal gemacht da ging es nicht. Komisch.
-
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.. ?
@arteck
Batterie getausch neu angelernt , interview erfolgreich
Interviewed:True, configured:True
Daten werden aber nicht empfangen nur wen ich über Entwickler und da die Werte auslese und dafür muss ich den Flower wach drücken. Funktioniert mit den anderen 6 stk ohne Probleme da muss ich den Flower NICHT wach drücken. Habe noch einen weiteren Flower als Reserve und mit dem genau das gleiche (wach drücken sonst keine werte) Firmware bei allen Aktuel -
@mickemup Versuch mal bitte die andere Variante - mit dem Cluster und Attribute via read im send_payload. Es ist denkbar das die SendToZigbee Funktion buggy ist in der 2.x/3.x.
A.
-
Known bugs:
- Fehlende Bilder im Hardware-Tab. Diese sind beim Übergang von meinem Test-System ins main-repository auf der Strecke geblieben. Wird behoben in 3.0.2
Weiteres
Hier werden geplante Neuerungen des Adapters aufgeführt (und ihr Erfolg)
Weitere Vorschläge zu systematischen Änderungen bitte gerne im Thread posten - wenn ich diese angehen will landen sie hier.Wichtig: Alles was hier steht kann und soll diskutiert werden. Es ist die Liste der Punkte die bei mir anstehen. Wenn da etwas steht was so als schlecht empfunden wird, schreibt das bitte. Ich sehe das nicht als Kritik sondern als Diskussion dazu wie der Adapter besser werden kann.
-
Definition von Device-Bildern über 'externe Konverter'
Stand: Initial implementiert - muss getestet werden. Bilder als Link sollten gehen, Bilder als base64 String sind ungetestet.
-- in der JS Datei des externen Konverters kann alsicon: '<pfad zum icon>ein Bild vorgegeben werden - als Link oder als base64 kodiertes Bild. Dieses soll im Adapter übernommen werden. Beispiele dafür gibt es unter :https://github.com/inventwo/custom-zigbee (nebenbei - ich kann bestätigen das die meisten Konverter aus diesem Projekt auch im Zigbee-Adapter gehen sollten. -
KonfigurationsDP für Gruppen
Stand: in Planung:
-- Gruppenstatus basierend auf Mitgliederstatus
-- eingrenzen von Gruppenfunktion (Datenpunkte die die Gruppe liefert)
-- Option zur erzwungenen Aktualisierung aller Mitglieder basierend auf Gruppenstatus. -
Änderung bei den Gerätekacheln (Die Kacheln sind generell zu voll, und mit zu vielen Dingen belastet die wenig Sinn machen):
--Enum-States mit genau 1 Auswahlmöglichkeit werden von den Gerätekacheln entferntDone (3.0.1)
--Text-States ohne Auswahl / Eingabemöglichkeit werden von den Gerätekacheln entferntDone (3.0.1)
--Numerische States ohne min/max werden von den Device-Kacheln entferntDone (3.0.1)
-- Numerische States mit min/max werden als slider mit Nummer auf den Kacheln dargestellt, wobei die Nummer nur Anzeige ist -- Aktuell nicht zu realisieren, daher sind dieser States in 3.0.1 ausgeblendet.
--Slider deren Werte-Bereich um 0 geht bekommen ein 'bias' auf 0, um das Einstellen von genau 0 zu vereinfachen.nicht mit akzeptablem Aufwand zu realisieren
--Denkbar: UI zur Auswahl der auf der Kachel sichtbaren Elemente, basierend auf Gerätetyp oder Gerät.Shelved - keinerlei Echo auf diese Planung. Keine Umsetzung in 3.x
A.
@asgothian bin auf der 3.01 habe keine Probleme alles läuft sehr gut und stabil. Vielen lieben Dank für deine Mühe.
Zu den Kacheln kann ich sagen das ich es gut finde wenn du sie ausdünnen tust.
Herzliche Grüße
Fabio -
@asgothian bin auf der 3.01 habe keine Probleme alles läuft sehr gut und stabil. Vielen lieben Dank für deine Mühe.
Zu den Kacheln kann ich sagen das ich es gut finde wenn du sie ausdünnen tust.
Herzliche Grüße
Fabio
Support us
605
Online32.4k
Users81.3k
Topics1.3m
Posts