Tester wanted - Zigbee Adapter 3.1

[Thomas Braun]

@flugschüler sagte in Tester wanted - Zigbee Adapter 3.1:

Soll ich den Adapter jetzt über git installiert lassen?

Ja. Wenn irgendwann über dein bevorzugtes Repository eine Version größer als die jetzige angeboten wird kommt die dann über deine regelmäßige Systempflege auf die Kiste.

[Flugschüler]

@thomas-braun Ihr seid die besten

[dimaiv]

@asgothian sagte in Tester wanted - Zigbee Adapter 3.1:

@dimaiv kannst du folgendes machen:

• die aktuelle Github version installieren
• nach dem Start eine ts0121 plug auf debug setzen
• ein Device Query machen
• Dann das Debug interface öffnen
  
• mit dem button 1 aus dem Screenshot die Daten aktualisieren
• in jeder Zeile bei incoming messages mit dem blauen Button 2 die Meldungen öffnen
• aus dem Dialog heraus kopieren und hier Posten ?

Danke.

A.

I01: Zigbee Event of Type readResponse from device 0x60a423fffe61dd4a, incoming event: {"type":"readResponse","data":{"tuyaBacklightMode":1},"linkquality":87,"groupID":0,"cluster":"genOnOff","meta":{"rawData":{"type":"Buffer","data":[24,8,1,1,128,0,48,1]},"zclTransactionSequenceNumber":8,"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0}},"endpoint_id":1}
I02: 3 converters available for 'TS0121_plug' '60a423fffe61dd4a' with cluster 'genOnOff' and type 'readResponse'
I03: message received '{"linkquality":87}' from device 60a423fffe61dd4a type 'TS0121_plug'
I04: value generated '87' from device 60a423fffe61dd4a for 'Link quality'
I02.1a: converter 1 : Cluster genOnOff
I02.0b: data: {"tuyaBacklightMode":1} options: {} meta:{"deviceIEEE":"0x60a423fffe61dd4a","logger":"StatesController","state":{"state":""}} result:undefined
I02.2a: converter 2 : Cluster genOnOff
I02.1b: data: {"tuyaBacklightMode":1} options: {} meta:{"deviceIEEE":"0x60a423fffe61dd4a","logger":"StatesController","state":{"state":""}} result:undefined
I02.3a: converter 3 : Cluster genOnOff
I02.2b: data: {"tuyaBacklightMode":1} options: {} meta:{"deviceIEEE":"0x60a423fffe61dd4a","logger":"StatesController","state":{"state":""}} result:{"indicator_mode":"off/on"}
I02.3c: candidates: [{},{},{"indicator_mode":"off/on"}] => payload {"indicator_mode":"off/on"}
I03-1: message received '{"indicator_mode":"off/on"}' from device 60a423fffe61dd4a type 'TS0121_plug'
I04-1: value generated '"off/on"' from device 60a423fffe61dd4a for 'LED indicator mode'

I01: Zigbee Event of Type readResponse from device 0x60a423fffe61dd4a, incoming event: {"type":"readResponse","data":{"moesStartUpOnOff":0},"linkquality":87,"groupID":0,"cluster":"genOnOff","meta":{"rawData":{"type":"Buffer","data":[24,7,1,2,128,0,48,0]},"zclTransactionSequenceNumber":7,"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0}},"endpoint_id":1}
I02: 3 converters available for 'TS0121_plug' '60a423fffe61dd4a' with cluster 'genOnOff' and type 'readResponse'
I03: message received '{"linkquality":87}' from device 60a423fffe61dd4a type 'TS0121_plug'
I04: value generated '87' from device 60a423fffe61dd4a for 'Link quality'
I02.1a: converter 1 : Cluster genOnOff
I02.0b: data: {"moesStartUpOnOff":0} options: {} meta:{"deviceIEEE":"0x60a423fffe61dd4a","logger":"StatesController","state":{"state":""}} result:undefined
I02.2a: converter 2 : Cluster genOnOff
I02.1b: data: {"moesStartUpOnOff":0} options: {} meta:{"deviceIEEE":"0x60a423fffe61dd4a","logger":"StatesController","state":{"state":""}} result:{"power_outage_memory":"off"}
I02.3a: converter 3 : Cluster genOnOff
I02.2b: data: {"moesStartUpOnOff":0} options: {} meta:{"deviceIEEE":"0x60a423fffe61dd4a","logger":"StatesController","state":{"state":""}} result:undefined
I02.3c: candidates: [{},{"power_outage_memory":"off"},{}] => payload {"power_outage_memory":"off"}
I03-1: message received '{"power_outage_memory":"off"}' from device 60a423fffe61dd4a type 'TS0121_plug'
I04-1: value generated '"off"' from device 60a423fffe61dd4a for 'Recover state after power outage'

I01: Zigbee Event of Type readResponse from device 0x60a423fffe61dd4a, incoming event: {"type":"readResponse","data":{"onOff":0},"linkquality":87,"groupID":0,"cluster":"genOnOff","meta":{"rawData":{"type":"Buffer","data":[24,6,1,0,0,0,16,0]},"zclTransactionSequenceNumber":6,"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0}},"endpoint_id":1}
I02: 3 converters available for 'TS0121_plug' '60a423fffe61dd4a' with cluster 'genOnOff' and type 'readResponse'
I03: message received '{"linkquality":87}' from device 60a423fffe61dd4a type 'TS0121_plug'
I04: value generated '87' from device 60a423fffe61dd4a for 'Link quality'
I02.1a: converter 1 : Cluster genOnOff
I02.0b: data: {"onOff":0} options: {} meta:{"deviceIEEE":"0x60a423fffe61dd4a","logger":"StatesController","state":{"state":""}} result:{"state":"OFF"}
I02.2a: converter 2 : Cluster genOnOff
I02.1b: data: {"onOff":0} options: {} meta:{"deviceIEEE":"0x60a423fffe61dd4a","logger":"StatesController","state":{"state":""}} result:undefined
I02.3a: converter 3 : Cluster genOnOff
I02.2b: data: {"onOff":0} options: {} meta:{"deviceIEEE":"0x60a423fffe61dd4a","logger":"StatesController","state":{"state":""}} result:undefined
I02.3c: candidates: [{"state":"OFF"},{},{}] => payload {"state":"OFF"}
I03-1: message received '{"state":"OFF"}' from device 60a423fffe61dd4a type 'TS0121_plug'
I04-1: value generated 'false' from device 60a423fffe61dd4a for 'On/off state of the switch'

P.S.: ich glaube, die weiteren Daten bei diesen Steckdosen wurden immer gepoolt, und jetzt passiert es nicht.

[dimaiv]

@asgothian
Was mir noch aufgefallen:

Mit 3.1.2 kann ich über:

sendToZigbee { "id": "zigbee.0.842e14fffedb8ae5", "ep": "1", "cid": "haElectricalMeasurement", "cmd": "read", "cmdType": "foundation", "zclData": { "activePower": {} } }

Die weiteren Daten abrufen.

Mit 3.1.3 von jetzt funktioniert es nicht.

Das sind 2 absolut gleiche Steckdosen, unterschiedliche Installationen.

[Asgothian]

@dimaiv sagte in Tester wanted - Zigbee Adapter 3.1:

P.S.: ich glaube, die weiteren Daten bei diesen Steckdosen wurden immer gepoolt, und jetzt passiert es nicht.

Sind die Meldungen nach einem Device_query, oder kommen die normal so ?

@dimaiv sagte in Tester wanted - Zigbee Adapter 3.1:

Was mir noch aufgefallen:
Mit 3.1.2 kann ich über:
sendToZigbee { "id": "zigbee.0.842e14fffedb8ae5", "ep": "1", "cid": "haElectricalMeasurement", "cmd": "read", "cmdType": "foundation", "zclData": { "activePower": {} } }
Die weiteren Daten abrufen.
Mit 3.1.3 von jetzt funktioniert es nicht.

Danke für den Hinweis - ich hab im Hintergrund einiges Optimiert.

A.

[dimaiv]

@asgothian sagte in Tester wanted - Zigbee Adapter 3.1:

Sind die Meldungen nach einem Device_query, oder kommen die normal so ?

A.

Die Meldungen sind nach einem Device_query, aber auch normal kommen nur die.

[Asgothian]

@dimaiv Ok, danke. Da scheint ein Konverter geändert - da muss ich im Detail graben, und Dir eine extra version machen. Wird aber etwas dauern.

A.

[Asgothian]

@asgothian Zumindest der Developer Tab sollte jetzt wieder funktionieren.

Kannst du versuchen was passiert wenn du damit versuchst die Daten abzurufen ? Ob dann eine Meldung rein kommt ?

Interessant ist was genau an Antwort auf den Read Request rein kommt, wenn überhaupt etwas.

A.

[dimaiv]

@asgothian sagte in Tester wanted - Zigbee Adapter 3.1:

@asgothian Zumindest der Developer Tab sollte jetzt wieder funktionieren.

Kannst du versuchen was passiert wenn du damit versuchst die Daten abzurufen ? Ob dann eine Meldung rein kommt ?

Interessant ist was genau an Antwort auf den Read Request rein kommt, wenn überhaupt etwas.

A.

Über Entwikler Tab funktioniert jetzt:

I01: Zigbee Event of Type readResponse from device 0x60a423fffe61dd4a, incoming event: {"type":"readResponse","data":{"activePower":0},"linkquality":51,"groupID":0,"cluster":"haElectricalMeasurement","meta":{"rawData":{"type":"Buffer","data":[24,8,1,11,5,0,41,0,0]},"zclTransactionSequenceNumber":8,"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0}},"endpoint_id":1}
I02: 1 converter available for 'TS0121_plug' '60a423fffe61dd4a' with cluster 'haElectricalMeasurement' and type 'readResponse'
I03: message received '{"linkquality":51}' from device 60a423fffe61dd4a type 'TS0121_plug'
I04: value generated '51' from device 60a423fffe61dd4a for 'Link quality'
I02.1a: converter 1 : Cluster haElectricalMeasurement
I02.0b: data: {"activePower":0} options: {} meta:{"deviceIEEE":"0x60a423fffe61dd4a","logger":"StatesController","state":{"state":""}} result:{"power":0}
I02.1c: candidates: [{"power":0}] => payload {"power":0}
I03-1: message received '{"power":0}' from device 60a423fffe61dd4a type 'TS0121_plug'
I04-1: value generated '0' from device 60a423fffe61dd4a for 'Load power'

Uber die Scripte stürzt aber der Adapter ab mit folgender Meldung:

2025-09-21 21:40:50.830 - info: javascript.0 (942) script.js.Plug_abfragen: start JavaScript (Blockly)
2025-09-21 21:40:50.842 - info: javascript.0 (942) script.js.Plug_abfragen: registered 0 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions
2025-09-21 21:40:55.849 - error: zigbee.0 (282446) 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-21 21:40:55.851 - error: zigbee.0 (282446) unhandled promise rejection: Cannot read properties of undefined (reading 'replace')
2025-09-21 21:40:56.167 - error: zigbee.0 (282446) 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: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-21 21:40:56.168 - error: zigbee.0 (282446) Cannot read properties of undefined (reading 'replace')
2025-09-21 21:40:56.193 - info: zigbee.0 (282446) Halting zigbee adapter. Restart delay is at least 30 seconds.
2025-09-21 21:40:56.193 - info: zigbee.0 (282446) cleaning everything up...
2025-09-21 21:40:56.196 - info: zigbee.0 (282446) Saved local configuration data
2025-09-21 21:40:56.227 - warn: zigbee.0 (282446) ELEVATED:I03 (2e22) message received '{"available":false}' from device 60a423fffe61dd4a type 'TS0121_plug'
2025-09-21 21:40:56.228 - warn: zigbee.0 (282446) ELEVATED:I04 (2e22) value generated 'false' from device 60a423fffe61dd4a for 'Available'
2025-09-21 21:40:56.229 - warn: zigbee.0 (282446) ELEVATED:I03 (2e22) message received '{"linkquality":0}' from device 60a423fffe61dd4a type 'TS0121_plug'
2025-09-21 21:40:56.230 - warn: zigbee.0 (282446) ELEVATED:I04 (2e22) value generated '0' from device 60a423fffe61dd4a for 'Link quality'
2025-09-21 21:40:56.586 - info: zigbee.0 (282446) Closing Zigbee network, 0 seconds remaining
2025-09-21 21:40:57.195 - warn: zigbee.0 (282446) Terminated (UNCAUGHT_EXCEPTION): Without reason
2025-09-21 21:40:57.783 - 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-21 21:40:57.784 - error: host.GartenIoB Caught by controller[2]: TypeError: Cannot read properties of undefined (reading 'replace')
2025-09-21 21:40:57.784 - error: host.GartenIoB Caught by controller[2]: at Developer.sendToZigbee (/opt/iobroker/node_modules/iobroker.zigbee/lib/developer.js:90:45)
2025-09-21 21:40:57.784 - error: host.GartenIoB Caught by controller[2]: at Developer.onMessage (/opt/iobroker/node_modules/iobroker.zigbee/lib/developer.js:49:26)
2025-09-21 21:40:57.784 - error: host.GartenIoB Caught by controller[2]: at Zigbee.emit (node:events:536:35)
2025-09-21 21:40:57.785 - error: host.GartenIoB Caught by controller[2]: at Zigbee.emit (node:domain:489:12)
2025-09-21 21:40:57.785 - 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-21 21:40:57.785 - 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-21 21:40:57.785 - error: host.GartenIoB Caught by controller[2]: at processImmediate (node:internal/timers:483:21)
2025-09-21 21:40:57.785 - error: host.GartenIoB instance system.adapter.zigbee.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
2025-09-21 21:40:57.785 - info: host.GartenIoB Restart adapter system.adapter.zigbee.0 because enabled
2025-09-21 21:41:01.905 - info: javascript.0 (942) script.js.Plug_abfragen: Stopping script

Blockly=>JS:

var Intervall;

// Beschreibe diese Funktion …
async function Power() {
  sendTo('zigbee.0', 'sendToZigbee', {
    'parameter': { "id": "zigbee.0.60a423fffe61dd4a", "ep": "1", "cid": "haElectricalMeasurement", "cmd": "read", "cmdType": "foundation", "zclData": { "activePower": {} } },
  });
}


Intervall = setInterval(async () => {
  await Power();
}, 5000);

Mit 3.1.2 funktionieren beide Variante.

[Asgothian]

@dimaiv Danke fürs Testen - ich schau mir das morgen an

[Asgothian]

@dimaiv sagte in Tester wanted - Zigbee Adapter 3.1:

sendTo('zigbee.0', 'sendToZigbee', { 'parameter': { "id": "zigbee.0.60a423fffe61dd4a", "ep": "1", "cid": "haElectricalMeasurement", "cmd": "read", "cmdType": "foundation", "zclData": { "activePower": {} } }, });

Diese Methode die Funktion aufzurufen ist auf Dauer instabil - sie basiert darauf das interne Funktionen nicht geändert werden. Bitte teste, ob mit einer der 3.X Versionen der folgende Payload in send_payload das gewünschte Ergebnis bringt. Dieses ist als Ersatz für das 'sendToZigbee' implementiert worden

{
  "read": {
    "cluster": "haElectricalMeasurement",
    "attributes": [
      "activePower"
    ]
  }
}

Nachtrag:

bist du sicher das dieser Code in 3.0.5 wirklich geht ?

var Intervall;
 
// Beschreibe diese Funktion …
 async function Power() {
   sendTo('zigbee.0', 'sendToZigbee', {
     'parameter': { "id": "zigbee.0.60a423fffe61dd4a", "ep": "1", "cid": "haElectricalMeasurement", "cmd": "read", "cmdType": "foundation", "zclData": { "activePower": {} } },
   });
 }
  
  
 Intervall = setInterval(async () => {
   await Power();
 }, 5000);

Hintergrund - es gab eine Anpassung am Blockly SendTo Block. Wo der vorher den Code

sendTo('zigbee.0', 'sendToZigbee', {"id": "zigbee.0.00be44fffeab0b87", "ep": "1", "cid": "haElectricalMeasurement", "cmd": "read", "cmdType": "foundation", "zclData": { "activePower": {} } },
);

als Standard erzeugt hat, macht er jetzt

 sendTo('zigbee.0', 'sendToZigbee', {
     'parameter': { "id": "zigbee.0.60a423fffe61dd4a", "ep": "1", "cid": "haElectricalMeasurement", "cmd": "read", "cmdType": "foundation", "zclData": { "activePower": {} } },
   });

mit dem Standard Block. Um die alte Version zurück zu bekommen muss man den Namen der Variable im Block löschen.

Blockly Skript zum importieren als Beispiel:

<xml xmlns="https://developers.google.com/blockly/xml">
  <block type="sendto_custom" id="+%Nw$~nnCWC@TlZQZ~]8" x="212" y="138">
    <mutation xmlns="http://www.w3.org/1999/xhtml" items="parameter"></mutation>
    <field name="INSTANCE">zigbee.0</field>
    <field name="COMMAND">sendToZigbee</field>
    <field name="LOG"></field>
    <field name="WITH_STATEMENT">FALSE</field>
    <value name="ARG0">
      <shadow type="text" id="](`*pMFJEuOLTeBJ5hZF">
        <field name="TEXT">{"id": "zigbee.0.00be44fffeab0b87", "ep": "1", "cid": "haElectricalMeasurement", "cmd": "read", "cmdType": "foundation", "zclData": { "activePower": {} } }</field>
      </shadow>
    </value>
    <next>
      <block type="sendto_custom" id="1o#t?S/@4Z_1R7G/YxW3">
        <mutation xmlns="http://www.w3.org/1999/xhtml" items=""></mutation>
        <field name="INSTANCE">zigbee.0</field>
        <field name="COMMAND">sendToZigbee</field>
        <field name="LOG"></field>
        <field name="WITH_STATEMENT">FALSE</field>
        <value name="ARG0">
          <shadow type="text" id="O`S)U?JPvg=x#CYYZI*r">
            <field name="TEXT">{"id": "zigbee.0.00be44fffeab0b87", "ep": "1", "cid": "haElectricalMeasurement", "cmd": "read", "cmdType": "foundation", "zclData": { "activePower": {} } }</field>
          </shadow>
        </value>
      </block>
    </next>
  </block>
</xml>

[dimaiv]

@asgothian
Deine Blockly ist absolut identisch mit dem was ich oben gepostet habe, nur bei mir ist SendTo in eine funktion gepackt und anderes exportiert.
Aber es macht nix, beide Varianten bringen 3.1.3 zum Absturz, und mit 3.1.2 aus latest funktionieren einwandfrei.
Aber, das ist jetz auch egal, weil, Variante über send_payload funktioniert auch bei 3.1.3 , und ist einfacher einzurichten bei mehreren Steckdosen.

Hoffentlich, muss man es ab jetzt, nich dauerhaft benutzen und überall einrichten , und es wird, wie vorher, von alleine über Converter (Pooling) funktionieren .

P.S.: Problem mit send_payload bei SWV bin ich auch betroffen, aber ich verfolge es auf Git. Falls hier was zum testen gibt, oder du das Ventil zum debuggen haben möchtest/muss, sag Bescheid.

[Asgothian]

Es gibt eine neue Version auf Github: 3.1.2-alpha-4.

Folgende Anpassungen sollten da drin sein:

• Fix für 'onEvent' Polling: Sollte diesen Issue (GitHub link) schliessen: (sowie die Probleme vor @dimaiv)
• Fix für 'no configure on pairing' - neu dem Netzwerk hinzugefügte Devices sollten automatisch Konfiguriert werden.
• Netzwerk am Router öffnen - da der ZH diese Funktion wieder bietet, ist sie (hoffentlich) auch wieder verfügbar. Ich kann das nur bedingt testen.
  
• Icon download button in der Konfiguration des Adapters. Notwendig wenn ein Upload gemacht wird ohne den Adapter neu zu starten.
  
• Neue Optionen (grün: verifiziert, Orange: Bedarf Tests die ich mangels Gerät aktuell nicht durchführen kann)
  
  -- Active availability check. Wie in diesem Issue (GitHub link) zu sehen scheint der ZHC Ping nicht immer gut zu laufen. Deswegen gibt es jetzt im Adapter wählbare alternative Methoden (incl. 'off')
  -- Time between activity Checks: Dieses ist eine Maximalzeit zwischen Ping Versuchen. Es gibt interne Verrechnungen abhängig davon wie viele Devices im Netz sind, wie oft ein Device nicht erreicht werden konnte und diese Zahl. Je höher die Zahl desto seltener wird jedes Device abgefragt.
  -- List devices at Start: Aktiviert / Deaktivert die lange Liste an aktiven Geräten und Gruppen bei Adapter-Start.
  -- try to read all states at adapter start: Dient dazu beim Start des Adapters zu versuchen den Status im ioBroker mit dem der Geräte zu synchronisieren. Kann bei grossen Netzen Problematisch werden. Dazu gehört: delay in seconds - die Verzögerung zwischen Adapter-Start und dem Start des Abfrage aller Geräte.
  -- Read States at device announce: Wenn ein Gerät sich am Netzwerk 'zurück' meldet (xxx has announced itself) wird ein Device-Query für das Device ausgelöst um dessen Status zu ermitteln.
  -- use channel for complex exposes: Dies ist eine zukünftige Entwicklung. Es gibt bei bestimmten Geräten Datenpuntke die eigentlich nur gemeinsam gesetzt werden dürfen. Ein Beispiel dafür sind Farben mit r, g, b - die schon als Channels angeboten werden. Dabei passiert folgendes:
  -- wird einer der States im Channel verändert so wird ein timeout gestartet. Bei Ablauf des Timeout werden alle eingetragenen Werte genommen und in einem Payload an das Gerät gesandt. Dabei ist die Zeit für den Timeout abhängig davon ob die Änderung 'manuell' im Admin passiert oder nicht. Im Admin liegt der Timeout zwischen 2.5 und 5 sekunden. Ausserhalb des Admin sind es 100 - 250 ms. Durch weitere Tests können sich diese Zahlen noch ändern.
• Veränderungen an der Netzwerk-Karte: Der vorherige Regenerate button (blau) wurde durch einen grünen Reload button ersetzt. Dieser lädt eine bereits generierte Map vom Adapter anstatt diese neu vom Netzwerk anzufragen. Um eine Map vollständig neu aufzubauen gibt es in den Map-Einstellungen einen eigenen Button:
  
• via den 'zigbee subsystem error' Anzeiger kann das Zigbee-Subsystem nun direkt gestartet werden, ohne auf die Hardware-seite zu gehen. Dieser button ist auch im Tab sichtbar wenn das Zigbee-System nicht läuft aber der Adapter schon.
• Die Koordinator-Karte zeigt jetzt nicht nur an ob der Koordinator ansprechbar ist, sondern auch ob der Haken zum automatischen Start des Zigbee Subsystems gesetzt ist:
  --Haken gesetzt:
  -- Haken nicht gesetzt:
• developer modus gefixed - sollte sauber gehen.
• Gruppen aus der Auswahl im Developer Modus entfernt, da die Funktionalität so nicht nutzbar ist.

[Asgothian]

@dimaiv sagte in Tester wanted - Zigbee Adapter 3.1:

@asgothian
Deine Blockly ist absolut identisch mit dem was ich oben gepostet habe, nur bei mir ist SendTo in eine funktion gepackt und anderes exportiert.
Aber es macht nix, beide Varianten bringen 3.1.3 zum Absturz, und mit 3.1.2 aus latest funktionieren einwandfrei.
Aber, das ist jetz auch egal, weil, Variante über send_payload funktioniert auch bei 3.1.3 , und ist einfacher einzurichten bei mehreren Steckdosen.

Hoffentlich, muss man es ab jetzt, nich dauerhaft benutzen und überall einrichten , und es wird, wie vorher, von alleine über Converter (Pooling) funktionieren .

Bist du sicher das die den gleichen Code erzeugen ? Bei mir tun sie das nicht, und der von mir gepostetete code

sendTo('zigbee.0', 'sendToZigbee', {"id": "zigbee.0.00be44fffeab0b87", "ep": "1", "cid": "haElectricalMeasurement", "cmd": "read", "cmdType": "foundation", "zclData": { "activePower": {} } },
);

sollte auch mit der aktuellen 3.1.3 laufen.

Aber:

Es gibt inzwischen eine 3.1.3-alpha-4, damit sollte hoffentlich das polling wieder laufen.

A.

[dimaiv]

@asgothian
Adapter 3.1.3 alpha 4 stürzt sofort ab.