DOIF neue Features (Sleep-Alternative)

[Ralli]

Ich habe auch gerade nachgedacht und mir einen internen Lösungsweg überlegt (ist wahrscheinlich einfacher als ich dachte).

Eine Möglichkeit wäre die RegExp für Devices in Anführungszeichen zu setzen, z. B.
Alle Devices mit entsprechendem Event (mit Fragezeichen vor der Eventangabe wie bisher)

Code Auswählen Erweitern

[ ".*":?[Bb]attery.*[Ll]ow.*]

Also

Code Auswählen Erweitern


[".*":battery] eq "low"
[?".*":battery] eq "low"
[".*":?battery.*low]
[".*":&Internal] eq "blub"


Damit wären alle bisherigen Möglichkeiten plus Device-übergreifend abgedeckt! Top.

RegExp für Readings halte ich nicht für sinnvoll.

Ist doch über [".*":?battery.*low] abgedeckt?

Waittimer gelten immer für die entsprechenden Ausführungsteile nicht für Devices in der Bedingung  - das muss so bleiben.

Ja - aber .

Wie geschrieben sehe ich hier ein Problem, wenn sich ein alternativer Ausführungsteil auf einen Ausführungsteil beziehen soll, der von einem anderen Device angetriggert wurde. Also das klassische Device-Übergreifende Watchdog-Problem. Nochmal ein Beispiel:

define Beispiel DOIF (["device.*"] eq "on") (set dummy1 §dev1:NAME) DOELSEIF ([§dev1] eq "off") (set dummy2 §dev1:NAME)
attr doif wait 60:60

Wenn Bedingung1 zutrifft, dann dummy1 mit dem auslösenden Devicenamen setzen. Wenn dieses auslösende Device in den state "off" wechselt, dann den dummy2 mit dem Devicenamen des Auslösers setzen.

Wenn Du hingegen

define Beispiel DOIF (["device.*"] eq "on") (set dummy1 §dev1:$NAME) DOELSEIF (["device.*"] eq "off") (set dummy2 §dev1:NAME)
attr doif wait 60:60

verwendest, kann irgendein device1 die Bedingung1 erfüllen und irgendein device2 die Alternativ-Bedingung erfüllen. Auch sinnvoll aber nicht alleine glückbringend .

[Damian]

Ist doch über [".*":?battery.*low] abgedeckt?

hier wird das Event des Triggers ausgewertet nicht das Reading. Readings werden ohne Fragezeichen angegeben und ausgewertet. Diese müssen für das jeweilige Device eindeutig sein.

Wie geschrieben sehe ich hier ein Problem, wenn sich ein alternativer Ausführungsteil auf einen Ausführungsteil beziehen soll, der von einem anderen Device angetriggert wurde. Also das klassische Device-Übergreifende Watchdog-Problem. Nochmal ein Beispiel:

define Beispiel DOIF (["device.*"] eq "on") (set dummy1 §dev1:NAME) DOELSEIF ([§dev1] eq "off") (set dummy2 §dev1:NAME)
attr doif wait 60:60

Wenn Bedingung1 zutrifft, dann dummy1 mit dem auslösenden Devicenamen setzen. Wenn dieses auslösende Device in den state "off" wechselt, dann den dummy2 mit dem Devicenamen des Auslösers setzen.

Wenn Du hingegen

define Beispiel DOIF (["device.*"] eq "on") (set dummy1 §dev1:$NAME) DOELSEIF (["device.*"] eq "off") (set dummy2 §dev1:NAME)
attr doif wait 60:60

verwendest, kann irgendein device1 die Bedingung1 erfüllen und irgendein device2 die Alternativ-Bedingung erfüllen. Auch sinnvoll aber nicht alleine glückbringend .

Das wird auch der Grund sein, warum Rudi den Watchdog nicht devices-übergreifend programmiert hat. Auch im DOIF ist die einzige Gemeinsamkeit der Zustand des Moduls, ansonsten "wissen" die Bedingungen nichts von einander. Alles andere ist schwierig, weil man beliebig Bedingungen definieren kann.

Gruß

Damian

[Ralli]

Ja, genau da liegt die besondere Herausforderung.

Wäre es nicht eine Idee, pro auslösendem Device einen Readings-Satz anzulegen, so wie Du es ja jetzt eigentlich schon für die auslösenden Trigger der tangierten Devices machst?

Es gibt ja bspw.

cmd_event GEN_Aussensensor 2015-07-28 13:46:19
cmd_nr 5 2015-07-28 13:46:19
e_GEN_Aussensensor_luminosity 7653 2015-07-28 16:18:41
e_GEN_Aussensensor_temperature 23.3 2015-07-28 16:18:41
e_Wetter_condition überwiegend wolkig 2015-07-28 16:13:52
e_Wetter_fc1_condition teilweise wolkig 2015-07-28 16:13:52
e_Wetter_fc1_high_c 19 2015-07-28 16:13:52

Um auslösende Devices mit zu erfassen, könnte man es doch genau so machen - pro auslösendem Device mit Reading und Value und Zeitstempel halt ein e_....

Dann müsste nur noch die Art und Weise der Weiterverarbeitung in den jeweiligen DOIF-Zweigen und -Bedingungen durchdacht werden und natürlich auch eine Variablen-Belegung für das aktuell triggernde Device und auslösende Event (also $NAME und $EVENT). Zum Beispiel nach folgendem Schema:

define Beispiel DOIF ([".*":battery] eq "low") (set dummy1 $NAME) DOELSEIF ([".*":battery] eq "ok" and [?Beispiel:e_$NAME_battery_prev] eq "low") (set dummy2 $NAME)
attr doif wait 60:0

... setze also dummy1 mit dem auslösenden Device, wenn 60 Sekunden kein anderer state erfolgt (und wenn noch kein e_$NAME_battery-Reading, lege es an mit den entsprechenden Werten; wenn bereits ein e_$NAME_battery besteht, schiebe die "alten" Werte in e_$NAME_battery_prev und belege die Werte von e_$NAME_battery neu). Ein anderer State kann erfolgen, wenn irgendein Device (also auch das primär auslösende) ok ist UND für dieses Device ein Reading (s.o.) im eigenen DOIF besteht, welches den Wert low hat.

[Damian]

Ja, genau da liegt die besondere Herausforderung.

Wäre es nicht eine Idee, pro auslösendem Device einen Readings-Satz anzulegen, so wie Du es ja jetzt eigentlich schon für die auslösenden Trigger der tangierten Devices machst?

Es gibt ja bspw.

cmd_event GEN_Aussensensor 2015-07-28 13:46:19
cmd_nr 5 2015-07-28 13:46:19
e_GEN_Aussensensor_luminosity 7653 2015-07-28 16:18:41
e_GEN_Aussensensor_temperature 23.3 2015-07-28 16:18:41
e_Wetter_condition überwiegend wolkig 2015-07-28 16:13:52
e_Wetter_fc1_condition teilweise wolkig 2015-07-28 16:13:52
e_Wetter_fc1_high_c 19 2015-07-28 16:13:52

Um auslösende Devices mit zu erfassen, könnte man es doch genau so machen - pro auslösendem Device mit Reading und Value und Zeitstempel halt ein e_....

Dann müsste nur noch die Art und Weise der Weiterverarbeitung in den jeweiligen DOIF-Zweigen und -Bedingungen durchdacht werden und natürlich auch eine Variablen-Belegung für das aktuell triggernde Device und auslösende Event (also $NAME und $EVENT). Zum Beispiel nach folgendem Schema:

define Beispiel DOIF ([".*":battery] eq "low") (set dummy1 $NAME) DOELSEIF ([".*":battery] eq "ok" and [?Beispiel:e_$NAME_battery] eq "low") (set dummy2 $NAME)
attr doif wait 60:0

... setze also dummy1 mit dem auslösenden Device, wenn 60 Sekunden kein anderer state erfolgt. Ein anderer State kann erfolgen, wenn irgendein Device (also auch das primär auslösende) ok ist UND für dieses Device ein Reading im eigenen DOIF besteht, welches den Wert low hat.

ja, da muss man sich ein schlüssiges Konzept ausdenken und paar mal drüber schlafen.

Gruß

Damian

[Ralli]

Daumen hoch !! (hab oben noch mal was geändert)

Nach einigem Denken ist mir noch was eingefallen, was bei o.a. Konstellation mit bedacht werden muss:

Device 1 triggert auf cmd_1 und löst den wait-timer aus.
Device 2 kämme nun auch noch mit einem battery low.
Device 2 kommt nun innerhalb von 60 Sekunden wieder mit einem battery ok. cmd_2 löst damit aus und unterbricht den wait-timer von cmd_1.
Device 1 ist zwar immer noch low, triggert aber nicht mehr.

Somit wäre eigentlich folgende Funktionalität (also doch RegExp auf Reading) erforderlich, um das abzufangen:

define Beispiel DOIF ([".*":battery] eq "low") (set dummy1 $NAME) DOELSEIF ([".*":battery] eq "ok" and !([?"Beispiel:e_.*_battery.*low"])) (set dummy2 $NAME)
attr Beispiel wait 60:0

Sollte bewirken, dass irgendein Device mit Battery=low den wait-timer für cmd_1 auslöst. cmd_2 wird nur ausgelöst (und unterbricht damit cmd_1), wenn ein Device Battery=ok meldet UND KEIN EINZIGES aktuelles(!) Battery-Reading irgendeines Devices im DOIF mehr mit Wert low existiert (immer davon ausgehend, dass vor der Auswertung der Readings bereits diese Readings mit den Device- und Event-Werten des Triggers gefüttert werden bzw. die alten in ..._prev geschoben werden).

[Skusi]

Ich muß hier mal eben was loswerden:

@Damian
Ich bin begeistert was man alles mit Deinem DOIF Modul anstellen kann. Jetzt wo Du auch noch die erweiterten Wait Funktionen eingebaut hast, ist mein config gleich wieder einwenig geschrumpft. Ich bin erst seit gut einem halben Jahr Fhem infiziert, und so ziemlich früh mit DOIF in Berührung gekommen. Also ich meine ich kenne die Zeiten vor DOIF nicht.

Ich habe von Anfang an versucht so wenig verschiedenen Module wie möglich einzusetzen. So versuche ich meine Ideen immer erst per DOIF zu lösen und nur wenn das nicht geht, greife ich zur commandref.

Leider konnte ich dank Deines Moduls noch nicht alzuviele Module einsetzten, weil einfach jede noch so kranke Idee mit DOIF umsetzbar war.
Manchmal habe ich das Gefühl das ich nicht mit Fhem sondern mit DOIF arbeite

Lange Rede... Ein groooßes Lob und Danke Schön für Deine Arbeit.

Ich ziehe den Hut vor soviel Einfallsreichtum und Energie, und freue mich über jede weitere Entwicklung dieses in meinen Augen schon perfekten Moduls. Ich hoffe nur Du packst nicht irgendwann soviel Features hinein, das es instabil wird.

Also, weiter so....

--Skusi

[All-Ex]

Hi Damian!

Hast du einen konkreten Anwendungsfall? Normalerweise hängen Zeiten mit Wochentagen zusammen und die kann man mit or verknüpfen.

Ich habe eine sonnenstandsabhängige Rollladensteuerung mit DOIF gebaut. An einem Wochentag ist "Putztag", während dessen von einer Start- bis zu einer Endeuhrzeit die Rollläden nicht bewegt werden sollen, um das Fensterputzen nicht zu stören.

Aktuell habe ich den Putztag fest auf Donnerstag (4) eingestellt:

Code Auswählen Erweitern

([wet.twilight:azimuth]>124 and
[wet.twilight:azimuth]<266 and
[wet.yrno:temp]>22 and
not [?[putztag.start]-[putztag.ende]|4])
(set <fahre rollos halb runter...>)
DOELSEIF
(<irgendwann>)
(<fahre Rollos wieder rauf...>)

Um auch für den Wochentag einen Dummy zu verwenden, der im Webinterface konfiguriert werden kann, könnte ich wahrscheinlich in etwa dies bauen:

Code Auswählen Erweitern

and not ([?[putztag.start]-[putztag.ende]] and $wday==[?putztag.tag])

Aber eleganter und einfacher zu lesen wäre m.E.

Code Auswählen Erweitern

and not [?[putztag.start]-[putztag.ende]|[putztag.tag]]

Viele Grüße,
Alex

[Damian]

Hi Damian!Ich habe eine sonnenstandsabhängige Rollladensteuerung mit DOIF gebaut. An einem Wochentag ist "Putztag", während dessen von einer Start- bis zu einer Endeuhrzeit die Rollläden nicht bewegt werden sollen, um das Fensterputzen nicht zu stören.

Aktuell habe ich den Putztag fest auf Donnerstag (4) eingestellt:

Code Auswählen Erweitern

([wet.twilight:azimuth]>124 and
[wet.twilight:azimuth]<266 and
[wet.yrno:temp]>22 and
not [?[putztag.start]-[putztag.ende]|4])
(set <fahre rollos halb runter...>)
DOELSEIF
(<irgendwann>)
(<fahre Rollos wieder rauf...>)

Um auch für den Wochentag einen Dummy zu verwenden, der im Webinterface konfiguriert werden kann, könnte ich wahrscheinlich in etwa dies bauen:

Code Auswählen Erweitern

and not ([?[putztag.start]-[putztag.ende]] and $wday==[?putztag.tag])

Aber eleganter und einfacher zu lesen wäre m.E.

Code Auswählen Erweitern

and not [?[putztag.start]-[putztag.ende]|[putztag.tag]]

Viele Grüße,
Alex

OK, kommt dann auf die Todo-Liste.

Gruß

Damian

[Damian]

Ich muß hier mal eben was loswerden:

@Damian
Ich bin begeistert was man alles mit Deinem DOIF Modul anstellen kann. Jetzt wo Du auch noch die erweiterten Wait Funktionen eingebaut hast, ist mein config gleich wieder einwenig geschrumpft. Ich bin erst seit gut einem halben Jahr Fhem infiziert, und so ziemlich früh mit DOIF in Berührung gekommen. Also ich meine ich kenne die Zeiten vor DOIF nicht.

Ich habe von Anfang an versucht so wenig verschiedenen Module wie möglich einzusetzen. So versuche ich meine Ideen immer erst per DOIF zu lösen und nur wenn das nicht geht, greife ich zur commandref.

Leider konnte ich dank Deines Moduls noch nicht alzuviele Module einsetzten, weil einfach jede noch so kranke Idee mit DOIF umsetzbar war.
Manchmal habe ich das Gefühl das ich nicht mit Fhem sondern mit DOIF arbeite

Lange Rede... Ein groooßes Lob und Danke Schön für Deine Arbeit.

Ich ziehe den Hut vor soviel Einfallsreichtum und Energie, und freue mich über jede weitere Entwicklung dieses in meinen Augen schon perfekten Moduls. Ich hoffe nur Du packst nicht irgendwann soviel Features hinein, das es instabil wird.

Also, weiter so....

--Skusi

Danke für´s Kompliment. Keine Sorge, immerhin greife ich auf mehr oder weniger 30 Jahre Softwareentwicklung zurück, das letzte Jahrzehnt allerdings nur privat, beruflich unterrichtend, da weiß ich, dass man vorsichtig Neuerungen einführen muss. Nicht umsonst ist diese Version noch nicht eingecheckt, weil sie an zentraler Stelle Änderungen erfahren hat. Wenn genügend Tester sich nicht beschweren und mein Haus in den nächsten Tagen nicht explodiert ist , werde ich sie einchecken.

Gruß

Damian

[FunkOdyssey]

Ich kann mich dem Lob voll und ganz anschließen. Ich kenne Fhem erst seit kurzem. Und kenne auch kaum andere Module außerhalb der DOIF-Welt. Wobei die Entwickler sicherlich auch eine wahre Meisterleistung abliefern.

Damian, danke dir. Fürs Modul und für den Support.

[All-Ex]

OK, kommt dann auf die Todo-Liste.

Gruß

Damian

Perfekt, Danke

[Damian]

Version 0.6

Neue Readings im Modul:

Device  (aktuelles Device des Triggers)

Event (aktuelles Event)

Beide Readings lassen sich im Ausführungsteil abfragen - sie werden vor der Ausführung bereits gesetzt.

Gruß

Damian

[Ralli]

Damian, vielen vielen Dank!

Der erste Schritt für generisch-Device-übergreifende DOIFs, toll!

Nun bin ich ein paar Tage (leider ) nicht in der Lage, fleissig mit zu experimentieren, bin unterwegs. Daher die Frage, wie hast Du es nun realisiert, gibt es Device-spezifische Events, also pro Device ein Event-Reading? Da du nun (in meinen Augen richtigerweise) das Reading vor der Abarbeitung setzt, baust du noch ein prev(ious)-Reading pro Device ein, wo der zuletzt auslösende Event immer mitgeführt wird? Würde einige Dinge in der Abarbeitung vereinfachen (siehe mein Beitrag weiter oben).

[FunkOdyssey]

Ich habe erstmal die PM-Datei aus dem ersten Post hochgeladen und ein Reload durchgeführt.

Ich weiß (noch) nicht, ob das zusammenhängt, aber es erschienen folgende Fehler und nun ist mein FHEM nicht mehr erreichbar. Ich begebe mich auf Fehlersuche.

Code Auswählen Erweitern

Too many arguments for main::DOIF_SetSleepTimer at ./FHEM/98_DOIF.pm line 712, near "1)"
Too many arguments for main::DOIF_cmd at ./FHEM/98_DOIF.pm line 713, near "$event)"
Too many arguments for main::DOIF_SetSleepTimer at ./FHEM/98_DOIF.pm line 748, near "$timerNr)"
Too many arguments for main::DOIF_SetSleepTimer at ./FHEM/98_DOIF.pm line 761, near "$timerNr)"


Update: Sieht nach Fehlalarm aus. Scheinbar hatte ich einen anderen Bock im System. Sorry.

[RoBra81]

Hallo,

nach dem Einspielen der Datei ist ein shutdown restart erforderlich (steht irgendwo im Thread - ich glaube, erster Post)...

Ronny