DOIF neue Features (Sleep-Alternative)

[Damian]

Version 0.4 im ersten Post.

- Problembehebung
- das disable-Attribut deaktiviert jetzt komplett das Modul (Timer werden gelöscht) weniger Performanceverbrauch
-

Code Auswählen Erweitern

set disable  setzt das Modul in Zustand disable (Timer laufen weiter) der Zustand bleibt auch nach einem Neustart
-

Code Auswählen Erweitern

set initialize aktiviert ein inaktives Modul, bzw. setzt den Status auf initialized - der nächste Trigger führt zur Ausführung
- rechnen mit Waittimern, z. B.

Code Auswählen Erweitern

attr di_modul wait ([wait_time1]+[wait_time2]-1)*2
- neues Attribut timerWithWait, wenn das Attribut gesetzt wird, wird auch bei Timern wait berücksichtigt.

Gruß

Damian

[Damian]

Hallo!

Bekomme ich auch einen Wait timer bei diesem Code hin?

Code Auswählen Erweitern

([AbendLicht] eq "on") ({HueOnSofa};{HueOnSideBoard})

Wo soll der Waittimer hinkommen? Was ist HueOnSofa bzw. HueOnSideBoar?

Gruß

Damian

[Steffen]

Wo soll der Waittimer hinkommen? Was ist HueOnSofa bzw. HueOnSideBoar?

Gruß

Damian

Das sind jeweils zwei Perl Scripte die meine hue steuern mit Farbe und Dimmzeit und würde gerne den WaitTimer benutzen um die Scripte zeit verzörgert zu starten.

Würde das gehen?

Mfg Steffen

[Damian]

Das sind jeweils zwei Perl Scripte die meine hue steuern mit Farbe und Dimmzeit und würde gerne den WaitTimer benutzen um die Scripte zeit verzörgert zu starten.

Würde das gehen?

Mfg Steffen

Warum sollte es nicht gehen?

z. B.

Code Auswählen Erweitern

([AbendLicht] eq "on") ({HueOnSofa}) ({HueOnSideBoard})

attr di_dein_modul wait 10,20

Edit: habe es gerade korrigiert

Gruß

Damian

[Loredo]

Hallo Damian,


wird bei der Verwendung der neuen wait Sleep Funktion auch noch das cmdState Attribut entsprechend erweitert?
Mir ist aufgefallen, dass der Status zwischendurch cmd_X_Y ist und nicht meiner cmdState Definition entspricht. Es sollte also zumindest bei vorhandenem cmdState der dort definierte Status auch für die Sub-Tasks hergenommen werden oder cmdState sollte dafür erweitert werden die Status mit Komma abgetrennt (optional) ebenfalls mit anzugeben.




Gruß
Julian

[Damian]

Hallo Damian,


wird bei der Verwendung der neuen wait Sleep Funktion auch noch das cmdState Attribut entsprechend erweitert?
Mir ist aufgefallen, dass der Status zwischendurch cmd_X_Y ist und nicht meiner cmdState Definition entspricht. Es sollte also zumindest bei vorhandenem cmdState der dort definierte Status auch für die Sub-Tasks hergenommen werden oder cmdState sollte dafür erweitert werden die Status mit Komma abgetrennt (optional) ebenfalls mit anzugeben.




Gruß
Julian

Es geht hier um Zwischenzustände. Für Endzustände bleibt bei cmdState alles wie bisher. Es wäre kein Problem kommagetrennte Zwischenzustände zu erlauben, es dürfte dann allerdings kein Komma im cmd-String in den bisherigen (und zukünftigen) Definitionen geben, sonst ist man nicht abwärtskompatibel.

Gruß

Damian

[Loredo]

Es geht hier um Zwischenzustände. Für Endzustände bleibt bei cmdState alles wie bisher.

Hm, ich frage in meinen Eventauswertungen sehr häufig den Status des DOIF Moduls selbst mittels [?di_name:state] ab (insbesondere meiner Beschattungssteuerung). Damit kann es dann also vorkommen, dass eine zuvor wahre Aussage während der Abarbeitung der verschiedenen Kommandos wieder unwahr wird, richtig? Hat das eine Auswirkung, sprich wird nach jedem Sleep nochmals geprüft und bei unwahr ggf. abgebrochen? Kann ja auch wünschenswert sein, nur eben (wie meist bei mir) nicht immer... deshalb war mir die Angabe des Zwischenzustandes im state aufgefallen.


Mit der Abwärtskompatibilität beim cmdState Attribut hast du natürlich recht. Unschön dabei, dass man dann inzwischen mehr und mehr unterschiedliche Notationen in Attributen vorfindet. Da blickt man bald nicht mehr so leicht durch 

[Damian]

Hm, ich frage in meinen Eventauswertungen sehr häufig den Status des DOIF Moduls selbst mittels [?di_name:state] ab (insbesondere meiner Beschattungssteuerung). Damit kann es dann also vorkommen, dass eine zuvor wahre Aussage während der Abarbeitung der verschiedenen Kommandos wieder unwahr wird, richtig? Hat das eine Auswirkung, sprich wird nach jedem Sleep nochmals geprüft und bei unwahr ggf. abgebrochen? Kann ja auch wünschenswert sein, nur eben (wie meist bei mir) nicht immer... deshalb war mir die Angabe des Zwischenzustandes im state aufgefallen.


Mit der Abwärtskompatibilität beim cmdState Attribut hast du natürlich recht. Unschön dabei, dass man dann inzwischen mehr und mehr unterschiedliche Notationen in Attributen vorfindet. Da blickt man bald nicht mehr so leicht durch 

Es gibt mehrere Lösungsansätze. Man könnte z. B. über ein (neues) Attribut das Setzen der Zwischenzustände abschalten oder erst mal grundsätzlich per default den Status mit Zwischenzuständen nicht belegen und per Attribut einschaltbar machen. Ich kann noch nicht abschätzen was günstiger wäre.

Andererseits könntest du in deinen Abfragen statt DOELSE, z. B.  DOELSEIF ([di_modul:cmd2]) abfragen.

Gruß

Damian

[Damian]

Mal zur Info:

Man kann jetzt mit der neuen Version auch solche Sachen machen:

Code Auswählen Erweitern

define di_Zufall DOIF ([:00]) (set bla on)

attr di_Zufall do always
attr di_Zufall timerWithWait
attr di_Zufall wait rand(60)


Gruß

Damian

[Ralli]

Hallo Damian,

da Du momentan wieder so aktiv programmierst, wollte ich Dich nochmal auf das Thema RegExp auf mehrere Devices bringen - ja ich weiß, ist nicht unbedingt DIREKT in Perl umsetzbar.

Aber Du findest ganz bestimmt eine interne Lösung

Für z.B. solche Sachen, die jetzt über Umweg realisiert werden:

Code Auswählen Erweitern


define Helper notify .*:[Bb]attery.*[Ll]ow.* {
  if (!($defs{"DOIF_lowbat_".$NAME})) {fhem("
     define DOIF_lowbat_".$NAME." DOIF ([".$NAME.":?[Bb]attery.*[Ll]ow.*]) (set UEA.Batterie_niedrig ".$NAME.")
     DOELSEIF ([".$NAME.":?[Bb]attery.*[Oo][Kk].*]) ()");fhem("
     attr DOIF_lowbat_".$NAME." wait 3600:0");fhem("
     define trigger_".$NAME." at +00:00:05 trigger ".$NAME)
  }
}


[Damian]

Hallo Damian,

da Du momentan wieder so aktiv programmierst, wollte ich Dich nochmal auf das Thema RegExp auf mehrere Devices bringen - ja ich weiß, ist nicht unbedingt DIREKT in Perl umsetzbar.

Aber Du findest ganz bestimmt eine interne Lösung

Für z.B. solche Sachen, die jetzt über Umweg realisiert werden:

Code Auswählen Erweitern


define Helper notify .*:[Bb]attery.*[Ll]ow.* {
  if (!($defs{"DOIF_lowbat_".$NAME})) {fhem("
     define DOIF_lowbat_".$NAME." DOIF ([".$NAME.":?[Bb]attery.*[Ll]ow.*]) (set UEA.Batterie_niedrig ".$NAME.")
     DOELSEIF ([".$NAME.":?[Bb]attery.*[Oo][Kk].*]) ()");fhem("
     attr DOIF_lowbat_".$NAME." wait 3600:0");fhem("
     define trigger_".$NAME." at +00:00:05 trigger ".$NAME)
  }
}


So etwas könnte man auf Events einschränken, also nur in Kombination mit Fragezeichen. Allerdings müsste ich intern einiges umstellen. Ich kann es auf die Todo-Liste setzen.

Gruß

Damian

                                   

[Ralli]

Sehr schön  Danke !

Ich denke, hier ist in zwei Richtungen zu denken:

1) In den Bedingungen eines DOIF auf unbestimmte Devices zu triggern (also z.B. mittels RegExp wie bei notify oder watchdog) ist das eine und dürfte - auch bei wahrscheinlich einigen Umstellungen - noch gut realisierbar sein.
2) Die eigentliche Herausforderung wird sein, zu erreichen, entsprechende "Nachbedingungen" dem auslösenden Device zuzordnen, dafür werden wahrscheinlich pro auslösendem Device entsprechende InternalDOIFs gebaut werden müssen.

Also:

define doif wenn device.*:Bedingung dann set dummy1 $NAME sonst set dummy2 $NAME
attr doif wait 60:60

Nun kann device.*:Bedingung durch mehrere Devices ausgelöst werden. Pro auslösendem Device sollten die auslösenden wait-timer mitgeführt und dann die entsprechenden cmd_1 bzw. cmd_2 ausgelöst werden. Die einfachere aber unflexiblere Möglichkeit wäre, die wait-timer und cmd-Auslösung "einfach" mitzuführen und auszulösen - wenn das Suchmuster passt, wird halt getriggert, dann sollte aber zumindest vor der weiteren Abarbeitung des DOIF irgendwo das auslösende Device und der auslösende Event verarbeitbar sein. So besteht nur die Gefahr, dass die Bedingung 1 durch ein Device gesetzt und die Sonst-Bedingung 2 durch ein anderes Device gesetzt werden kann. Schön wäre es daher, in DOELSEIF-Bedingungen auf das Device reagieren zu können, was in der DOIF-Definition auch den Auslöser gesetzt hat.

Hartes Stück Arbeit.

[Damian]

Sehr schön  Danke !

Ich denke, hier ist in zwei Richtungen zu denken:

1) In den Bedingungen eines DOIF auf unbestimmte Devices zu triggern (also z.B. mittels RegExp wie bei notify oder watchdog) ist das eine und dürfte - auch bei wahrscheinlich einigen Umstellungen - noch gut realisierbar sein.
2) Die eigentliche Herausforderung wird sein, zu erreichen, entsprechende "Nachbedingungen" dem auslösenden Device zuzordnen, dafür werden wahrscheinlich pro auslösendem Device entsprechende InternalDOIFs gebaut werden müssen.

Also:

define doif wenn device.*:Bedingung dann set dummy1 $NAME sonst set dummy2 $NAME
attr doif wait 60:60

Nun kann device.*:Bedingung durch mehrere Devices ausgelöst werden. Pro auslösendem Device sollten die auslösenden wait-timer mitgeführt und dann die entsprechenden cmd_1 bzw. cmd_2 ausgelöst werden. Die einfachere aber unflexiblere Möglichkeit wäre, die wait-timer und cmd-Auslösung "einfach" mitzuführen und auszulösen - wenn das Suchmuster passt, wird halt getriggert, dann sollte aber zumindest vor der weiteren Abarbeitung des DOIF irgendwo das auslösende Device und der auslösende Event verarbeitbar sein. So besteht nur die Gefahr, dass die Bedingung 1 durch ein Device gesetzt und die Sonst-Bedingung 2 durch ein anderes Device gesetzt werden kann. Schön wäre es daher, in DOELSEIF-Bedingungen auf das Device reagieren zu können, was in der DOIF-Definition auch den Auslöser gesetzt hat.

Hartes Stück Arbeit.

Ich habe auch gerade nachgedacht und mir einen internen Lösungsweg überlegt (ist wahrscheinlich einfacher als ich dachte). Nach außen muss man die RegExp besonders kennzeichnen, sonst kann ich intern nicht zwischen Devices und Zeiten unterscheiden.

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.*]

Status des Trigger-Devices, das "window" im Namen beinhaltet (im Gegensatz zu notify wird intern kein ^ und $ gesetzt)

["window":state]

ohne Triggerung, wie bisher mit Fragezeichen vor dem Device.

[?"window":state]

Reading "state" des Trigger-Devices, das "window" im Namen beinhalten.

Code Auswählen Erweitern

["window":state]

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

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

Gruß

Damian

[All-Ex]

Damian, Danke für die Weiterentwicklung  Die neue Sleep-Variante und Zufallszahlen im Wait kann ich gut gebrauchen!

Eine Erweiterungsidee habe ich noch. Heute geht bereits:

Indirekte Zeitangaben lassen sich mit Wochentagangaben kombinieren, z. B.:
define di_time DOIF ([[begin]-[end]|7]) (set radio on) DOELSE (set radio off)

Dort den Wochentag auch als Variable anzugeben wäre total hilfreich, also so:

Code Auswählen Erweitern

define di_time DOIF ([[begin]-[end]|[day]]) (set radio on) DOELSE (set radio off)

Grüße
Alex

[Damian]

Damian, Danke für die Weiterentwicklung  Die neue Sleep-Variante und Zufallszahlen im Wait kann ich gut gebrauchen!

Eine Erweiterungsidee habe ich noch. Heute geht bereits:
Dort den Wochentag auch als Variable anzugeben wäre total hilfreich, also so:

Code Auswählen Erweitern

define di_time DOIF ([[begin]-[end]|[day]]) (set radio on) DOELSE (set radio off)

Grüße
Alex

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

Gruß

Damian