DOIF: neue Zeit-Features

[Pfriemler]

@flurin: ich meinte das Beispiel aus #70 und Rallis Einwand in #72. Durch einen entsprechenden Tausch sollte sich das doch ändern? Oder führt wie aktuell bei den Zeiten ein Event als einziger Trigger eines Zweiges dazu, dass alle betreffenden Zweige geprüft werden, auch wenn bereits einer zutraf? Dann wäre ja hier das "DOALSOIF" genauso angebracht.
Elseif-Strukturen in anderen Sprachen arbeiten m.W. immer so, dass die erste erfolgreiche Bedingung abgearbeitet und in diesem Fall keine weiteren Bedingungen mehr geprüft werden.

geht nich Gips nich ...

[Damian]

@flurin: ich meinte das Beispiel aus #70 und Rallis Einwand in #72. Durch einen entsprechenden Tausch sollte sich das doch ändern? Oder führt wie aktuell bei den Zeiten ein Event als einziger Trigger eines Zweiges dazu, dass alle betreffenden Zweige geprüft werden, auch wenn bereits einer zutraf? Dann wäre ja hier das "DOALSOIF" genauso angebracht.
Elseif-Strukturen in anderen Sprachen arbeiten m.W. immer so, dass die erste erfolgreiche Bedingung abgearbeitet und in diesem Fall keine weiteren Bedingungen mehr geprüft werden.

geht nich Gips nich ...

Grundsätzlich gilt:

1. Ein Trigger kann nur zur Ausführung eines Zweiges führen.

2. Es werden nur Bedingungen überprüft, wo der Trigger vorkommt (Device oder Zeit)

Gruß

Damian

[flurin]

@flurin: ich meinte das Beispiel aus #70 und Rallis Einwand in #72. Durch einen entsprechenden Tausch sollte sich das doch ändern? Oder führt wie aktuell bei den Zeiten ein Event als einziger Trigger eines Zweiges dazu, dass alle betreffenden Zweige geprüft werden, auch wenn bereits einer zutraf? Dann wäre ja hier das "DOALSOIF" genauso angebracht.
Elseif-Strukturen in anderen Sprachen arbeiten m.W. immer so, dass die erste erfolgreiche Bedingung abgearbeitet und in diesem Fall keine weiteren Bedingungen mehr geprüft werden.

geht nich Gips nich ...

@Pfriemler

In deinem Posting #82 hast du mich zitiert. Ich konnte aus deinem Text nicht ableiten, worauf du dich bezogen hast.
Aber jetzt ist es klar. Wie gesagt, die Abhängigkeit der Reihenfolge zu vermeiden, finde ich bei DOIF sinnvoll.
Zudem kann man ein DOIF aufteilen, wenn es Konflikte gibt (siehe auch defensives Programmieren).

Im Commandref heisst es:

Syntax angelehnt an Verzweigungen if - elseif - ... - elseif - else in höheren Sprachen

DOIF hat jedoch zusätzliche Eigenschaften und verhält sich nicht wie das "if" in höheren Sprachen.

[Damian]

DOIF hat jedoch zusätzliche Eigenschaften und verhält sich nicht wie das "if" in höheren Sprachen.

ja, den Unterschied machen Trigger aus, die eine Aktion auslösen - die gibt es in höheren Sprachen bei "if" so nicht. Das macht die Sache etwas komplexer.

Gruß

Damian

[Ralli]

Danke für den regen Austausch .

Also rein logisch betrachtet wäre es für die Abarbeitung eines DOIF sinnvoller, erst mal alle in der DOIF-Def vorhandenen Trigger "zu sammeln" bzw. auch zu konsolidieren (Stichwort gleiche Zeitangaben als Trigger) und dann rein strukturiert die Zweige mit ihren logischen Bedingungsprüfungen jeweils vom Start weg abzuarbeiten - egal, ob ein Trigger bspw. erst im dritten DOELSEIF auftaucht.

Dass das in der Programmierung komplex und nicht einfach ist, glaube ich gerne .

[Pfriemler]

Ich wiederhole mich: Zuerst ist man geneigt zu vermuten, das stets das gesamte DOIF gecheckt wird und als Trigger jedes irgendwo als Trigger definiertes Event im DOIF dient (so wie Ralli es eben vorschlägt). Wer "ElseIf" liest und es aus anderen Sprachen kennt, ist dann doch verwundert, wenn sich ein DOELSEIF nicht genauso verhält, wie es die Beispiele mit den Triggerzeiten und auch der Umstand, dass nur Bedingungszweige gecheckt werden, in denen der Trigger vorkommt, zeigen. DOIF verstehe ich stattdessen also als eine Sammlung von Bedingungsgruppen, deren letztes Zutreffen sich das DOIF zudem als Zustand merkt, und zwar jeweils nur den letzten, auch wenn sich mehrere Zweige quasi gleichzeitig als wahr erweisen und möglichweise auch ausgeführt werden.
ABER: Man kann hier nicht alles gleichzeitig haben, und es gibt ja genügend vernünftige Gründe es so zu tun wie es Damian umgesetzt hat, und mit

... die Abhängigkeit der Reihenfolge zu vermeiden, finde ich bei DOIF sinnvoll.

hat flurin auch absolut recht. Eine zusätzliche Abfrage in der entsprechenden Bedingungsgruppe kann viel Klarheit schaffen und tut niemandem weh. Ganz alternativ könnte man ja etwa bei dem Rollo-Beleuchtungs-Beispiel auch auf wochenends 6 Uhr triggern und den Rollozustand abfragen und erst im Ausführungsteil mit einem IF auf die Beleuchtungsstärke zwischen Rollobewegung und Treppenhausbeleuchtung entscheiden.

Etwas Offtopic:
Weiterhin: Eine ElseIf-Gruppe in anderen Sprachen hinterlässt nach ihrer Abarbeitung keine Spuren. DOIF ist ja zusätzlich noch ein Zustandsspeicher, und der Zustand des DOIF vor der erneuten Triggerung ist ohne "do always" auch eine versteckte Ausführungsbedingung. Das und der Umstand, dass die in den Zweigen formulierten Bedingungen aus völlig unterschiedlichen Kategorien stammen können, erlaubt einerseits interessante Zusammenfassungen von Automatisierungsvorgängen unter einem Dach, erlaubt aber immer noch nicht beliebige Konstruktionen als Zustandsspeicher (was kein Fehler von DOIF ist).

Zudem kann man ein DOIF aufteilen, wenn es Konflikte gibt (siehe auch defensives Programmieren).

Genau. Ich habe mit meinem Garagentor versucht, dessen Zustände closed, opening, opened, closing und stopped (als Zwischenhalt unterwegs) durch die Abfrage von zwei Motorrelais und zwei Endlagenschaltern in ein DOIF zu pressen. Hierbei alle Eventualitäten zu berücksichtigen, etwa dass die Relais nicht gleich schnell schalten und der Motor erst nach dem Erreichen des Endlagenschalters stoppt, war auch mit gezielten waits nicht so trivial zu erreichen - letztlich wurde je ein DOIF für die Motorbewegung und ein weiteres für den Torzustand (closed, between, opend) und jeweilige sets auf einen Dummy die einfachere Lösung.

Ansonsten liebe ich gerade den Zustandsspeicher des DOIF und seine hervorragenden Formatierungsmöglichkeiten. Dass sich ganz ohne Zusatzdummys in der Weboberfläche ein DOIF hinter einer klarschriftlichen Bezeichnung (per alias) und einer Zustandsbeschreibung (per Attribut  cmdstate und ggf. state) verbergen kann, nutze ich so oft es irgend geht.

[Ralli]

Pfriemler, mein Beispiel-DOIF habe ich hier nur angeführt, um das "Problem" aufzuzeigen. Natürlich habe ich das längst um eine entsprechende Abfrage ergänzt und somit das "Problem" umschifft.

Letztendlich bleibt tatsächlich der letztendliche Unterschied zu einem klassischen elsif einer Programmiersprache. Man muss sich eben klar darüber sein, dass es in einem DOIF bislang scheinbar kein klassisches/echtes (DO)ELSIF gibt.

Damit wir uns recht verstehen: ich bin sehr froh über das Modul und noch mehr über Damians "Ansprechbarkeit"! Was ich aufzeigte, soll auch kein Gemecker sein - ich bin halt drüber gestolpert und wollte das hier kundtun, falls andere, die elsif kennen, hier ebenfalls an sich zweifeln .

[Damian]

Pfriemler, mein Beispiel-DOIF habe ich hier nur angeführt, um das "Problem" aufzuzeigen. Natürlich habe ich das längst um eine entsprechende Abfrage ergänzt und somit das "Problem" umschifft.

Letztendlich bleibt tatsächlich der letztendliche Unterschied zu einem klassischen elsif einer Programmiersprache. Man muss sich eben klar darüber sein, dass es in einem DOIF bislang scheinbar kein klassisches/echtes (DO)ELSIF gibt.

Damit wir uns recht verstehen: ich bin sehr froh über das Modul und noch mehr über Damians "Ansprechbarkeit"! Was ich aufzeigte, soll auch kein Gemecker sein - ich bin halt drüber gestolpert und wollte das hier kundtun, falls andere, die elsif kennen, hier ebenfalls an sich zweifeln .

Ich hatte schon mal geschrieben: Am Anfang der Entwicklungsphase des Moduls hat ein beliebiger Trigger immer zur Abarbeitung aller Zweige der Reihe nach geführt. Das war auch trivial zu programmieren, weil man sich nicht merken musste, welche Devices in welchen Bedingung steckten. Diese Vorgehensweise habe ich allerdings bereits vor der Veröffentlichen direkt verworfen, weil meine definierten DOIF-Module etwas taten, was ich eigentlich nicht wollte - Zweige auszuführen, die mit dem Trigger nichts zu tun hatten. Es zeigte sich nämlich, dass man beim Definieren einer Bedingung mit ihrem Ausführungsteil erst mal an die Sachen denkt, die in dieser Bedingung vorkommen und nicht an die Sachen, die in anderen Bedingung vorkommen. Das Problem zeigt sich immer noch beim DOELSE-Fall, an den viele nicht denken, der immer dann vorkommt, wenn die zu prüfenden Zweige nicht wahr sind - vor allem dann, wenn es mehrere DOELSEIF-Fälle gibt.

Gruß

Damian

[Pfriemler]

...weil meine definierten DOIF-Module etwas taten, was ich eigentlich nicht wollte - Zweige auszuführen, die mit dem Trigger nichts zu tun hatten.

Darauf könnte ich antworten: Dann wäre zu überlegen, ob diese Zweige auch richtigerweise in dieses DOIF gehören. Denn eine Konstruktion wie (nur logisch gesprochen, nicht syntaktisch richtig)
DOIF ([Lichtdraußen] < x)(set Außenlicht on)
DOELSEIF ([LichtDrinnen] < y)(set Innenlicht on)
wird als Sammlung von Bedingungen wie gewünscht funktionieren, wenn die Zweige nur von den entsprechenden Triggern bedient werden: Wird's draußen dunkel, schalte das Licht ein, wird's drinnen dunkel, schalte das Licht ein. Beim Abklappern des gesamten DOIF nach dem Auftreten eines der beiden Trigger würde das Innenlicht aber nie angehen, wenn es zuerst draußen dunkel wird, weil die erste Bedingung wahr ist - und Schluss. Man kann sich aber an dieser Stelle trefflich streiten, ob diese beiden eigentlich voneinander völlig unabhängigen Fälle ins gleiche DOIF gehören. 

Abgesehen davon muss ich diese Aussagen:

Damit wir uns recht verstehen: ich bin sehr froh über das Modul und noch mehr über Damians "Ansprechbarkeit"! Was ich aufzeigte, soll auch kein Gemecker sein - ich bin halt drüber gestolpert und wollte das hier kundtun, falls andere, die elsif kennen, hier ebenfalls an sich zweifeln

mal ganz dick unterschreiben. Wir können uns nur wünschen, dass es so bleibt!

[Damian]

Darauf könnte ich antworten: Dann wäre zu überlegen, ob diese Zweige auch richtigerweise in dieses DOIF gehören. Denn eine Konstruktion wie (nur logisch gesprochen, nicht syntaktisch richtig)
DOIF ([Lichtdraußen] < x)(set Außenlicht on)
DOELSEIF ([LichtDrinnen] < y)(set Innenlicht on)
wird als Sammlung von Bedingungen wie gewünscht funktionieren, wenn die Zweige nur von den entsprechenden Triggern bedient werden: Wird's draußen dunkel, schalte das Licht ein, wird's drinnen dunkel, schalte das Licht ein. Beim Abklappern des gesamten DOIF nach dem Auftreten eines der beiden Trigger würde das Innenlicht aber nie angehen, wenn es zuerst draußen dunkel wird, weil die erste Bedingung wahr ist - und Schluss. Man kann sich aber an dieser Stelle trefflich streiten, ob diese beiden eigentlich voneinander völlig unabhängigen Fälle ins gleiche DOIF gehören. 

DOIF unterscheidet nicht grundsätzlich zwischen Zeit- bzw. Device-Triggerung.

Bei diesem Beispiel gehören beide Bedingungen in ein Modul, weil es sich um das gleiche Rollo handelt. Nun möchte jemand, dass es bei Helligkeit morgens hoch fährt und prinzipiell um 19:00 Uhr runter fährt, ob es noch hell ist oder nicht:

Code Auswählen Erweitern

DOIF ([hell] eq "on") (set rollo hoch)
DOELSEIF ([19:00]) (set rollo runter)


Um 19:00 Uhr würde der Rollladen aber nicht runterfahren, wenn es noch hell ist.

Gruß

Damian

[satprofi]

Hallo. Habe fehlermeldung bei folgendem doif.

Code Auswählen Erweitern

  ([ mytwilight:akt.event] eq "ss") (set Steckdose1 on-till 22:30,define next2 at +00:00:30 set Vorgarten_links1 on-till 22:32,define next3 at +00:01:00 set Vorgarten_Haus on-till 22:20,define next4 at +00:01:30 set Antikleuchte on-till 23:00,define next5 at +00:15:00 set Poolbeleuchtung on-till 22:31,set Dunkelheit on)

Error: define next5 already defined, delete it first.   Warum? Kann kein next5 finden

Sent from my OPO

[Pfriemler]

Ernstlich? Dein DOIF definiert zur Ausführungzeit einmalige 5 at's, die sich nach Ausführung selbst löschen. Taucht die Fehlermeldung zur Ausführungszeit auf (z.B. im Log), dann war das betreffende at noch nicht aktiv und existiert demnach noch. Einmalige at tauchen nicht in der fhem.cfg, sondern nur im statefile auf. "list next.*" sollte Dir alle noch aktiven (wartenden) at's mit dem Namen auf der Kommandoebene zeigen.

[satprofi]

ja, wirklich. Fehlermeldung steht schon wieder an.
Ich denke kommt bei anlegen von next5. komisch das aber fehlerfrei geschalten wird.
vielleicht nur ein bug von DOIF ?

list next5 ergibt kein ergebnis.

gruss

[Ralli]

Es könnte daran liegen, dass ein weiterer auslösender Event vor Ablauf der 15 Minuten das DOIF erneut getriggert hat. Setze mal im DOIF Verbose auf 5.

[duke-f]

Ohne dass ich jetzt alles hier mitverfolgt hätte: Könnte hier das neue "defmod" eine Lösung darstellen?
http://forum.fhem.de/index.php/topic,36326.0.html