neues Attribut: startup, neuer set-Befehl: checkall, neuer get-Befehl: html

[Damian]

Zu Weihnachten gibt es mal wieder neue Features.

Attribut startup:

Möchte man beim Hochfahren des Systems eine bestimme Aktion ausführen, so lässt sich das mit dem Attribut startup bewerkstelligen, die Syntax entspricht der eines Ausführungsteil beim DOIF (runde Klammern werden nicht angegeben)

Syntax:

Code Auswählen Erweitern

attr <DOIF-Modul> startup <FHEM-Befehl oder Perl-Befehl in geschweiften Klammern mit DOIF-Syntax>

Beispiel:

Beim Hochfahren des System soll immer der Ausführungsteil cmd_1 bedingunglos ausgeführt werden.

Code Auswählen Erweitern

attr di_test startup set $SELF cmd_1 

Überprüfen aller Bedingungen mit Ausführung, um nach dem Hochfahren des Systems einen definierten Zustand zu erreichen.

Code Auswählen Erweitern

attr di_test startup set $SELF checkall

set-Befehl checkall

mit dem set Befehl werden wie beim gleichnamigen Attribut alle DOIF-Bedingung überprüft, sobald eine Bedingung als wahr geprüft ist, wird das dazugehörige Kommando ausgeführt. Einsatzgebiet: Überprüfung der Bedingungen nach einer Definition oder Nutzung in Kombination mit dem neuen Attribut startup. Zu beachten ist, dass nur Zustandsabfragen sowie Zeitintervalle und keine Ereignisabfragen bzw. keine Zeitpunkte sinnvoll überprüft werden können, da sie zum Zeitpunkt der Abfrage nicht wahr sind.

get Befehl html

mit dem get Befehl wird die komplette HTML-Definition einer uiTable zurückgeliefert.

Symtax

Code Auswählen Erweitern

get <DOIF-Modul mit uiTable definition> html

Beispiel:

Code Auswählen Erweitern

define wl weblink htmlCode {fhem("get Heizung html",1)}

Damit wird das Layout von uiTable des DOIF-Moduls "Heizung" als weblink dargestellt. Hierbei ist die komplette Funktionalität gegeben, Widgets werden automatisch aktualisiert und lassen sich bedienen.

Edit: letzte Version wurde eingecheckt

[the ratman]

Damit wird das Layout von uiTable des DOIF-Moduls "Heizung" als weblink dargestellt

somit sollte also auch alles im floorplan gehen. wenn ja, jetzt schon thx dafür!

[Damian]

somit sollte also auch alles im floorplan gehen. wenn ja, jetzt schon thx dafür!

Über einen weblink sollte es funktionieren.

[Brockmann]

Attribut startup:

Möchte man beim Hochfahren des Systems eine bestimme Aktion ausführen, so lässt sich das mit dem Attribut startup bewerkstelligen, die Syntax entspricht der eines Ausführungsteil beim DOIF (runde Klammern werden nicht angegeben)

Landen diese Befehle automatisch am Ende der Queue, so dass immer erst die fhem.cfg komplett abgearbeitet wird, bevor dieser Befehle ausgeführt werden?

[Damian]

Landen diese Befehle automatisch am Ende der Queue, so dass immer erst die fhem.cfg komplett abgearbeitet wird, bevor dieser Befehle ausgeführt werden?

Was denkst du denn, ich würde hier halbe Sachen machen

Inzwischen werden zeitkritische Dinge wie Timer setzen, Events auswerten usw. erst dann vorgenommen, wenn das ganze System hochgefahren ist.

[Brockmann]

Was denkst du denn, ich würde hier halbe Sachen machen

Ich entschuldige mich in aller Form für diese Respektlosigkeit!   

Aber trotzdem möchte ich anregen, den startup-Befehl mit einer wait-artigen Verzögerung versehen zu können. Das könnte hilfreich sein, wenn die Aktion sich auf externe Systeme beziehen soll, die etwa nach einem Stromausfall nicht so schnell wieder online sind wie fhem.
Und man könnte den Mechanismus dann auch nutzen in dem Sinne: Wenn x Minuten nach Systemstart noch kein Event y eingetreten ist, dann führe Aktion z aus. Also quasi ein Watchdog, der beim Systemstart automatisch scharf geschaltet wird. (Wobei sich das vermutlich auch jetzt schon mit einem Watchdog-Device bewerkstelligen ließe...)

Edit: Vermutlich ist das auch jetzt alles schon mit Bordmitteln umsetzbar, also entschuldige ich mich diesmal vorsichtshalber schon im voraus... 

[Damian]

Ich entschuldige mich in aller Form für diese Respektlosigkeit!   

Aber trotzdem möchte ich anregen, den startup-Befehl mit einer wait-artigen Verzögerung versehen zu können. Das könnte hilfreich sein, wenn die Aktion sich auf externe Systeme beziehen soll, die etwa nach einem Stromausfall nicht so schnell wieder online sind wie fhem.
Und man könnte den Mechanismus dann auch nutzen in dem Sinne: Wenn x Minuten nach Systemstart noch kein Event y eingetreten ist, dann führe Aktion z aus. Also quasi ein Watchdog, der beim Systemstart automatisch scharf geschaltet wird. (Wobei sich das vermutlich auch jetzt schon mit einem Watchdog-Device bewerkstelligen ließe...)

Edit: Vermutlich ist das auch jetzt alles schon mit Bordmitteln umsetzbar, also entschuldige ich mich diesmal vorsichtshalber schon im voraus... 

Eine zusätzliche Verzögerung mittels wait habe ich bisher nicht vorgesehen. Aber man kann jetzt schon beliebige FHEM-, Perlkommandos aneinanderreihen, damit kann man ein sleep oder eine at-Definition davorhängen, z. B.

Code Auswählen Erweitern

attr di_test startup sleep 60;set blabla...

In erster Linie wollte ich aber eine Möglichkeit haben nach einem längeren Stillstand und einem erneuten Hochfahren des Systems, meine DOIFs möglichst schnell wieder auf den aktuellen Stand bringen, und nicht auf Events/Timer warten, die den Zustand wieder geradebiegen, denn das kann je nach Definition und Event-Häufigkeit schon mal länger dauern. Daher auch der neue set-Befehl checkall. Nebenbei kann es den Usern die Überprüfung eigener DOIF-Definition erleichtern, in dem man set ... checkall aufruft und schaut, was das DOIF-Modul so macht oder nicht macht. Das funktioniert natürlich besonders gut, wenn man in den DOIF-Bedingungen Zustände von Readings mit eq abfragt.

[Damian]

Hier noch zwei interessante Details zu Nutzung der neuen Features:

1) Beim Attribut startup in Verbindung mit set checkall wird natürlich DOIF-konform ohne do always keine Wiederholung des selben Befehls vorgenommen, wenn sich der Zustand nicht ändert - das wird vermutlich oft auch beim startup-Attribut so gewollt sein. Möchte man dennoch auch ohne do always  per set checkall eine Ausführung unbedingt am Anfang provozieren, so definiert man einfach das bisherige Attribut initialize. Damit wird der letzte Zustand des Moduls zurückgesetzt und somit ein Zustandswechsel provoziert - der Ausführung eines Befehlszweiges steht nichts mehr im Wege (für die richtige Reihenfolge der Abarbeitung der beiden Attribute habe ich schon gesorgt )

2) Möchte man nicht alle DOIF-Bedingungen per set checkall abprüfen, sondern nur bestimmte, dann kann man einfach im startup-Attribut Trigger auf die Devices ausführen, welche in den betroffenen DOIF-Bedingungen vorkommen.

z. B.

Code Auswählen Erweitern

attr di_test startup trigger Lampe

Edit: Das Setzen von Selftrigger ist hier nicht erforderlich, das eigene Modul wird dennoch getriggert, da durch das startup-Attribut keine Rekursionen entstehen können.

[Damian]

Version v0.3 im ersten Post.

Jetzt wird das Reading mode immer gesetzt. Die Zustände sind: enabled, disabled, deactivated

Damit ist der Zustand eines DOIF-Moduls zu jedem Zeitpunkt eindeutig definiert.

[crispyduck]

Spitze!

Hab das bis jetzt mit einem extra DOELSEIF welches als Bedingung global INITIALIZED hatte gemacht.

Könnte man beim Startup eventuell noch ein wait mit angeben?

Habe z.B. meine Garagentorsteuerung komplett in einem DOIF gemacht, und der Sensor welcher anzeigt ob das Tor offen oder geschlossen ist, ist ein RPI_GPIO Eingang, welcher erst ca. 6 Sekunden nach Start den richtigen Wert liefert.

Mache das jetzt über das Attribut initializ, z.B. Warte auf Sensor,
DOELSEIF ([global:"INITIALIZED"])(set $SELF initialize)
mit wait 6
Und in den zwei DOELSIF Zweigen die open oder closed setzen ist noch [$SELF:state] mit in der Bedingung.

startup + checkall wäre dafür ideal, nur bräuchte ich hier noch ein wait.

Danke,
crispyduck

[Ellert]

Spitze!

Hab das bis jetzt mit einem extra DOELSEIF welches als Bedingung global INITIALIZED hatte gemacht.

Könnte man beim Startup eventuell noch ein wait mit angeben?

Habe z.B. meine Garagentorsteuerung komplett in einem DOIF gemacht, und der Sensor welcher anzeigt ob das Tor offen oder geschlossen ist, ist ein RPI_GPIO Eingang, welcher erst ca. 6 Sekunden nach Start den richtigen Wert liefert.

Mache das jetzt über das Attribut initializ, z.B. Warte auf Sensor,
DOELSEIF ([global:"INITIALIZED"])(set $SELF initialize)
mit wait 6
Und in den zwei DOELSIF Zweigen die open oder closed setzen ist noch [$SELF:state] mit in der Bedingung.

startup + checkall wäre dafür ideal, nur bräuchte ich hier noch ein wait.

Danke,
crispyduck

siehe Antwort 6

[crispyduck]

Ups, habe wohl doch nicht alles gelesen. 

Baue das bei mir gleich mal auf:

Code Auswählen Erweitern

attr Garagentor startup sleep 6; set $SELF checkall
um. 

Danke
crispyduck

[Damian]

Version v0.4 mit aktueller Doku.

[bmwfan]

Die Funktion startup finde ich super. Hier mal ein großes Kompliment an Damian. Ich versuche inzwischen alles mit DOIF zu realisieren, da ich das viel eleganter finde als notify oder at.

Bisher hatte ich teilweise Problem wegen fehlendem Vorbelegen von Werten. Ich habe die 98_DOIF.pm auf den Raspi kopiert und alles hat super funktioniert. Heute ein Update gemacht, und das attr. startup wird nicht erkannt. Alle DOIF, die ich mit dem attr versehen habe, werden mit einem unbekannten Attribut gekennzeichnet.

2 Fragen hierzu:
1: Bis wann wird das attr über die Update-Funktion verteilt?
2: Muss ich alle DOIF wieder ändern oder funktionieren sie trotzdem, so dass ich in Ruhe darauf warten kann, bis startup eingebaut ist

Gruß Jürgen

[Ellert]

Für Versionen, die noch nicht per Update verteilt werden, gibt es das globale Attribut exclude_from_update.

Mit "attr global 98_DOIF.pm" schliesst Du es vom Update aus, wenn es per Update verteilt wird, löschst Du das Attribut wieder.

Die startup Attribute wurden wahrscheinlich gelöscht, wenn kein save aussgeführt wurde, dann die Version von hier kopieren und rereafcfg durchführen, dann ist alles wie zuvor.

Sonst restore ausführen und dabei die .save Datei einschliessen.

[Damian]

Letzte Version wurde eingecheckt.

[chq]

Was bewirkt das Attribut checkall, wenn es nicht wie weiter vorne im Thread zu lesen mit startup kombiniert wird?

Ist davon auszugehen, dass wenn das Attribut checkall nicht gesetzt ist checkall all (wie in der deutschen Commandref zu lesen) voreingestellt ist?

Gruß Chris

[Damian]

Was bewirkt das Attribut checkall, wenn es nicht wie weiter vorne im Thread zu lesen mit startup kombiniert wird?

Ist davon auszugehen, dass wenn das Attribut checkall nicht gesetzt ist checkall all (wie in der deutschen Commandref zu lesen) voreingestellt ist?

Gruß Chris

checkall-Attribut verändert das Verhalten des DOIFs wie folgt: https://forum.fhem.de/index.php/topic,63375.msg547361.html#msg547361

[chq]

Syntax:

Code Auswählen Erweitern

attr <DOIF-Modul> startup <FHEM-Befehl oder Perl-Befehl in geschweiften Klammern mit DOIF-Syntax>

Entspricht das der Syntax:

Code Auswählen Erweitern

{set_Reading("doifState","idle")}

Gruß Chris

[chq]

Entspricht das der Syntax:

Code Auswählen Erweitern

{set_Reading("doifState","idle")}

Gruß Chris

Bitte um Antwort.. 

Gruß Chris

Edit: "Gelesen 2667 mal" am 5.10.2018 um 20:37 Uhr- Wahnsinn! Das kommt durch die vielen Fleißigen, die stets die Forensuche bemühen, bevor sie sich trauen etwas zu fragen.

[Damian]

Startup-Attribut gibt es nur im FHEM-Modus, set_Reading aber nur im Perlmodus. Im Perlmodus wird der Block  init beim Start ausgeführt, dort kann man set_Reading nutzen.

Wie immer in der Commandref genau nachzulesen: https://fhem.de/commandref_DE.html#DOIF_Perl_Modus

P.S. 2600 Aufrufe nach fast einem Jahr sind nichts besonders (vielleicht war der Beitrag anfangs angepinnt ).

Dieser Thread https://forum.fhem.de/index.php/topic,23833.0.html hatte ein paar mehr, bevor ich es schließen musste, weil das System träge wurde

[Invers]

Hi, ich habe das TV-DOIF in meinen Flurplan eingebunden

Code Auswählen Erweitern

define wl weblink htmlCode {fhem("get doif_TEST html",1)}
Ich würde aber noch einen vertikalen Scrolbalken benötigen, da die Tabelle zu lang für meinen FP ist. Ist so etwas möglich und wenn ja, wie geht das?

[Ellert]

Ich denke das ist eher eine Frage für den Floorplanbereich.

[Invers]

Da hast du sicher Recht, aber ich habe beschlossen, dass ich es einfach so lasse. Danke dir.