DOIF: "Repeat .. Until" möglich?

[heikoh81]

Hallo zusammen,

ich möchte mit DOIF eine Repeat-Until-Schleife realisieren.

Ich habe manchmal das Problem, dass 433Mhz-Steckdose an der Reichweitengrenze den Befehl manchmal, aber nicht immer, nicht ausführen.
Von der Steckdose wird ein Linux-Sat-Receiver ein- und ausgeschaltet, den ich mittels presence-Funktion pingen kann.
Somit kann ich in diesem Fall prüfen, ob die Schaltsteckdose den Receiver tatsächlich ausgeschaltet hat.

Ich möchte also eine Art Repeat .. Until-Schleife programmieren, die den set off-Befehl so lange im Abstand von 5min wiederholt, bis der Status des Sat-Receivers auf "absent" wechselt.

Mit dem attr repeatsame ist meines Wissens nur eine Feste Anzahl an Wiederholungen möglich.
Oder würde das DOIF bei repeatsame = 20 nach 2x abbrechen, wenn zwischenzeitlich der SatReceiver auf "absend" wechselt?
Dann könnte ich repeatsame einfach auf einen sehr hohen Wert setzen...

Code Auswählen Erweitern


define di_ReceiverAusschalten_pruefen DOIF
([Funksteckdose_SATReceiver] eq "off"
and [?SATReiver] eq "present")
(set Funksteckdose_SATReceiver off)


Viele Grüße,
Heiko

[Sunny]

Moin Heiko,

was ich noch nicht wusste, ist das 433Mhz Ihren Status übermitteln.
Das geht, wenn man weiß was man tut, mit DOIF schon jetzt.   

z.B.mit:

define di_ReceiverAusschalten_pruefen DOIF
   ([+00:05] and [Funksteckdose_SATReceiver:?state] eq "off"
     and [SATReiver] eq "present")
      (set Funksteckdose_SATReceiver off)
DOELSE
attr di_ReceiverAusschalten_pruefen cmdState alle_5min|aus
attr di_ReceiverAusschalten_pruefen do always

( ist aber ungetestet )

Eine von mehreren Möglichkeiten.
Zum lesen/lernen/testen einfach mal auf > Device specific help < klicken. 

Viele Grüße
Sunny

[heikoh81]

Hallo sunny,

danke, werde das mal nachvollziehen und probieren.

Eine Frage:
Wieso brauche ich "cmdState alle_5min" ist?
Das wird nirgends definiert, und auch nirgends ausgewertet bzw. auf on gesetzt?

was ich noch nicht wusste, ist das 433Mhz Ihren Status übermitteln.

Tun sie nicht, aber das Gerät, das ein/ausgeschaltet wird, hat eine LAN-Buchse (aber leider kein WOL, VU+ Solo...), die kann ich mit presence anpingen
Somit weiß ich, ob geschaltet wurde oder nicht.

Viele Grüße,
Heiko

[Sunny]

Moin Heiko,

Eine Frage:
Wieso brauche ich "cmdState alle_5min" ist?
Das wird nirgends definiert, und auch nirgends ausgewertet bzw. auf on gesetzt?

Sorry, aber hatte erst eine andere "Version" in der ein 2.tes DOELSEIF auf den Status von "di_ReceiverAusschalten_pruefen" abgefragt hat. Daher brauchst Du es nicht.
Werde es löschen. Definiert wurde es durch das attr... und geändert durch das "di_ReceiverAusschalten_pruefen" selbst.

Tun sie nicht, aber das Gerät, das ein/ausgeschaltet wird, hat eine LAN-Buchse (aber leider kein WOL, VU+ Solo...), die kann ich mit presence anpingen
Somit weiß ich, ob geschaltet wurde oder nicht.

Magst Du mir einen Link von der Steckdose und den ca. Preis verraten.

Viele Grüße
Sunny

[heikoh81]

Hallo Sunny,

Werde es löschen. Definiert wurde es durch das attr... und geändert durch das "di_ReceiverAusschalten_pruefen" selbst.Magst Du mir einen Link von der Steckdose und den ca. Preis verraten.

Ok. Was ich jetzt aber noch nicht verstehe: im Fall DOELSE wird "attr do always" gesetzt.
Aber wann wird "attr do always" wieder gelöscht? Das bleibt dann doch für immer erhalten, auch wenn wieder der DOIF-Fall eintritt?

Magst Du mir einen Link von der Steckdose und den ca. Preis verraten.

Ich bin mir nicht sicher, ob wir das gleiche meinen.
Die 433Mhz-Steckdose hat keine LAN-Buchse. Von dieser wird aber ein SAT-Receiver einfach vom Strom-Netz getrennt bzw. aufgeschaltet. Dieser Sat-Receiver (ein Enigma2-Receiver, konkret VU+ Solo) hat eine LAN-Buchse, und die kann ich anpingen. Gedanke: Wenn 230V an, dann SAT-Receiver an, dann erreiche ich nach dem Booten auch die LAN-Buchse per Ping.

Ich verwende mittlerweile bestimmt mehr als 40 Funksteckdosen von Pollin, konkret immer dieses Set:
http://www.pollin.de/shop/dt/MzMzOTQ0OTk-/Haustechnik/Funkschaltsysteme/Funksteckdosen_Set_mit_3_Steckdosen.html
Preis war bis 2015 noch 9,95€, also ein Spottpreis. Im aktuellen Katalog wurde der Preis auf 12,95€ erhöht. Geht immer noch.
Die Empfangseigenschaften sind ok, aber verglichen mit einer alten Intertechno (mit den Stellrädern hinten) ein wenig schlechter, zumindest funktioniert mit demselben CUL (433Mhz-Sender von ebay für 2€ an Raspi mit Pilight) die Intertechno zuverlässig, wo die von Pollin nicht immer funktionieren.

Viele Grüße,
Heiko

[Ellert]

Alternativ könnte dies auch klappen:

Code Auswählen Erweitern

define di_ReceiverAusschalten_pruefen DOIF ([Funksteckdose_SATReceiver] eq "off" and [?SATReiver] eq "present")
   (set Funksteckdose_SATReceiver off)
DOELSEIF (![SATReiver] eq "present")

mit

Code Auswählen Erweitern

attr di_ReceiverAusschalten_pruefen repeatcmd 300

repeatcmd ist performanter als [+00:05], da das DOIF nur einmal getriggert wird.

Aber wann wird "attr do always" wieder gelöscht? Das bleibt dann doch für immer erhalten, auch wenn wieder der DOIF-Fall eintritt?

do always wird nicht gelöscht. Es ist notwendig damit eine Bedingung wiederholt eintreten kann, also auch beim nächsten Ausschalten.

[heikoh81]

@Ellert:
Danke, deinen Vorschlag probiere ich auch aus.
Update: Funktioniert perfekt.
das hätte ich nämlich als nächstes gefragt, denn im Vorschlag von sunny wird das doif ja alle x minuten durchlaufen, und das will ich aus Performance-Gründen vermeiden.

@sunny:

Code Auswählen Erweitern


([+00:00:15] and [?TestSteckdoseSat] eq "off" and [?TestDummyPresence] eq "present")
(set Test_ChkBox on)
DOELSE
attr di_ReceiverAusschalten_pruefen do always

wird zwar alle 15 Sekunden getriggert, aber der cmd1 wird exakt 1 mal ausgeführt, nachdem entweder "TestSteckdoseSat = off" oder "TestDummyPresence = present" gesetzt wurde.

[Sunny]

Moin Heiko,

Was ich jetzt aber noch nicht verstehe: im Fall DOELSE wird "attr do always" gesetzt.
...auch wenn wieder der DOIF-Fall eintritt?

Dies sorgt nur dafür, das DOIF den Status ändert in "state cmd_2" und nicht nur "state cmd_1" hat.
Damit könntest Du sehen, ob das DOIF "geschaltet" hat.

Ich bin mir nicht sicher, ob wir das gleiche meinen.
Die 433Mhz-Steckdose hat keine LAN-Buchse.

Jupp, hatte ich anders verstanden.

@sunny:

Code Auswählen Erweitern


([+00:00:15] and [?TestSteckdoseSat] eq "off" and [?TestDummyPresence] eq "present")
(set Test_ChkBox on)
DOELSE
attr di_ReceiverAusschalten_pruefen do always


Hatte ich so auch nicht geschrieben und das Attribut "attr di_ReceiverAusschalten_pruefen do always" gehört nicht in das DEF-Fenster!
Freut mich, das Du eine Lösung gefunden hast.


Moin Ellert,

...

Code Auswählen Erweitern

attr di_ReceiverAusschalten_pruefen repeatcmd 300
...
repeatcmd ist performanter als [+00:05], da das DOIF nur einmal getriggert wird.

Vielen Dank für diese Info, werde dann meine DOIF's ändern. ( Habe ich das irgendwo überlesen ?)

Alternativ könnte dies auch klappen:

Code Auswählen Erweitern

define di_ReceiverAusschalten_pruefen DOIF ([Funksteckdose_SATReceiver] eq "off" and [?SATReiver] eq "present")
...


ist das auch performanter als:

Code Auswählen Erweitern

...DOIF
   ([Funksteckdose_SATReceiver:?state] eq "off"
     and [SATReiver] eq "present")...

Viele Grüße Euch Beiden von
Sunny

[Ellert]

Habe ich das irgendwo überlesen ?

http://forum.fhem.de/index.php/topic,43638.msg355904.html#msg355904

...DOIF
   ([Funksteckdose_SATReceiver:?state] eq "off"
     and [SATReiver] eq "present")...

Performance = 0, es lauscht auf Ereignisse die "state" enthalten und schaut, ob das Ergebnis gleich "off" ist, "state" ist immer ungleich "off".

Richtig wäre

Code Auswählen Erweitern

[Funksteckdose_SATReceiver:?off] das ist gleichwertig, weil nur einmal auf "off" getriggert wird.

[Sunny]

Moin Heiko,

Entschuldigung für meine Kaperung Deines Threads.
Hoffe Du kannst mir verzeihen.

Viele Grüße & einen angenehmen Sonntag
Sunny

                                                                                                                                                                                     
Moin Ellert,

den Link kannte ich nicht.

..."state" ist immer ungleich "off".

Vieleicht verstehe ich Dich nicht richtig, da z.B. bei IT und Dect 200 Steckdosen der "state" gleich "off" sein kann.

Code Auswählen Erweitern

Readings von einer AVM FRITZ!Dect 200 Steckdose:
state off 2016-01-10 08:20:32

Hoffe ich habe Dich richtig verstanden, das folgendes

Code Auswählen Erweitern

[?Funksteckdose_SATReceiver:off]dann die beste Per­for­manz hat.
Hierbei wird nicht auf alle Ereignisse die "off" enthalten gelauscht.

Was mir bewusst ist es dürfen nicht alle Bedingungen ein Fragezeichen enthalten. (Das hat zu 1. bis 3. geführt)
Sonst > "no trigger in condition"

Hoffe ich strapaziere Deine Geduld nicht zu sehr...

Drei Fragen hätte ich noch, ist es performanter auf:
1: die Zeit zu triggern?
2: häufig oder selten ändernde "Readings"?
3: Mehrere oder ein "Monster" DOIF's zu "benutzen"?

Viele Grüße & nochmals Danke für Deine Geduld
Sunny

PS: Werde jetzt, mit Deinen Tipps, versuchen die 9 DOIF's auf meinem Slave RPi+ zu optimieren und hoffe die CPU-Auslastung  von 3.23 % zu verringern.

[Ellert]

3.23 %

Ich glaube Du hast überhöhte Erwartungen an die Performanceverbesserung.

Vieleicht verstehe ich Dich nicht richtig, da z.B. bei IT und Dect 200 Steckdosen der "state" gleich "off" sein kann.

Die Zeichenkette "state" ist immer ungleich der Zeichenkette "off".

Hoffe ich habe Dich richtig verstanden, das folgendes
Code: [Auswählen]

[?Funksteckdose_SATReceiver:off]

dann die beste Per­for­manz hat.
Hierbei wird nicht auf alle Ereignisse die "off" enthalten gelauscht.

Was mir bewusst ist es dürfen nicht alle Bedingungen ein Fragezeichen enthalten. (Das hat zu 1. bis 3. geführt)
Sonst > "no trigger in condition"

Hoffe ich strapaziere Deine Geduld nicht zu sehr...

Drei Fragen hätte ich noch, ist es performanter auf:
1: die Zeit zu triggern?
2: häufig oder selten ändernde "Readings"?
3: Mehrere oder ein "Monster" DOIF's zu "benutzen"?

Die Aussage, die ich als "performanter" interpretiere kennst Du jetzt auch.

Für eigene Untersuchungen kanst Du apptime verwenden

[Damian]

Moin Heiko,

Entschuldigung für meine Kaperung Deines Threads.
Hoffe Du kannst mir verzeihen.

Viele Grüße & einen angenehmen Sonntag
Sunny

                                                                                                                                                                                     
Moin Ellert,

den Link kannte ich nicht.
Vieleicht verstehe ich Dich nicht richtig, da z.B. bei IT und Dect 200 Steckdosen der "state" gleich "off" sein kann.

Code Auswählen Erweitern

Readings von einer AVM FRITZ!Dect 200 Steckdose:
state off 2016-01-10 08:20:32

Hoffe ich habe Dich richtig verstanden, das folgendes

Code Auswählen Erweitern

[?Funksteckdose_SATReceiver:off]dann die beste Per­for­manz hat.
Hierbei wird nicht auf alle Ereignisse die "off" enthalten gelauscht.

Was mir bewusst ist es dürfen nicht alle Bedingungen ein Fragezeichen enthalten. (Das hat zu 1. bis 3. geführt)
Sonst > "no trigger in condition"

Hoffe ich strapaziere Deine Geduld nicht zu sehr...

Drei Fragen hätte ich noch, ist es performanter auf:
1: die Zeit zu triggern?
2: häufig oder selten ändernde "Readings"?
3: Mehrere oder ein "Monster" DOIF's zu "benutzen"?

Viele Grüße & nochmals Danke für Deine Geduld
Sunny

PS: Werde jetzt, mit Deinen Tipps, versuchen die 9 DOIF's auf meinem Slave RPi+ zu optimieren und hoffe die CPU-Auslastung  von 3.23 % zu verringern.

Man kann allgemein sagen, dass Event-Abfragen besser sind als ständiges pollen über Zeittrigger. Abfragen, die nicht triggern sollen, sollte man mit Fragezeichen angeben. Ein DOIF dürfte weniger Performance verbrauchen als mehrere, allerdings würde ich nach Möglichkeit pro Problem ein DOIF definieren und nicht künstlich verschiedene Problemlöser in ein DOIF packen, damit man seine Definitionen später noch selbst versteht.

Zusätzlich sollte man wissen, dass jedes Modul in FHEM, welches auf Events reagiert bei jedem Event im System immer aufgerufen wird und es muss selbst entscheiden, ob es mit dem Event etwas anfangen kann oder nicht.

Das ist allerdings alles akademisch, ich vermute, dass du noch nicht mal 1 % der Grundperformance reduzieren könntest, wenn du die Hälfte deiner Module löschen würdest (selbst das Deaktivieren reicht nicht, weil die Module trotzdem geweckt werden).

Gruß

Damian

[Sunny]

Moin Ellert,

als erstes mal Danke für Dein Zeit & Geduld.

Die Zeichenkette "state" ist immer ungleich der Zeichenkette "off".

Jetzt stellst Du mich aber voll auf den Schlauch. <Grübel AN>

Anwendungsbeispiel: Beschattungssteuerung abhängig von der Temperatur. ...die Temperatur über 26 Grad ist. Temperaturschwankungen um 26 Grad ...
define di_shutters DOIF ([sensor:temperature] > 26...

Folge ich Deiner Aussage, bedeutet das dann die Zeichenkette "temperature" immer kleiner der Zeichenkette "26" ist.

Code Auswählen Erweitern

## cmd_3 ## WarmWasser ist hoch, setze normal\
DOELSEIF\
(\
   [7_ww_RL:Temperatur] > 62\
   and\
   [Heizung_d:state] eq "WW_Hoch"\
   and\
   [Intern_Warm_Wasser:state] eq "on"\
) \
(\
    set Heizung_d Auto,\
    set Intern_Warm_Wasser off\
)\
DOELSE
Würde bei dem Beispiel bedeuten, die Zeichenkette "state" ist immer ungleich der Zeichenkette "WW_Hoch" und nicht funktionieren.
Funzt aber.

Für eigene Untersuchungen kanst Du apptime verwenden

Jupp, wird nur ziemlich schwierig werden, da die DOIF's per F2F eine Heizung steuern. (Ist um die 300KM entfernt...)

Viele Grüße
Sunny
                                                                                                                                                                                                                     
Moin Damian,

auch Dir erstmal ein Riesen DANK für Dein DOIF.
Ohne wäre ich noch nicht soweit mit der Anpassung von FHEM.

Man kann allgemein sagen, dass Event-Abfragen besser sind als ständiges pollen über Zeittrigger. Abfragen, die nicht triggern sollen, sollte man mit Fragezeichen angeben. Ein DOIF dürfte weniger Performance verbrauchen als mehrere, allerdings würde ich nach Möglichkeit pro Problem ein DOIF definieren und nicht künstlich verschiedene Problemlöser in ein DOIF packen, damit man seine Definitionen später noch selbst versteht.

Zusätzlich sollte man wissen, dass jedes Modul in FHEM, welches auf Events reagiert bei jedem Event im System immer aufgerufen wird und es muss selbst entscheiden, ob es mit dem Event etwas anfangen kann oder nicht.

Das ist allerdings alles akademisch, ich vermute, dass du noch nicht mal 1 % der Grundperformance reduzieren könntest, wenn du die Hälfte deiner Module löschen würdest (selbst das Deaktivieren reicht nicht, weil die Module trotzdem geweckt werden).

Upps, THX ! 
Habe mir auch nicht so viele Prozente vorgestellt. Bin aber auch noch lange nicht fertig mit "meinem Projekt"...
Ein DOIF pro Problem hatte ich zufälligerweise schon.
Versuche dann auf Event-Abfragen umstellen, wenn es überall funktioniert.
<OT an>
Und wenn man etwas neues lernt, kann man ja versuchen das möglichst nicht durch die Brust ins Auge um zusetzen.
(Muss gestehen der Anfang/erste Schritt mit DOIF war mindestens eine Steißgeburt oder ein Ironman, auch mit der commandref_DE.
Wenn es dann Klick gemacht hat kommt Freude auf und testet mehr bzw. verfeinert die ersten Versuche.)
<OT aus>

Viele Grüße & schönen Sonntag & viele Ideen 
Sunny

@Heiko: DANKE

PS: Denke das OWX mit z.Z. 9 DS18B20 OWTHERM per onkick, resolution=10 und interval=60 eher für leichte Verzögerungen sorgt.

[Ellert]

Würde bei dem Beispiel bedeuten, die Zeichenkette "state" ist immer ungleich der Zeichenkette "WW_Hoch" und nicht funktionieren.
Funzt aber.

Nein, Du vergleichst Äpfel mit Birnen.
Hiermit

Code Auswählen Erweitern

[Heizung_d:state] eq "WW_Hoch" fragst Du den Wert von [Heizung_d] ab, der kann "WW_Hoch" sein.

Und hiermit

Code Auswählen Erweitern

[Funksteckdose_SATReceiver:?state] fragst Du, ob im Ereignis von Funksteckdose_SATReceiver die Zeichenkette "state" vorhanden ist.
Den Bedeutungsunterschied erzeugt das Fragezeichen nach dem Doppelpunkt.

Einfach mal probieren, dann wird's klar

[Damian]

Man kann allgemein sagen, dass Event-Abfragen besser sind als ständiges pollen über Zeittrigger. Abfragen, die nicht triggern sollen, sollte man mit Fragezeichen angeben. Ein DOIF dürfte weniger Performance verbrauchen als mehrere, allerdings würde ich nach Möglichkeit pro Problem ein DOIF definieren und nicht künstlich verschiedene Problemlöser in ein DOIF packen, damit man seine Definitionen später noch selbst versteht.

Zusätzlich sollte man wissen, dass jedes Modul in FHEM, welches auf Events reagiert bei jedem Event im System immer aufgerufen wird und es muss selbst entscheiden, ob es mit dem Event etwas anfangen kann oder nicht.

Das ist allerdings alles akademisch, ich vermute, dass du noch nicht mal 1 % der Grundperformance reduzieren könntest, wenn du die Hälfte deiner Module löschen würdest (selbst das Deaktivieren reicht nicht, weil die Module trotzdem geweckt werden).

Gruß

Damian

Ich war selbst neugierig, wo in meinem FHEM-System die Zeit verbraucht wird:

Mit Hilfe des apptime-Befehls kann man sich den Verbrauch nach einer gewissen Laufzeit ausgeben lassen. Ich habe es hier nach der verbrauchten Gesamtzeit (total 5. Spalte) ausgeben lassen. Man kann sehen, dass die meiste Zeit hier für das Auslesen der 1-Wire- Sensoren verbraucht wird (erste Zeile) 97467 Millisekunden im Durchschnitt 2165 Millisekunden pro Aufruf, obwohl sie nur alle 300 Sekunden geprüft werden. Das erste DOIF-Modul in der Statistik von einigen, die ich bei mir definiert habe, findet man in der letzten Zeile mit 292 Millisekunden, im Durchschnitt verbrauchte das Modul pro Aufruf 0,09 Millisekunden. Man sollte sich also eher über seine eingebundenen Devices Gedanken machen, als über die Eventhandler, wie das DOIF-Modul.

Code Auswählen Erweitern

tmr-OWMULTI_GetValues      HASH(0x3f51e5c)   2214     45    97467  2165.93     57 HASH(Hy_Keller)
..               
          Anwesenheit          DOIF_Notify    180   3124      292     0.09      0 HASH(Anwesenheit); HASH(Alarm_Button)



Gruß

Damian