Konzepterweiterung: Mehrere DOIF in einem

[Damian]

Ich grüble gerade an einer Erweiterung der DOIF-Syntax. Oft erfordern Problemlösungen mehrere DOIFs. Mit dem Perl-Modus tun sich noch viele schwer. Meine Idee ist DOIF in DOIF zu erlauben, Die Syntax wäre dann:

DOIF (<Bedingung1>)(<Ausführung1>)
DOELSEIF(<Bedingung2>)(<Ausführung2>)
...
DOELSE (<Ausführung>)
DOIF (<Bedingung1>)(<Ausführung1>)
DOELSEIF(<Bedingung2>)(<Ausführung2>)
...
DOELSE (<Ausführung>)
DOIF ...

Die weiteren DOIF-Blöcke müssten einen eigenen Status bekommen: state_2, state_3, usw.

Weiterhin müssten einige Attribute ebenfalls für jeden DOIF-Block eine Erweiterung erfahren, z. B. das Attribut do:

do always  # once # resetwait # always ...

oder auch wait:

wait 3:2 # 1:3,1,3 #...

# wäre der Trenner für jeden DOIF-Block

Wie seht ihr das? Wäre diese Erweiterung sinnvoll, um Probleme in einem DOIF zu lösen oder reicht es, wie bisher, wenn man seine Problemlösung auf mehrere DOIFs aufteilt.

[Gisbert]

Hallo Damian,

dein Ansatz ist löblich, und ich hatte mir gewünscht, dass ich inhaltlich zusammenhängende DOIF in einem abhandeln könnte. Mittlerweile bin ich der Meinung, dass die Übersichtlichkeit steigt, wenn man Dinge vereinzelt.

Es passiert leider sehr schnell, dass Zweige eines DOIF "gegeneinander" arbeiten, z.B. ein Relais schaltet eine ganze Weile hin und her, bevor es sich für einen Zweig dauerhafter entscheidet. Es gibt natürlich immer einen Grund, den man beheben kann.

Je komplexer die Sache wird, umso schwerer sind vermutlich unbeabsichtiges Verhalten zu fixen.

Viele​ Grüße​ Gisbert​

[Ellert]

Es ist sicherlich reizvoll sowas zu implementieren. Würde das nicht auch die Attribute vervielfachen oder den Inhalt unübersichtlich machen. Wenn ich an wait oder cmdState denke mit Befehlszweigen, Sequenzen, Unterzweigen und Untersequenzen in beliebiger Verschachtelungstiefen, dann wird mir schwindelig.

Ich würde mir eher einen Debugmode wünschen, in dem auch die Werte nicht triggernde Operatoren im Listing erscheinen.

[the ratman]

also meiner geringen nicht-perl-doif-meinung nach, ists nicht wirklich nötig. hab da auch sorgen wegen der übersichtlichkeit. ich gruppier mir einfach zusammengehörige doifs in gemeinsame gruppen und schon sieht man, was zusammen gehört.


darf ich gleich mal träumen, wenn wir bei der übersichtlichkeit sind?
die übersichtlichkeit ist ja jetzt schon oft ein problem, wenn ich z.b. an 20 waits mit repeatsame usw. denke. nach monaten in dem doif was ändern? dann kannst anfangen deine zweige und attr durchzuzählen und hoffen, dass du auch überall gleich falsch gezählt hast *g*.
sprich: ich würde, wäre ich ein programmierer, dass mal irgendwie übersichtlicher hinkriegen wollen. und wenn ich das könnte, würde ich die DEF in einzelne doelseif-fenster aufteilen und die dazugehörigen waits,repeat..., usw. neben den einzelnen zweigen darstellen.
dann wäre eventuell deine idee mit mehrerern doifs in einem auch ausführbarer - man macht halt dann noch nen fetten rahmen um alles was zu 1 doif gehört.

btw. wems so geht wie mir und noch keine idee dazu hat: ich hab mir damit beholfen, alle wesentlichen attribute als globalen widgetoverride mit mehrzeiligen texten anzulegen - z.b. wait:textFieldNL-long
so hab ich dann dort die zeilennummerierung zur hilfe. selbe nummern trag ich nämlich im def bei jedem zweig auch ein.

[Damian]

Es ist sicherlich reizvoll sowas zu implementieren. Würde das nicht auch die Attribute vervielfachen oder den Inhalt unübersichtlich machen. Wenn ich an wait oder cmdState denke mit Befehlszweigen, Sequenzen, Unterzweigen und Untersequenzen in beliebiger Verschachtelungstiefen, dann wird mir schwindelig.

Ich würde mir eher einen Debugmode wünschen, in dem auch die Werte nicht triggernde Operatoren im Listing erscheinen.

Eigentlich müsste man mit den bisherigen Attributen auskommen. Ein weiteres Trennzeichen für die einzelnen Blöcke würde, wie vorgeschlagen, ausreichen, die Blöcke sind separat zu sehen und können nicht ineinander greifen. Allerdings würde es sicherlich die Attribute-Syntax nicht vereinfachen. Der Anpassungsaufwand im Modul wäre auch nicht unerheblich, die bisherige Syntax muss weiterhin voll erhalten bleiben. Vermutlich würde sich auch die Analyse bei Problemen schwieriger gestalten, da ein Trigger mehrere Zweige ausführen kann, wie im Perl-Modus. Ich denke ein häufiger Anwendungsfall, wäre eine flache Hierarchie der Art:

DOIF (...) (....)
DOIF (...) (....)
...

Allerdings all das und noch viel mehr kann man jetzt schon im Perl-Modus definieren.

Zum Debug-Modus :

Die angegebenen nicht triggernden Readings werden im Modul z. Zt. gar nicht beachtet, das Modul hat zur Laufzeit keine Ahnung, dass es sie gibt. Sie werden zum Zeitpunkt der Definition vom DOIF-Parser in Perlfunktionen übersetzt. Bei einem Trigger wird per eval die Bedingung als Perl-Definition lediglich auf wahr oder nicht wahr überprüft, der Rest ist Perl-Sache.

Es wäre also ein erheblicher Aufwand nicht triggernde Readings zwecks Protokollierung im DOIF-Modul zu verwalten.

[Damian]

also meiner geringen nicht-perl-doif-meinung nach, ists nicht wirklich nötig. hab da auch sorgen wegen der übersichtlichkeit. ich gruppier mir einfach zusammengehörige doifs in gemeinsame gruppen und schon sieht man, was zusammen gehört.


darf ich gleich mal träumen, wenn wir bei der übersichtlichkeit sind?
die übersichtlichkeit ist ja jetzt schon oft ein problem, wenn ich z.b. an 20 waits mit repeatsame usw. denke. nach monaten in dem doif was ändern? dann kannst anfangen deine zweige und attr durchzuzählen und hoffen, dass du auch überall gleich falsch gezählt hast *g*.
sprich: ich würde, wäre ich ein programmierer, dass mal irgendwie übersichtlicher hinkriegen wollen. und wenn ich das könnte, würde ich die DEF in einzelne doelseif-fenster aufteilen und die dazugehörigen waits,repeat..., usw. neben den einzelnen zweigen darstellen.
dann wäre eventuell deine idee mit mehrerern doifs in einem auch ausführbarer - man macht halt dann noch nen fetten rahmen um alles was zu 1 doif gehört.

btw. wems so geht wie mir und noch keine idee dazu hat: ich hab mir damit beholfen, alle wesentlichen attribute als globalen widgetoverride mit mehrzeiligen texten anzulegen - z.b. wait:textFieldNL-long
so hab ich dann dort die zeilennummerierung zur hilfe. selbe nummern trag ich nämlich im def bei jedem zweig auch ein.

Bei der Programmierung des Moduls habe ich mich hauptsächlich um die internen Abläufe gekümmert und weniger um die Benutzeroberfläche, die dem FHEM-Standard entspricht. Man könnte natürlich einen eigenen DEF-Bereich programmieren, wie es andere Module tun. Das würde sicherlich den Anfängern helfen, ihre Definition vorzunehmen. Andererseits kann man DOIF mit den vielfältigen Definitionsmöglichkeiten als eine Programmiersprache ansehen. Als Programmierer, weiß man, dass für eine Programmiersprache ein komfortabler Editor nicht zu ersetzen ist. Der Codemirror hilft da eigentlich schon ganz gut.  Es war für mich einfacher, die ganze wait-Geschichte über Attribute zu realisieren, als neue Kommandos a la sleep zu definieren, die man mühevoll parsen muss.

Bisher hat sich keiner getraut eine Oberfläche für DOIF zu programmieren. Ellert hat immerhin bei DOIFTools etwas abweichend vom Standard an der Oberfläche gedreht.


PS: wait und einige andere Attribute haben inzwischen per default textFieldNL-long

[OliS.]

Welche Vorteile, bis auf die Möglichkeit, mehrere DOIF zusammenzufassen, hätte das Ganze? Ließe sich damit beispielsweise das hier beschriebene Problem lösen?

https://forum.fhem.de/index.php/topic,85098.0.html

LG
Oli

[Damian]

Welche Vorteile, bis auf die Möglichkeit, mehrere DOIF zusammenzufassen, hätte das Ganze? Ließe sich damit beispielsweise das hier beschriebene Problem lösen?

https://forum.fhem.de/index.php/topic,85098.0.html

LG
Oli

Die einzige Idee war mehrere unabhängige DOIF-Definitionen zusammenzufassen. Man könnte damit nicht mehr, sondern eher weniger realisieren, als mit getrennten DOIFs, denn der Status der anderen DOIF-Zweige wäre dann unter status_1 usw. versteckt, um nicht mit dem ersten DOIF-Zweig zu kollidieren.

Ich habe die Pläne schon verworfen, denn es würde für mehr Verwirrung sorgen als nutzen. Ich denke, die Leute haben sich inzwischen an die Syntax DOIF-DOELSIF-... gewöhnt.

Unabhängige Zweige kann man abgesehen davon sehr schön im Perl-Modus realisieren.

[Per]

Ein weiteres Trennzeichen für die einzelnen Blöcke würde, wie vorgeschlagen...

Ich würde eine einheitliche Syntax schon befürworten, auch wenn es dann für einige Attribute dann zwei Schreibweisen wg. der Abwärtskompatibilität geben müsste. Klammern gefallen mir wg. der Ähnlichkeit mit berechneten Werten weniger.
Ansonsten stimme ich den anderen Vorschlägen und Meinungen voll zu (und das passiert wirklich nicht oft! ).

[drhirn]

Wie seht ihr das? Wäre diese Erweiterung sinnvoll, um Probleme in einem DOIF zu lösen oder reicht es, wie bisher, wenn man seine Problemlösung auf mehrere DOIFs aufteilt

Ich bin etwas spät dran, aber ich wäre schwer dafür. Hätte ich schon oft brauchen können. Und - im Gegensatz zu meinen Vorpostern - fände ich es übersichtlicher, wenn alles in einem DOIF abgehandelt würde, als dauernd vier Browserfenster mit je einem DOIF offenzuhaben, weil die alle irgendwie zusammenspielen. Und der Perl-Modus ist für mich noch unerschlossenes Terrain.

[Per]

Vllt. wäre es eine Möglichkeit, diese 4 (dauernd? ) DOIF hier zur Diskussion zu stellen und zu optimieren? Erst letztens hatte Damian dazu eine gute Lösung!

[Ellert]

Wenn man zusammenhängende DOIF in einem Fenster editieren möchte, kann man das über Raw definition machen, in dem man Dump "Probably associated with" too markiert.

Vorher muss man die assoziierten DOIF durch Leerzeichen getrennt als Kommentar angeben.

Ausprobieren kann man das mit DOIFtools, wenn in der Detailansicht Raw definition geöffnet wird, kann man alle DOIF-Instanzen in einem Fenster editieren