Hallo zusammen,
wie kann ich ein DOIF Triggern wenn ein Dummy seinen State von "off" auf "on" wechselt?
Und zwar nur in diesem Fall. Sprich der DOIF soll nur einmal Triggern, wenn der Dummy in den Status "on" wechselt.
Bisher triggert mein DOIF anscheinen ständig solange der Dummy im Status "on" ist.
Wofür brauche ich das ganze?
Ich habe einen Watchdog am laufen, der einen Shelly Plug S ausschalten soll, wenn die Leistung für eine gewisse Zeit (1 min) unter die Grenze X fällt.
Der Watchdog löst aus, wenn der Dummy deaktiviert wird (Leistung unter 30W > Dummy "off"). Dazu muss dieser aber erst einmal den Status "on"
gehabt haben.
Schaltet man den Shelly aber "versehentlich" ein und kein Verbraucher wird aus dem Standby geholt bleibt die Leistung immer unter 30W, der Dummy schaltet nicht
auf "on" wodurch der schlafende Hund (Watchdog) nicht geweckt (löst nicht aus) wird.
Daher soll der DOIF den Dummy beim einschalten des Shellys einmal auf "on" schalten (der dann durch den notify wieder auf "off" gesetzt wird, da die Leistung unter 30W liegt).
Könnte mir da jemand eventuell ein wenig auf die Sprünge helfen?
Oder gibt es hier eine charmantere Lösung?
Wenn ich mich irgendwo missverständliche ausgedrückt haben sollte oder noch irgendwelche Fragen offen sind oder Informationen gebraucht werden würde ich
diese selbstverständlich gerne nachreichen.
Danke schon einmal im voraus und beste Grüße
Decayed
Wenn du ein DOIF benutzt, dann brauchst du kein Watchdog und kein notify. Beides ist im DOIF schon drin. Statt Watchdog kannst du wait im DOIF nutzen.
Und umgekehrt, wenn du Watchdog und notify benutzen willst, dann brauchst du kein DOIF.
Edit: Auch die Dummys als Zustandsindikatoren kannst du im DOIF abbilden - die brauchst du dann auch nicht.
Hi Damian,
danke für die Auskunft.
Was ist denn in dem Fall die "best practice"?
Ich vermute mal ganz stark, dass sowohl DOIF als auch Watchdog gewisse vor und Nachteile haben, oder sehe ich das falsch?
Zitat von: Decayed am 18 März 2020, 21:32:39
Hi Damian,
danke für die Auskunft.
Was ist denn in dem Fall die "best practice"?
Ich vermute mal ganz stark, dass sowohl DOIF als auch Watchdog gewisse vor und Nachteile haben, oder sehe ich das falsch?
Es sind verschiedene Konzepte. Zu allen Modulen gibt es eine Commandref, die die Funktionsweise der einzelnen Module erklärt.
Dein Beispiel passt ein wenig zum Beispiel "Waschmaschine fertig". Z. B. hier als Einzeiler zu finden: https://fhem.de/commandref_DE.html#DOIF_wait
Zitat von: Damian am 18 März 2020, 21:41:02
Dein Beispiel passt ein wenig zum Beispiel "Waschmaschine fertig". Z. B. hier als Einzeiler zu finden: https://fhem.de/commandref_DE.html#DOIF_wait
Ach du meine Güte, es kann tatsächlich sooooo einfach sein, wenn einen jemand in die richtige Richtung schubbst!
Läuft soweit jetzt einwandfrei und das mit nur "einem" DOIF (halt mehrere Commands).
Daher vielen lieben Dank für die schnelle Hilfe :DD
Ich hätte da jetzt allerdings noch ein, zwei generelle Fragen:
define Test DOIF ([MQTT2_shellyplug_s_6A5FB9:relay_0_power] == "0" and [MQTT2_shellyplug_s_6A5FB9:state] eq "on") (set MQTT2_shellyplug_s_6A5FB9 off)
DOELSEIF ([MQTT2_shellyplug_s_6A5FB9:relay_0_power] < "30" and [MQTT2_shellyplug_s_6A5FB9:state] eq "on") (set MQTT2_shellyplug_s_6A5FB9 off)
DOELSE ()
1. Das "DOELSE ()" habe ich angefügt, da der DOIF sonst in cmd_1 stehen geblieben wäre, und ein erneutes auslösen von cmd_1 so lange nicht möglich gewesen wäre wie
der State nicht in cmd_2 gesprungen wäre. So wird der DOIF nach jedem anderen cmd quasi in seinen "Normalzustand" cmd_3 versetzt.
Stellt das ein Problem dar? Sollte man sowas überhaupt machen? Gäbe es hier noch eine alternative? (Laut Commandref wir ja bei DOIF's mit nur einen cmd intern automatisch dein DOELSE gesetzt)
2. Die FHEM-Instanz läuft auf einem Raspberry PI4 mit 2 Gb Ram - Sind hier irgendwelche Performance-Probleme zu erwarten?
Ich frage mich halt wie gut der "kleine" DOIF's und ähnliches weg stecken kann, bevor er in die Bremse läuft.
3. Macht es Sinn die DOIF's im Perl-Modus laufen zu lassen (klar, müsste dann den DEF umschreiben)?
Brächte das irgendwelche Performance-Vorteile mit sich? (Das da "programmiertechnisch" mehr geht als im FHEM-Modus verstehe ich wohl)
Zitat von: Decayed am 19 März 2020, 07:51:43
Ach du meine Güte, es kann tatsächlich sooooo einfach sein, wenn einen jemand in die richtige Richtung schubbst!
Läuft soweit jetzt einwandfrei und das mit nur "einem" DOIF (halt mehrere Commands).
Daher vielen lieben Dank für die schnelle Hilfe :DD
Ich hätte da jetzt allerdings noch ein, zwei generelle Fragen:
define Test DOIF ([MQTT2_shellyplug_s_6A5FB9:relay_0_power] == "0" and [MQTT2_shellyplug_s_6A5FB9:state] eq "on") (set MQTT2_shellyplug_s_6A5FB9 off)
DOELSEIF ([MQTT2_shellyplug_s_6A5FB9:relay_0_power] < "30" and [MQTT2_shellyplug_s_6A5FB9:state] eq "on") (set MQTT2_shellyplug_s_6A5FB9 off)
DOELSE ()
1. Das "DOELSE ()" habe ich angefügt, da der DOIF sonst in cmd_1 stehen geblieben wäre, und ein erneutes auslösen von cmd_1 so lange nicht möglich gewesen wäre wie
der State nicht in cmd_2 gesprungen wäre. So wird der DOIF nach jedem anderen cmd quasi in seinen "Normalzustand" cmd_3 versetzt.
Stellt das ein Problem dar? Sollte man sowas überhaupt machen? Gäbe es hier noch eine alternative? (Laut Commandref wir ja bei DOIF's mit nur einen cmd intern automatisch dein DOELSE gesetzt)
2. Die FHEM-Instanz läuft auf einem Raspberry PI4 mit 2 Gb Ram - Sind hier irgendwelche Performance-Probleme zu erwarten?
Ich frage mich halt wie gut der "kleine" DOIF's und ähnliches weg stecken kann, bevor er in die Bremse läuft.
3. Macht es Sinn die DOIF's im Perl-Modus laufen zu lassen (klar, müsste dann den DEF umschreiben)?
Brächte das irgendwelche Performance-Vorteile mit sich? (Das da "programmiertechnisch" mehr geht als im FHEM-Modus verstehe ich wohl)
Zu 1: Wenn es für deinen Anwendungsfall korrekt funktioniert, dann ist DOELSE an dieser Stelle richtig. Wie du schon korrekt festgestellt hast, wird DOELSE in diesem Fall nicht automatisch dran gehängt. Alternativ kann man do always-Attribut setzen um eine Wiederholung zuzulassen, dann sollte man allerdings Abfragen von zyklisch sendenden Sensoren, wie in cmd_2, in einen DOIF_Reading (siehe Commandref) auslagern, sonst würde cmd_2 ständig geschaltet werden.
Zu 2: DOIF verwendet die selben Trigger-Mechanismen wie notify, at und co., daher werden nicht mehr Resourcen verbraucht als bei anderen Modulen - es arbeitet ereignisgesteuert, also schläft es in Normalfall, ohne das System zu belasten. Das Modul wird nur einmal für alle Definitionen in Speicher geladen.
Zu 3: Der Perl-Modus ist etwas effizienter, da auch der Ausführungsteil (nicht nur die Bedingung) in Perl abläuft. Der wesentliche Unterschied ist, dass man sich im Perl-Modus selbst um den eigenen Status kümmern muss (Wiederholungen werden nicht automatisch unterbunden), dafür kann man in einem Modul beliebig viele
unabhängige Zweige (Perl-Blöcke) definierten und man hat beliebig viele wait-Timer, die man verwalten kann. Allerdings werden mehr Perlkenntnisse verlangt.
Edit: Zahlen bei Vergleichen solltest du nicht in Anführungszeichen setzen: [MQTT2_shellyplug_s_6A5FB9:relay_0_power] < 30
Zitat von: Damian am 19 März 2020, 08:26:08
Zu 1: Wenn es für deinen Anwendungsfall korrekt funktioniert, dann ist DOELSE an dieser Stelle richtig. Wie du schon korrekt festgestellt hast, wird DOELSE in diesem Fall nicht automatisch dran gehängt. Alternativ kann man do always-Attribut setzen um eine Wiederholung zuzulassen, dann sollte man allerdings Abfragen von zyklisch sendenden Sensoren, wie in cmd_2, in einen DOIF_Reading (siehe Commandref) auslagern, sonst würde cmd_2 ständig geschaltet werden.
Zu 2: DOIF verwendet die selben Trigger-Mechanismen wie notify, at und co., daher werden nicht mehr Resourcen verbraucht als bei anderen Modulen - es arbeitet ereignisgesteuert, also schläft es in Normalfall, ohne das System zu belasten. Das Modul wird nur einmal für alle Definitionen in Speicher geladen.
Zu 3: Der Perl-Modus ist etwas effizienter, da auch der Ausführungsteil (nicht nur die Bedingung) in Perl abläuft. Der wesentliche Unterschied ist, dass man sich im Perl-Modus selbst um den eigenen Status kümmern muss (Wiederholungen werden nicht automatisch unterbunden), dafür kann man in einem Modul beliebig viele unabhängige Zweige (Perl-Blöcke) definierten und man hat beliebig viele wait-Timer, die man verwalten kann. Allerdings werden mehr Perlkenntnisse verlangt.
Edit: Zahlen bei Vergleichen solltest du nicht in Anführungszeichen setzen: [MQTT2_shellyplug_s_6A5FB9:relay_0_power] < 30
Danke für die ausführliche Antwort Damian :D
Ich finde es echt gut, dass du einem Neuling hier so tatkräftig zur Seite stehst.
Zitat von: Damian am 19 März 2020, 08:26:08
Zu 3: Der Perl-Modus ist etwas effizienter, da auch der Ausführungsteil (nicht nur die Bedingung) in Perl abläuft. Der wesentliche Unterschied ist, dass man sich im Perl-Modus selbst um den eigenen Status kümmern muss (Wiederholungen werden nicht automatisch unterbunden), dafür kann man in einem Modul beliebig viele unabhängige Zweige (Perl-Blöcke) definierten und man hat beliebig viele wait-Timer, die man verwalten kann. Allerdings werden mehr Perlkenntnisse verlangt.
Das heißt, es gibt im FHEM-Modus ein limit an Commands die eingegeben werden können oder bin ich hier grade auf dem Holzweg? Wenn ja, wo läge das Limit denn? (Oder hab ich das im Commandref überlesen? Dann reicht ein kleiner Hinweis und ich muss nochmal mit der Lupe ran!)
Zitat von: Damian am 19 März 2020, 08:26:08
Edit: Zahlen bei Vergleichen solltest du nicht in Anführungszeichen setzen: [MQTT2_shellyplug_s_6A5FB9:relay_0_power] < 30
Dann auch gleichbedeutend bei [MQTT2_shellyplug_s_6A5FB9:relay_0_power] == "0" (dann ohne Anführungszeichen) ?
Gehe ich eigentlich recht in der Annahme, dass Werte für Vergleiche von nicht numerischen Zeichen case-sensitive sind?
Zitat von: Decayed am 19 März 2020, 22:20:07
Danke für die ausführliche Antwort Damian :D
Ich finde es echt gut, dass du einem Neuling hier so tatkräftig zur Seite stehst.
Das heißt, es gibt im FHEM-Modus ein limit an Commands die eingegeben werden können oder bin ich hier grade auf dem Holzweg? Wenn ja, wo läge das Limit denn? (Oder hab ich das im Commandref überlesen? Dann reicht ein kleiner Hinweis und ich muss nochmal mit der Lupe ran!)
Dann auch gleichbedeutend bei [MQTT2_shellyplug_s_6A5FB9:relay_0_power] == "0" (dann ohne Anführungszeichen) ?
Gehe ich eigentlich recht in der Annahme, dass Werte für Vergleiche von nicht numerischen Zeichen case-sensitive sind?
Es gibt kein Limit an Kommandos oder an DOELSEIF-Zweigen.
Es gibt im DOIF-FHEM-Modus allerdings nur einen wait-Timer. In diesem Modus wird bei einem eintreffenden Ereignis höchstens nur ein DOIF/DOELSEIF/DOELSE-Zweig ausgeführt.
Für DOIF-Bedingungen gilt, bis auf Angaben in eckigen Klammern, Perl-Syntax und damit gelten aller Regeln von Perl, insb. case-sensitive für Ausdrücke und Vergleiche.
Neben der Commmandref ist der Einsteigerleitfaden für Anfänger nützlich:
https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen