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

[paul53]

@david-g sagte: Am ehsten im Javascript Adapter oder?

Eher nicht. Es muss ein besonderes Verhalten des Datenpunktes des Watcher-Adapters sein. Hat er ein state.expire?

[Codierknecht]

@david-g
Ich hab' noch 'ne andere Idee:
Für meine Offline-Warnung triggere ich auf "offlineCount".
Wenn sich das ändert, lese ich den Inhalt von "offlineList" und arbeite die ab.

Das ließe sich mit wenig Aufwand auf "lowBattery" ummodeln.

var active = false;
var timeout;

on({id: "device-watcher.0.offlineCount", change: "ne"}, async function (obj) {

    (function () {if (timeout) {clearTimeout(timeout); timeout = null;}})(); // alle laufenden Timer beenden

    // die eigentliche Prüfung erfolgt erst nach einem Timeout von 60 Sekunden,
    // damit kurzzeitige Ausfälle nicht gemeldet werden müssen
    timeout = setTimeout(async function () {
        var offlineCount = obj.state.val;
        if (offlineCount > 0) {
            active = true;
            var devices = getState("device-watcher.0.offlineList").val;
            var message = 'ACHTUNG: ' + offlineCount + ' Gerät(e) offline:\n';
            for (var i = 0; i < devices.length; i++) {
                message += devices[i].Device + '\n';
            }
        } else {
            if (active) message = 'Alle Geräte sind online!';
            active = false;
        }
        sendSignalMessage(message, mobileNumber);
    }, 60000);

});

[David G.]

@paul53

Wie kann ich das prüfen?
Sonst müsste @ciddi89 mal nach schauen.

[Ein ehemaliger Benutzer]

@codierknecht man sieht schon am Zeitstempel ‚zuletzt geändert‘ das sich da inhaltlich nichts geändert hat sondern nur aktualisiert wurde. Daher sollte der trigger garnicht auslösen. Wäre interessant zu wissen ob es auch bei anderen Datenpunkten der Fall ist oder nur hier. Habt ihr mal den Export blockly für mich damit ich auch mal testen kann?

[Codierknecht]

@ciddi89

<xml xmlns="https://developers.google.com/blockly/xml">
  <variables>
    <variable id="bhZlx3!hSc?sjp*V4Q`E">liste</variable>
    <variable id="4)UVHmM{XPXRM28y.|3,">obj</variable>
  </variables>
  <block type="on" id="YgiA/=!`3gaZ_y1oWYQO" x="88" y="213">
    <field name="OID">device-watcher.0.lowBatteryList</field>
    <field name="CONDITION">ne</field>
    <field name="ACK_CONDITION"></field>
    <statement name="STATEMENT">
      <block type="variables_set" id="shOIp|-,)1QyBw~ccrcx">
        <field name="VAR" id="bhZlx3!hSc?sjp*V4Q`E">liste</field>
        <value name="VALUE">
          <block type="on_source" id="~4{dPD;LII$3v]wtj)bc">
            <field name="ATTR">state.val</field>
          </block>
        </value>
        <next>
          <block type="controls_forEach" id="`1%S^g=$~m-2@5V,2A%A">
            <field name="VAR" id="4)UVHmM{XPXRM28y.|3,">obj</field>
            <value name="LIST">
              <block type="variables_get" id="Hl{8^KvH+5Ds4lf+1u2n">
                <field name="VAR" id="bhZlx3!hSc?sjp*V4Q`E">liste</field>
              </block>
            </value>
            <statement name="DO">
              <block type="debug" id="~Ut55bl(S:!f-?%BQ=tT">
                <field name="Severity">log</field>
                <value name="TEXT">
                  <shadow type="text" id="}7jzalime5-*9Xp:(4ZG">
                    <field name="TEXT">test</field>
                  </shadow>
                  <block type="get_attr" id="2N7H,vR6SLlKD2a8^lYi">
                    <value name="PATH">
                      <shadow type="text" id="xn}WN)W^k|V=L)9^Lu47">
                        <field name="TEXT">Device</field>
                      </shadow>
                    </value>
                    <value name="OBJECT">
                      <block type="variables_get" id="OPi.o}#]R0i}=KM|Y-Lv">
                        <field name="VAR" id="4)UVHmM{XPXRM28y.|3,">obj</field>
                      </block>
                    </value>
                  </block>
                </value>
              </block>
            </statement>
          </block>
        </next>
      </block>
    </statement>
  </block>
</xml>

Edit: Nochmal korrigiert, da noch die Prüfung drin war.

[David G.]

@ciddi89

In meinem Eingangspost.

@paul53 hatte noch eine Frage.
Kann ich aber nichts mit anfangen.....

@paul53 sagte in Skript löst "fälschlicherweise" aus:

@david-g sagte: Am ehsten im Javascript Adapter oder?

Eher nicht. Es muss ein besonderes Verhalten des Datenpunktes des Watcher-Adapters sein. Hat er ein state.expire?

[Codierknecht]

@ciddi89
Das ist das Ergebnis:

Edit: Aktualisierungsintervall des Adapters steht auf 30 Sekunden!

[Ein ehemaliger Benutzer]

@david-g ne hat er nicht. Und alle Datenpunkte werden gleich erstellt. Daher codemäßig ist da kein unterschied.

[paul53]

@codierknecht sagte: Das ist das Ergebnis:

Teste mal mit:

on('device-watcher.0.lowBatteryList', function(dp) {
    log(dp.oldState);
    log(dp.state);
});

[Ein ehemaliger Benutzer]

@paul53 said in Skript löst "fälschlicherweise" aus:

                                                                                                                            on('device-watcher.0.lowBatteryList', function(dp) {                                                                                                                                                                                log(dp.oldState);                                                                                                                                                                                log(dp.state);                                                                                                                                                                            });

23:42:57.860	info	javascript.0 (544) script.js.Vorlagen.Skript_1: {'val':[{'Device':'Büro Bewegungsmelder','Adapter':'Zigbee2MQTT','Battery':'21%'}],'ts':1676500962641,'ack':true,'lc':1676499209986,'from':'system.adapter.device-watcher.0','q':0,'user':'system.user.admin'}
23:42:57.860	info	javascript.0 (544) script.js.Vorlagen.Skript_1: {'val':[{'Device':'Büro Bewegungsmelder','Adapter':'Zigbee2MQTT','Battery':'21%'}],'ts':1676500977819,'ack':true,'lc':1676499209986,'from':'system.adapter.device-watcher.0','q':0,'user':'system.user.admin'}

[paul53]

@ciddi89
Außer ts alles identisch, also hätte nicht getriggert werden dürfen.

[Ein ehemaliger Benutzer]

@paul53 ja mein reden. Das ist wirklich sehr merkwürdig.

[David G.]

Im Admin leuchten bei mir auch alle 10sek 4 Datenpunkte (wo es auch Sinn macht) grün auf.

Der hier betroffene ist nicht bei.

Somit scheint ja "theoretisch" alles zu stimmen.....

[Codierknecht]

@paul53
Ich hab's gerade mal mit lowBatteryList und auch mit offlineList getestet. Beide Trigger werden passend zum eingestellten Aktualisierungsintervall des Adapters ausgeführt. Und wie bei @ciddi89 ändert sich nur ts.

Triggere ich dagegen auf lowBatteryCount bzw. offlineCount, passiert ... nix. Hier wird der Trigger dann tatsächlich - wie erwartet - nur ausgeführt, wenn sich etwas ändert.

[Codierknecht]

@ciddi89
Was ist denn, wenn Du in writeDatapoints(adptName) aus dem hier:

// list battery low powered
if (this.lowBatteryPoweredCount === 0) {
	// if no device is count, write the JSON List with default value
	this.batteryLowPowered = [{ Device: '--none--', Adapter: '', Battery: '' }];
}
//write JSON list
await this.setStateAsync(`devices.${dpSubFolder}lowBatteryList`, {
	val: JSON.stringify(this.batteryLowPowered),
	ack: true,
});

Das hier machst:

// list battery low powered
if (this.lowBatteryPoweredCount === 0) {
	// if no device is count, write the JSON List with default value
	this.batteryLowPowered = [{ Device: '--none--', Adapter: '', Battery: '' }];
} else {
  //write JSON list
  await this.setStateAsync(`devices.${dpSubFolder}lowBatteryList`, {
  	val: JSON.stringify(this.batteryLowPowered),
  	ack: true,
  });
}

Das "umgeht" zwar nur das eigentliche Problem, sollte aber helfen.

[Ein ehemaliger Benutzer]

@codierknecht naja was soll da umgehen werden? Das wird dann trotzdem genau so ausgeführt werden. Also das end Ergebnis wird gleich bleiben.

//Edit: sry nun erst richtig wach. Das Ergebnis wird bei deinem Vorschlag doch nicht gleich bleiben da setState bei 0 garnicht ausgeführt wird. Aber egal wie der Stand ist, er soll immer ausgeführt werden.

[Codierknecht]

@ciddi89 sagte in Skript löst "fälschlicherweise" aus:

Aber egal wie der Stand ist, er soll immer ausgeführt werden.

Stimmt auch wieder. War wohl auch noch nicht richtig wach :-(
Und wenn tatsächlich mal ein Gerät zu melden wäre, würde das ja auch immer wieder geschrieben.

[Ein ehemaliger Benutzer]

@codierknecht das was ich Adapter seitig machen kann ist den Wert zu vergleichen mit den Datenpunkt und dann wirklich nur bei Änderung schreiben lassen. Werde mal gucken wie andere devs das so machen.

[Ein ehemaliger Benutzer]

Soooo habe auch herausgefunden warum er das macht und konnte den Fehler Adapterseitig beseitigen.

Anstatt einfach nur setStateAsync muss man setStateChangedAsync nutzen. Dann beschreibt der Adapter den Datenpunkt nur wenn der Wert wirklich anders ist. Somit wieder was gelernt. :)

@David-G In der Github Version ist es bereits geändert. Ansonsten auf das nächste Release warten.