[gelöst] DOIF ... present eq "absent": Unknown command present, try help.

[dafosy]

Servus,

ich bekomme obigen Fehler mit folgender Konfiguration und finde den Fehler nicht:

Code Auswählen Erweitern

define testping PRESENCE lan-ping 192.168.0.121 30 ... funktioniert present/ absent, bzw. reagiert auch je nach Pingbarkeit.
Schreibtisch ist meine funktionierend schaltbare Schreibtischlampe zu Testzwecken.
...

Code Auswählen Erweitern

define test1 DOIF ([+00:00:20]) ([testping] eq "absent") (set Schreibtisch off) (set Schreibtisch on)
attr wait 0,0,5 ... gesetzt
attr do always ... gesetzt

Fehler:
2019.12.05 10:49:52 2: test1: present eq "absent": Unknown command present, try help.
2019.12.05 10:49:52 3: sduino IT_set: Schreibtisch off
2019.12.05 10:49:57 3: sduino IT_set: Schreibtisch on

Weiß jemand Rat?
Weiß jemand, ob ich meine Attribute "wait" richtig gesetzt habe? Zwischen dem Schreibtisch off und Schreibtisch on möchte ich gerne 5 Sekunden haben. Ich habe auch einen Delay, weiß aber nicht, ob der von meinen Attributen kommt oder normal verzögert. Aktuell gehe ich davon aus, dass meine Attribute stimmen. Die Zeitkomponente am Anfang scheint also nicht mitzuzählen.


Hinweis:
Hintergrund der Schaltung ist eine Art Router reboot. Der 20sek. Prüfrhythmus ist nur zu Testzwecken.

[Otto123]

([+00:00:20]) ([testping] eq "absent")

Dein 1. Kommando (im Sinne DOIF) ist eine Frage.
Du wolltest so?

Code Auswählen Erweitern

([+00:00:20] and [testping] eq "absent")

Dann musst Du noch wait anpassen.

[laberlaib]

Gude,

Erst mal das von Otto123 und dann:

Was willst Du eigentlich machen?
Wenn das Ding absent ist, dann ausschalten und 5 Sekunden wieder anschalten?

Was soll den überhaupt [+00:00:20] bewirken?
Alle 20 Sekunden gucken ob das Ding auf Absent ist? Wozu?
Es gibt doch mit wait und auch in Presence diverse "richtige" Mechanismen um (Ab-)Wartezeiten richtig zu konfigurieren, statt dem alle 20 Sekunden schauen.

[dafosy]

Kurz zum Hintergrund:
ich habe einen NodeMCU im Garten, der meine Wetterdaten sammelt. Diese lasse ich mir seit Jahren in meinem Volkszähler visualisieren. Seit geraumer Zeit spinnt jedoch mein NodeMCU und stürzt unvermittelt ab.

Mittels eines Reset/ Strom wegnehmen und wieder anlegen, läuft der NodeMCU aber wieder ganz brauchbar.
Deswegen meine obige Schaltung.

Ja, ich möchte final, dass alle 15min geprüft wird, ob der NodeMCU per Ping erreichbar ist, wenn nicht, dann Steckdose ausschalten, 5 Sekunden warten und dann wieder einschalten. Danach erneut 15min warten, prüfen, entsprechend handeln oder erneut 15min warten und dann wieder prüfen usw.

Tatsächlich bin ich im Berech FHEM und DOIF neu, wie würdet ihr mein Problem mittels DOIF lösen? Oder Watchdog oder was gibt es sonst noch? DOIF finde ich jedoch sinnvoll.

[Otto123]

Mein Code entspricht jetzt nicht dem was Du Dir vorgestellt hast?

Ansonsten brauchst eigentlich keinen Zeittrigger. Du triggerst einfach auf absent, wartest ne Weile und machst reset.

Ich habe so ein ähnliches DOIF welches ermittelt ob ich 5 min lang weg bin.

Code Auswählen Erweitern

defmod di_Dev_Otto DOIF ([st_Dev_Otto] eq "absent")(set PersonOtto absent) DOELSEIF ([st_Dev_Otto] eq "present")(set PersonOtto present)
attr di_Dev_Otto room Status
attr di_Dev_Otto wait 300


Das kannst Du mit deinem Ansatz kombinieren (DOELSEIF Zweig brauchst Du nicht, vielleicht aber do reset wait ), dann sollte das passen. Probier es aus, wenn Du nicht zurecht kommst frag nach.

Gruß Otto

[dafosy]

Auf "absent" zu triggern klappt erstmal ganz gut, auch mit dem Attribut "wait".

Nur wie weise ich DOIF an, den Test nochmal zu machen? Bzw. solange periodisch (alle 15min) den Prozess zu durchlaufen, bis der Status "present" wieder da ist.

Es kann ja sein, dass sich der "absent" Status nicht zu "present" ändert, weil der Schaltimpuls nicht umgesetzt wurde. Mit der obigen DOIF Anweisung tritt ja erst eine Handlung ein, wenn sicher der Status ändert. Wenn dieser sich nicht ändert, läuft der DOIF-Prozess einmal durch - egal ob erfolgreich oder nicht.

[MadMax-FHEM]

Du musst (solltest) lernen, dass fhem Event-basiert ist.

Klar kann man zyklisch pollen und sich tot-prüfen (hat man früher gemacht, so vor Objektorientierter Programmierung   /  gut manches läuft auch heute noch so: PLC)...

Besser ist es doch auf ein Ereignis zu reagieren und nur dann (wenn es eben nötig ist) was zu tun...

D.h. wenn die Zustände/Ereignisse nicht kommen wie gewünscht: dort ansetzen...

Beispiel:

du kannst entweder alle 5 Minuten schauen oder auch mit Namen rufen prüfen, ob noch jemand zuhause ist...
...geht unheimlich auf die Stimme und kostet echt unnötig Zeit...

ODER einfach warten, bis jemand rein kommt und "Hallo" sagt

Wenn natürlich das "Hallo" ausbleibt ist das doof, also daher: jeden anweisen beim Reinkommen "Hallo" zu rufen


Wenn du alle 15min was prüfen willst: ein zyklisches at für alle 15min definieren und "totprüfen"

Gruß, Joachim

[Otto123]

Wenn die nodeMCU tot ist und nach einem Reset nicht wieder kommt hilft es doch nix.
Du kannst ja noch eine Abfrage machen, die prüft ob nach einem absent innerhalb von 15 min ein present kommt. Wenn nicht schickst Du Dir eine Mail.
Ich habe irgendwo so etwas, muss mal schauen.

[dafosy]

@ MadMax

Nun genau das ist ja meine Herausforderung:

Was, wenn der, der nach hause kommen soll, nicht kommt. Dann mache ich mir ja Sorgen und sollte reagieren.
Oder wie damals, Mama ruft zum Mittagessen, aber keiner kommt. Das Essen würde kalt werden, wenn Mama nicht nochmal ruft. 

Sprich, wenn sich mein Sensor-Arduino aus dem Garten nicht meldet, dann würde ich es nochmal probieren mit einer Schaltung der entsprechenden Steckdose. Es kann ja sein, dass mein erster Schaltbefehl an die Steckdose nicht ankam.

[Otto123]

Es kann ja sein, dass mein erster Schaltbefehl an die Steckdose nicht ankam.

Da würde ich eine Steckdose mit Rückmeldung nehmen. Alles andere ist Murks.
Aber Du kannst letztendlich machen was Du willst

Ich habe hier noch ein watchdog:

Code Auswählen Erweitern

defmod w_Sicherung watchdog Sicherung:on 00:15 Sicherung:ServerBackup {DebianMail('xxx@web.de','FHEM: Sicherung','Sicherung nicht fristgerecht beendet')};; trigger w_Sicherung .
Normalerweise erzeugt Sicherung eine Kette von Events:
Start
on
ServerBackup
fertig

Der Event on triggert das watchdog, wenn bis zu Event ServerBackup mehr als 15 min vergehen, schickt er einen Mail das etwas nicht stimmt. Wenn innerhalb der Zeit der Event kommt passiert mit dem watchdog nichts.

Also nur als Idee und nicht als fertige Lösung. Man kann das sicher auch in einem DOIF vereinen.

Gruß Otto

[MadMax-FHEM]

@ MadMax

Nun genau das ist ja meine Herausforderung:

Was, wenn der, der nach hause kommen soll, nicht kommt. Dann mache ich mir ja Sorgen und sollte reagieren.
Oder wie damals, Mama ruft zum Mittagessen, aber keiner kommt. Das Essen würde kalt werden, wenn Mama nicht nochmal ruft. 

Sprich, wenn sich mein Sensor-Arduino aus dem Garten nicht meldet, dann würde ich es nochmal probieren mit einer Schaltung der entsprechenden Steckdose. Es kann ja sein, dass mein erster Schaltbefehl an die Steckdose nicht ankam.

Jaja, jetzt hab ich die Problematik mal ganz gelesen

Dann wie vorgeschlagen: watchdog

Macht wie der Name sagt eigentlich was du willst/brauchst...

Allerdings schon fraglich warum der NodeMCU immer wieder mal "aussteigt"...

Eigener Sketch oder was "Fertiges"?

Fritzbox im Einsatz?

Gruß, Joachim

[dafosy]

Ich glaube, der NodeMCU hat ein Korrosionsproblem, da dieser seit mehr als 2 Jahren, zwar geschützt, aber für Luftfeuchte dennoch erreichbar, installiert wurde. 

Nach einem Reset läuft er auch erstmal wieder, aber eben unzuverlässig lang. Bevor ich mich also mit einem neuen Aufbau des NodeMCUs bemühe, schöpfe ich erstmal die Möglichkeiten mit FHEM aus. 

Die Parameter für Watchdog schaue ich mir dann gleich mal an.
Hast du ggf. ein paar spontane Stichworte für "define" parat - insbesondere mit der im Blick halten des watchdogs der PRESENCE Variablen?

[MadMax-FHEM]

Warum sollte er bei einem Korrosionsproblem nach einem Neustart "einfach wieder laufen"!?

Trotzdem nochmal die Frage: eigener Sketch oder was "Fertiges"!?

Und noch mal: Fritzbox im Einsatz!?

Ich habe auch einen ESP auf dem Balkon, auch gut geschützt aber durchaus auch mit Luftfeuchte (in einem "Kämmerchen" zusammen mit meinem Wassertank / ESP: Füllstandsmesser)...
...mein erster Sketch neigte auch dazu ab und an einfach "weg zu sein"

Nach reboot war alles gut.

Habe dann noch mal drüber geschaut und ein paar Sachen geändert, seither läuft er problemlos durch (2 Jahre jetzt am Stück)...

Ansonsten gibt es halt immer wieder Meldungen bzgl. ESP und Fritzbox...

Gruß, Joachim

[dafosy]

Ich habe jetzt einen Test laufen mit:

Code Auswählen Erweitern


        define GaragenPing PRESENCE lan-ping 192.168.0.100 300
        attr GaragenPing event-on-change-reading state
        define GaragenSchalt DOIF ([GaragenPing] eq "absent") (set Garage off) (set Garage on)
        attr GaragenSchalt wait 0,10
        define GarageWatchdog watchdog GaragenPing.absent 00:10 GaragenPing.present set Garage off;; sleep 5;; set Garage on

@MadMax:

(1) Der arduino ist was selbst gebautet ... ähnlich luftinfo.org nur aufgesetzt auf ESPeasy und visualisiert in meinem Volkszähler.
(1a) nun, der Arduino lief 2 Jahre fehlerfrei, aber nun plötzlich hat er Macken. Habe Stromzufuhr schon getauscht, aber keine Verbesserung. Mein BMP280 Temperatursensor hatte auch schonmal Korrssionsschäden und ich habe den nach Problemen gewechselt - dann gang alles wieder.
(2) Keine Fritzbox, DD-WRT Router

[Per]

Schau mal hier rein, ähnliches Problem, vllt. ne Lösung?