NEWS
Skript löst "fälschlicherweise" aus
-
Hallo,
ich habe für einen User im Forum folgendes Skript erstellt:
Komischerweise löst es bei mir alle 10 Sekunden aus (Aktualisierungsintervall vom Device-Watcher Adapter).
Wenn ich mir jedoch unter den Objekten anschaue, wann der Datenpunkt zuletzt geändert wurde, sehe ich, dass dies gestern geschehen ist.
Woran kann das liegen? Habe ich noch nie beobachtet sowas.
-
Hallo,
ich habe für einen User im Forum folgendes Skript erstellt:
Komischerweise löst es bei mir alle 10 Sekunden aus (Aktualisierungsintervall vom Device-Watcher Adapter).
Wenn ich mir jedoch unter den Objekten anschaue, wann der Datenpunkt zuletzt geändert wurde, sehe ich, dass dies gestern geschehen ist.
Woran kann das liegen? Habe ich noch nie beobachtet sowas.
@david-g
Den Effekt kann ich ebenfalls beobachten.
Aber das Senden der Mail lässt sich ja recht einfach unterdrücken. Vorschlag:
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring")
Proxmox 9.1.1 LXC|8 GB|Core i7-6700
HmIP|ZigBee|Tasmota|Unifi
Zabbix Certified Specialist
Konnte ich Dir helfen? Dann benutze bitte das Voting unten rechts im Beitrag -
@david-g
Den Effekt kann ich ebenfalls beobachten.
Aber das Senden der Mail lässt sich ja recht einfach unterdrücken. Vorschlag:
Hast du das Verhalten auch nur in Verbindung mit dem Device-Watcher Adapter oder auch woanders?
Ich selber nutze das Skript nicht.
Was bewirkt der Falls Block?
Da ich keinen boolischen Wert prüfe ist denke alles größer 0 "wahr" oder?Dann geht die Mail doch trotzdem so oft raus wenn min 1 Device leer ist?
Mich würde interessieren, warum der Trigger so oft auslöst. Es liegt ja keine Änderung vor.
Ist es ein Fehler vom Javascript Adapter, vom iobroker oder vom device Watcher? -
Hast du das Verhalten auch nur in Verbindung mit dem Device-Watcher Adapter oder auch woanders?
Ich selber nutze das Skript nicht.
Was bewirkt der Falls Block?
Da ich keinen boolischen Wert prüfe ist denke alles größer 0 "wahr" oder?Dann geht die Mail doch trotzdem so oft raus wenn min 1 Device leer ist?
Mich würde interessieren, warum der Trigger so oft auslöst. Es liegt ja keine Änderung vor.
Ist es ein Fehler vom Javascript Adapter, vom iobroker oder vom device Watcher?@david-g
Gute Frage(n).
Hab' nur mit Device-Watcher getestet. Aber wenn's bei anderen auch wäre, würden die mir ständig etwas schicken. Und auch beim Device-Watcher ist das seltsam ... bei Geräte-Offline passiert das nicht.
Bei mir wurde der Trigger auch alle paar Sekunden ausgeführt - obwohl keines der Geräte schwache Batterien hatte. Etwas seltsam, da der Trigger ja auch "wurde geändert" und nicht auf "wurde aktualisiert" sitzt. Und das "Falls" stellt nur sicher, dass zumindest bei 0 Geräten keine Meldung kommt.Könnte man jetzt mit 'nem Workaround umgehen.
Man merkt sich die Geräte in einer Variablen und prüft vor dem Versand der Nachricht, ob der Inhalt sich vom aktuell ermittelten unterscheidet.
Zum Beispiel alle Devicenamen nacheinander als string in die Variable schreiben.
Im Trigger macht man das mit den aktuellen Devices nochmal und vergleicht die beiden Variablen.
Nur wenn die sich unterscheiden, werden die jetzt gefundenen Geräte ich die "Merk"-Variable geschrieben und die Nachricht verschickt.
Ist aber nur ein rumdoktorn an den Symptomen - eigentlich sollte das (zumindest nach meiner Theorie) gar nicht passieren. Es hat sich ja nicht tatsächlich etwas geändert.Mach doch in GitHub ein Issue auf.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring")
Proxmox 9.1.1 LXC|8 GB|Core i7-6700
HmIP|ZigBee|Tasmota|Unifi
Zabbix Certified Specialist
Konnte ich Dir helfen? Dann benutze bitte das Voting unten rechts im Beitrag -
@david-g
Gute Frage(n).
Hab' nur mit Device-Watcher getestet. Aber wenn's bei anderen auch wäre, würden die mir ständig etwas schicken. Und auch beim Device-Watcher ist das seltsam ... bei Geräte-Offline passiert das nicht.
Bei mir wurde der Trigger auch alle paar Sekunden ausgeführt - obwohl keines der Geräte schwache Batterien hatte. Etwas seltsam, da der Trigger ja auch "wurde geändert" und nicht auf "wurde aktualisiert" sitzt. Und das "Falls" stellt nur sicher, dass zumindest bei 0 Geräten keine Meldung kommt.Könnte man jetzt mit 'nem Workaround umgehen.
Man merkt sich die Geräte in einer Variablen und prüft vor dem Versand der Nachricht, ob der Inhalt sich vom aktuell ermittelten unterscheidet.
Zum Beispiel alle Devicenamen nacheinander als string in die Variable schreiben.
Im Trigger macht man das mit den aktuellen Devices nochmal und vergleicht die beiden Variablen.
Nur wenn die sich unterscheiden, werden die jetzt gefundenen Geräte ich die "Merk"-Variable geschrieben und die Nachricht verschickt.
Ist aber nur ein rumdoktorn an den Symptomen - eigentlich sollte das (zumindest nach meiner Theorie) gar nicht passieren. Es hat sich ja nicht tatsächlich etwas geändert.Mach doch in GitHub ein Issue auf.
-
Die Frage ist, wo ich es auf mache.
Mit dem dev vom device Watcher @ciddi89 hatte ich schon Kontakt.Am ehsten im Javascript Adapter oder?
@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?
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: RPi 2 mit S.USV, HM-MOD-RPI und SLC-USB-Stick mit root fs -
Die Frage ist, wo ich es auf mache.
Mit dem dev vom device Watcher @ciddi89 hatte ich schon Kontakt.Am ehsten im Javascript Adapter oder?
@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 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?
-
@david-g
Gute Frage(n).
Hab' nur mit Device-Watcher getestet. Aber wenn's bei anderen auch wäre, würden die mir ständig etwas schicken. Und auch beim Device-Watcher ist das seltsam ... bei Geräte-Offline passiert das nicht.
Bei mir wurde der Trigger auch alle paar Sekunden ausgeführt - obwohl keines der Geräte schwache Batterien hatte. Etwas seltsam, da der Trigger ja auch "wurde geändert" und nicht auf "wurde aktualisiert" sitzt. Und das "Falls" stellt nur sicher, dass zumindest bei 0 Geräten keine Meldung kommt.Könnte man jetzt mit 'nem Workaround umgehen.
Man merkt sich die Geräte in einer Variablen und prüft vor dem Versand der Nachricht, ob der Inhalt sich vom aktuell ermittelten unterscheidet.
Zum Beispiel alle Devicenamen nacheinander als string in die Variable schreiben.
Im Trigger macht man das mit den aktuellen Devices nochmal und vergleicht die beiden Variablen.
Nur wenn die sich unterscheiden, werden die jetzt gefundenen Geräte ich die "Merk"-Variable geschrieben und die Nachricht verschickt.
Ist aber nur ein rumdoktorn an den Symptomen - eigentlich sollte das (zumindest nach meiner Theorie) gar nicht passieren. Es hat sich ja nicht tatsächlich etwas geändert.Mach doch in GitHub ein Issue auf.
@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 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?
@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.
-
@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?
@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 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?
@ciddi89
Das ist das Ergebnis:
Edit: Aktualisierungsintervall des Adapters steht auf 30 Sekunden!
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring")
Proxmox 9.1.1 LXC|8 GB|Core i7-6700
HmIP|ZigBee|Tasmota|Unifi
Zabbix Certified Specialist
Konnte ich Dir helfen? Dann benutze bitte das Voting unten rechts im Beitrag -
@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?
@david-g ne hat er nicht. Und alle Datenpunkte werden gleich erstellt. Daher codemäßig ist da kein unterschied.
-
@ciddi89
Das ist das Ergebnis:
Edit: Aktualisierungsintervall des Adapters steht auf 30 Sekunden!
@codierknecht sagte: Das ist das Ergebnis:
Teste mal mit:
on('device-watcher.0.lowBatteryList', function(dp) { log(dp.oldState); log(dp.state); });Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: RPi 2 mit S.USV, HM-MOD-RPI und SLC-USB-Stick mit root fs -
@codierknecht sagte: Das ist das Ergebnis:
Teste mal mit:
on('device-watcher.0.lowBatteryList', function(dp) { log(dp.oldState); log(dp.state); });@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 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 ja mein reden. Das ist wirklich sehr merkwürdig.
-
@codierknecht sagte: Das ist das Ergebnis:
Teste mal mit:
on('device-watcher.0.lowBatteryList', function(dp) { log(dp.oldState); log(dp.state); });@paul53
Ich hab's gerade mal mitlowBatteryListund auch mitofflineListgetestet. Beide Trigger werden passend zum eingestellten Aktualisierungsintervall des Adapters ausgeführt. Und wie bei @ciddi89 ändert sich nurts.Triggere ich dagegen auf
lowBatteryCountbzw.offlineCount, passiert ... nix. Hier wird der Trigger dann tatsächlich - wie erwartet - nur ausgeführt, wenn sich etwas ändert. -
@paul53 ja mein reden. Das ist wirklich sehr merkwürdig.
@ciddi89
Was ist denn, wenn Du inwriteDatapoints(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.
Support us
843
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge