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

[Ketanest]

@david-g Hab ich tatsächlich nicht nein. Jedenfalls nix, was dauerhaft an wäre. Radio, Fernseher etc. hängen selbst an ner Steckdose zwecks Standby Verbrauch und sind nicht 24/7 an.
EDIT: Und der Rest hängt an der USV.
EDIT2: Mein Kühlschrank ist Smart, den könnte ich zwar anpingen, aber so oft wie der die Verbindung verliert ist das auch nicht zuverlässig.

[David G.]

@ketanest

Aber es klappt ja jetzt.
Jedenfalls ein kreativer Ansatz um einen Stromausfall zu ermitteln.

[Asgothian]

@ketanest das auf false setzen kannst du dir sparen - der DP sollte auf ein ansteuern mit wahr immer reagieren - wenn zu schnell dann mit einer Warnmeldungen im log. Ob der cutoff wirklich bei 2 Minuten oder ggf. Bei 30 Sekunden liegt erinnere ich nicht.

A.

[Asgothian]

@ketanest sagte in Availability Timeout Zigbee Geräte:

@asgothian Danke!
Ich habs jetzt so gelöst:
device-query false -> 10 Sekunden warten -> device-query true -> 10 Sekunden warten, Letzte Änderung von "Message from Zigbee" (scheint mir das zuverlässigste zu sein) mit aktueller Zeit - 1 Minute vergleichen, wenn der Letzte Zeitstempel älter ist haut er ne Benachrichtigung raus. Dann 3 Minuten warten und von vorn (while true hehe).
Die ganzen Änderungen sind scheinbar auch unter 2 Minuten möglich (vermutlich, da ich mit false und true jeweils nen neuen Wert setze).
Erster Test hat auch gepasst.

Zeig mal das Skript . Es erscheint mir unnötig komplex, und der „while true“ macht mir auch Kopfschmerzen

A.

[Ketanest]

@asgothian schittebön:

var message, Available, Text2;


message = false;
Available = true;
while (true) {
  setState('zigbee.0.6c5cb1fffe11042a.device_query' /* Trigger device query */, false);
  await wait(10000);
  setState('zigbee.0.6c5cb1fffe11042a.device_query' /* Trigger device query */, true);
  await wait(10000);
  if ((getState('zigbee.0.6c5cb1fffe11042a.msg_from_zigbee').lc < /* time calculation */ ((dateTime) => { const ts = (typeof dateTime === 'object' ? dateTime.getTime() : dateTime); return ts - ((1) * 60000); })((new Date().getTime())) && Available == true)) {
    message = true;
    Available = false;
    Text2 = 'Rack Steckdose reagiert nicht mehr.';
  } else if ((getState('zigbee.0.6c5cb1fffe11042a.msg_from_zigbee').lc > /* time calculation */ ((dateTime) => { const ts = (typeof dateTime === 'object' ? dateTime.getTime() : dateTime); return ts - ((1) * 60000); })((new Date().getTime())) && Available == false)) {
    message = true;
    Available = true;
    Text2 = 'Rack Steckdose reagiert wieder';
  }
  if (message == true) {
    sendTo("email", "send", {
       text: Text2,
       to: 'MEINE_EMAIL_ADRESSE',
       subject: Text2
    });
    sendTo("telegram", "send", {
        text: Text2
    });
    message = false;
  }
  await wait(10000);
}

[Asgothian]

@ketanest dange. So hatte ich das befürchtet.

Was hältst du von

const availabletimeout=null;
var Available =false;

const triggerintervall = setIntervall(function() { setState('zigbee.0.6c5cb1fffe11042a.device_query' /* Trigger device query */, true); },110000);

on ('zigbee.0.6c5cb1fffe11042a.msg_from_zigbee', function(obj) {
  clearTimeout(availabletimeout);
  availabletimeout = setTimeout(function() {
    If (Available) sendMessage(' Rack Steckdose funktioniert nicht mehr ');
    Available = false
  }, 120000);
  If (!Available) sendMessage(' Rack Steckdose funktioniert wieder ');
  Available = true;
});

function sendMessage(Text2)
{
    sendTo("email", "send", {
       text: Text2,
       to: 'MEINE_EMAIL_ADRESSE',
       subject: Text2
    });
    sendTo("telegram", "send", {
        text: Text2
    });
}
  

Das ganze basiert darauf das über einen timeout nachgehalten wird wie lange es her ist das sich der state msg_from_zigbee das letzte mal geändert hat. Wenn der timeout durchläuft dann ist es zu lange her, ansonsten wird der timeout bei jeder erkannten Änderung neu gestartet, das ganze ohne dauerhafte getState abfragen des states selber.

Das regelmäßige aktivieren des device query übernimmt das Intervall.

A.
P.s. ich hasse es code auf dem iPad ins Forum zu tippen - zu viele kleine automatikfehler.

[Ketanest]

@asgothian oh oh, jetzt muss ich mich in JavaScript noch einarbeiten haha. Hab das bisher mit Blockly gemacht und nur den Code rauskopiert. Kann man const availabletimeout überhaupt so benutzen? Soweit ich weiß kann man const Variablen nach der Deklaration weder initialisieren noch ändern :thinking_face:

Weiterhin interpretiere ich:
"triggerintervall" löst alle 110 Sekunden den device_query aus (den man im Übrigen scheinbar wirklich einmal switchen muss, habs ausprobiert, wenn ich den auf true setze obwohl er schon true ist, passiert nicht viel).

Wenn sich "msg_from_zigbee" ändert (spätestens durch triggerintervall) wird availabletimeout zurückgesetzt und direkt danach gesetzt -> heißt nach 120 Sekunden schickt er (sofern available wahr ist) den Text "Rack Steckdose funktioniert nicht mehr" und setzt Available auf false (grätscht hier aber triggerintervall wieder dazwischen (110 Sekunden) passiert das nicht, weil msg_from_zigbee sich ändert und dadurch der timeout unterbrochen wird).

Direkt danach (sofern Available false ist) schickt er "Rack Steckdose funktioniert wieder" und setzt Available auf true. -> Passiert das dann nicht jedesmal direkt nach der Nicht-Funktions-Meldung? Würde ja dann denn Sinn verfehlen. Den Teil hab ich jetzt nur so bedingt verstanden. Wäre es nicht sinnvoller, den "Wieder da"-Teil an den Anfang der Funktion zu packen? Denn bei dem "on"-Event ist das Ding ja auf jeden Fall wieder da.

[Asgothian]

@ketanest sagte in Availability Timeout Zigbee Geräte:

@asgothian oh oh, jetzt muss ich mich in JavaScript noch einarbeiten haha. Hab das bisher mit Blockly gemacht und nur den Code rauskopiert. Kann man const availabletimeout überhaupt so benutzen? Soweit ich weiß kann man const Variablen nach der Deklaration weder initialisieren noch ändern :thinking_face:

Das ganze kannst du auch in Blockly bauen - kann ich aber nur rudimentär zeigen - und es wird etwas dauern.

Weiterhin interpretiere ich:
"triggerintervall" löst alle 110 Sekunden den device_query aus (den man im Übrigen scheinbar wirklich einmal switchen muss, habs ausprobiert, wenn ich den auf true setze obwohl er schon true ist, passiert nicht viel).

Das ist seltsam - bei mir ging es ohne umschalten.

Wenn sich "msg_from_zigbee" ändert (spätestens durch triggerintervall) wird availabletimeout zurückgesetzt und direkt danach gesetzt -> heißt nach 120 Sekunden schickt er (sofern available wahr ist) den Text "Rack Steckdose funktioniert nicht mehr" und setzt Available auf false (grätscht hier aber triggerintervall wieder dazwischen (110 Sekunden) passiert das nicht, weil msg_from_zigbee sich ändert und dadurch der timeout unterbrochen wird).

Jein. Die Funktionsweise ist:
Wenn sich msg_from_zigbee ändert dann lebt die Steckdose.
Das sie das tut wird in der variablen „available“ gespeichert. Eine neue Nachricht gibt es nur wenn diese vorher „falsch“ war.
Der timeout dient dazu zu erkennen wenn die nächste Änderung ausbleibt. Zur Erinnerung - wir erwarten alle 110s eine Änderung. Solange sie also aktiv ist kommt der Inhalt des timeout nie zum Zuge, weil der timeout angehalten wird bevor er aktiv wird. Bleibt die Änderung aus dann kommen keine neuen trigger rein, der timeout läuft ins Ende und der Wechsel auf available=false tritt ein.

Direkt danach (sofern Available false ist) schickt er "Rack Steckdose funktioniert wieder" und setzt Available auf true. -> Passiert das dann nicht jedesmal direkt nach der Nicht-Funktions-Meldung? Würde ja dann denn Sinn verfehlen. Den Teil hab ich jetzt nur so bedingt verstanden. Wäre es nicht sinnvoller, den "Wieder da"-Teil an den Anfang der Funktion zu packen? Denn bei dem "on"-Event ist das Ding ja auf jeden Fall wieder da.

Kann man machen - ändert aber nichts. Der wieder-da Teil kommt nach dem starten des timeout, nicht nach dem Ende.

A.

[Asgothian]

@asgothian

So geht es bei mir.
Ich hab. Nicht den msg-from-zigbee state genommen, der wird bei mir auf ein device query 10 mal In schneller Folge aktualisiert.

A.

[Ketanest]

@asgothian Vielen Dank! Habs mir selbst aber auch schon sehr ähnlich zusammengebastelt:

Ich setz die Variable aber beim Beginn des Skriptes auf wahr, weil ich in jedem Fall mitkriegen will, wenn die auf false umspringt, sprich das Rack nicht erreichbar ist. Setz ich sie am Anfang auf false und das Rack ist bei Skriptbeginn nicht erreichbar, krieg ich das nicht mit. Finde ich persönlich schöner :blush:
Und den device query hab ich mit false und true gebaut, wie gesagt, scheint bei mir nötig zu sein.

[Asgothian]

@ketanest seltsam, aber ok.

Nur statt der Pause Geschichte würde ich die folgenden 2 Blöcke nutzen:
Und 10 Sekunden Pause sind da auch deutlich unnötig lang.

0.5 s reichen auf jeden Fall.