neue Features: defaultvalue, readingList, Ereignisfilter, Attribut checkall

[Damian]

Liebe DOIF-Nutzer,

ich bin gerade dabei die Generalisierung des Moduls weiter zu entwickeln.

Bisher konnte man eine Ereignisabfrage nur auf wahr oder nicht wahr abfragen.

Wollte man z. B. die Temperatur aller Temperatursensoren abfragen, so musste man einen Ereignistrigger mit Readingauswertung definieren, z. B.

Code Auswählen Erweitern

([":^temperature"] and [$DEVICE:temperature] < 0) (set pushmsg Frostgefahr!)

Nun habe ich die Syntax für allgemeine Ereignistrigger erweitert, sie lautet:

["Regex für Trigger":"<Regex-Filter>":<Output>,<Default>]

Regex-Filter- und Ouput-Parameter sind optional. Der Default-Wert ist verpflichtend.

Das Beispiel von oben wird dann einfach definiert:

Code Auswählen Erweitern

([":^temperature",0] < 0) (set pushmsg Frostgefahr)

Damit wird auf alle Devices getriggert, die mit "temperature" im Event beginnen. Zurückgeliefert wird der Wert, der im Event hinter "temperature: " steht. Wenn kein Event stattfindet, wird der Defaultwert zurückgeliefert. Das ist insb. bei kombinierten logischen Abfragen wichtig, wenn noch andere Trigger in der Bedingung vorkommen.

Die Angaben zum Filter und Output funktionieren, wie die beim Reading-Filter. Siehe:
http://fhem.de/commandref_DE.html#DOIF_Filtern_nach_Zahlen

Wenn kein Filter, wie oben, angegeben wird, so wird intern folgende Regex vorbelegt: "[^\*: (.*)"  Damit wird der Wert hinter der Readingangabe genommen. Durch eigene Regex-Filter-Angaben kann man beliebige Dinge des Events zurückgeben und in der Bedingung entsprechend auswerten, ohne auf Readings zurückgreifen zu müssen.

Wenn meine Tests abgeschlossen sind, werde ich diese Version zum Testen hier hochladen.

Anregungen zur neuen Syntax sind willkommen.

Edit: Die Version ist selbstverständlich abwärtskompatibel zur bisherigen. Ohne Default-Wert-Angabe verhält sich ein Ereignistrigger wie bisher: er liefert wahr beim Trigger bzw. unwahr sonst.

Gruß

Damian

Edit: aktuelle Version eingecheckt

[Damian]

Version 0.1 im ersten Post angehängt.

[Damian]

Version 0.2

Neues Attribut: checkall

Wenn das Attribut checkall auf 1 gesetzt wird, so werden alle DOIF/DOELSEIF-Zweige abgeprüft unabhängig davon, ob das triggernde Device in der Bedingung vorkommt oder nicht.

Bemerkung: Es kann wie bisher immer nur ein Zweig ausgeführt werden.

[Ellert]

Hallo Damian,

ausgehend von dieser Frage https://forum.fhem.de/index.php/topic,44941.msg367322.html#msg367322 ,
wäre es möglich und sinnvoll dem DOIF die zwei Attribute "readingList" und "setList" hinzuzufügen, wie beim Dummy?

Damit wäre es möglich die Kombination von Dummy im Frontend als Eingabe zum Schalten eines DOIF, durch ein DOIF zu ersetzen.

Also, damit so etwas möglich wird

Code Auswählen Erweitern

define Schalter DOIF (["$SELF:mybutton: on"]) (set ...)
DOELSEIF (["$SELF:mybutton: off]) (set ...)

attr Schalter readingList mybutton
attr Schalter setList Schalter mybutton:on,off
attr Schalter webCmd mybutton

Bei einem Dummy sieht das so aus

Code Auswählen Erweitern

define Schalter Dummy
attr Schalter readingList mybutton
attr Schalter setList Schalter mybutton:on,off
attr Schalter webCmd mybutton

[Damian]

Hallo Damian,

ausgehend von dieser Frage https://forum.fhem.de/index.php/topic,44941.msg367322.html#msg367322 ,
wäre es möglich und sinnvoll dem DOIF die zwei Attribute "readingList" und "setList" hinzuzufügen, wie beim Dummy?

Damit wäre es möglich die Kombination von Dummy im Frontend als Eingabe zum Schalten eines DOIF, durch ein DOIF zu ersetzen.

Also, damit so etwas möglich wird

Code Auswählen Erweitern

define Schalter DOIF (["$SELF:mybutton: on"]) (set ...)
DOELSEIF (["$SELF:mybutton: off]) (set ...)

attr Schalter readingList mybutton
attr Schalter setList Schalter mybutton:on,off
attr Schalter webCmd mybutton

Bei einem Dummy sieht das so aus

Code Auswählen Erweitern

define Schalter Dummy
attr Schalter readingList mybutton
attr Schalter setList Schalter mybutton:on,off
attr Schalter webCmd mybutton

Das Einbauen der beiden Attribute dürfte nicht das Problem sein. Das Problem dürfte allerdings die Tatsache sein, dass ich durch modify des DOIFs zunächst alle Readings lösche, ich weiß nicht was dann mit mybutton passieren würde. Es gab schon mal Anfragen selbstdefinierte Readings im DOIF nicht zu löschen - da müsste ich mir noch genauer Gedanken machen, diesen Wunsch ohne Nebenwirkungen umzusetzen. Das wäre vermutlich Voraussetzung für readingList.

[Ellert]

Code Auswählen Erweitern

Das Problem dürfte allerdings die Tatsache sein, dass ich durch modify des DOIFs zunächst alle Readings lösche, ich weiß nicht was dann mit mybutton passieren würde.
Man könnte in diesem Fall das DOIF über "RAW definition" ändern, dann bleiben die Readings erhalten.

Bei einem "Modify" wäre "mybutton" gelöscht, die nächste Auswahl eines Wertes erzeugt das Reading wieder.
Es wird eigentlich nur der Status im Frontend nicht angezeigt.

Ich denke der Funktionsgewinn ist nicht zu unterschätzen.

[Damian]

Code Auswählen Erweitern

Das Problem dürfte allerdings die Tatsache sein, dass ich durch modify des DOIFs zunächst alle Readings lösche, ich weiß nicht was dann mit mybutton passieren würde.
Man könnte in diesem Fall das DOIF über "RAW definition" ändern, dann bleiben die Readings erhalten.

Bei einem "Modify" wäre "mybutton" gelöscht, die nächste Auswahl eines Wertes erzeugt das Reading wieder.
Es wird eigentlich nur der Status im Frontend nicht angezeigt.

Ich denke der Funktionsgewinn ist nicht zu unterschätzen.

Ja. Ich werde es auf die todo-Liste setzen und gleichzeitig nur noch von DOIF erstellte Readings beim Modify löschen. Damit könnten User komplexere Dinge innerhalb eines DOIF programmieren ohne Sachen in irgendwelchen Dummys auszulagern.

[Ellert]

Ich habe mal den entsprechenden Code aus dem Dummy in das DOIF kopiert und angepasst, nicht schön, aber zum Probieren reicht es.
Vielleicht gibts ja einen kleinen Positionsgewinn in der ToDo-Liste 

Basis: $Id: 98_DOIF.pm Ver. 0.2 damian-s $

Zeile 24: use SetExtensions;
Zeile 74 ergänzt mit: setList readingList useSetExtensions
Zeile 1923 -1944 Code aus Dummy angepasst

Hiermit habe ich probiert (zum Import mit Raw definiton):

Code Auswählen Erweitern


define Test DOIF (["$SELF:mybutton: ein"]) DOELSEIF (["$SELF:mybutton: aus"])
attr Test cmdState ein|aus
attr Test readingList state mybutton
attr Test room 0_Test
attr Test setList state:disable,enable,initialize mybutton:ein,aus
attr Test webCmd state:mybutton


[Damian]

Ich habe mal den entsprechenden Code aus dem Dummy in das DOIF kopiert und angepasst, nicht schön, aber zum Probieren reicht es.
Vielleicht gibts ja einen kleinen Positionsgewinn in der ToDo-Liste 

Basis: $Id: 98_DOIF.pm Ver. 0.2 damian-s $

Zeile 24: use SetExtensions;
Zeile 74 ergänzt mit: setList readingList useSetExtensions
Zeile 1923 -1944 Code aus Dummy angepasst

Hiermit habe ich probiert (zum Import mit Raw definiton):

Code Auswählen Erweitern


define Test DOIF (["$SELF:mybutton: ein"]) DOELSEIF (["$SELF:mybutton: aus"])
attr Test cmdState ein|aus
attr Test readingList state mybutton
attr Test room 0_Test
attr Test setList state:disable,enable,initialize mybutton:ein,aus
attr Test webCmd state:mybutton


Funktioniert schon ganz gut. Allerdings muss man natürlich ohne die neuen Attribute die bisherige set-Auswahl (disable, enable, initialize) auswählen können.

[Ellert]

Ich habe den ergänzten Code bereinigt, jetzt bleiben die Set-Vorgaben erhalten.

Auf erlaubte Readings wird im Allgemeinen ja nicht geprüft, z.B. bei userReadings.

Basis: $Id: 98_DOIF.pm Ver. 0.2 damian-s $

Zeile 73 ergänzt mit: setList readingList
Zeile 1922 -1937 Code aus Dummy angepasst und bereinigt

Hier nochmal mein Testgerät

Code Auswählen Erweitern


define Test DOIF (["$SELF:mybutton: ein"]) DOELSEIF (["$SELF:mybutton: aus"])
attr Test cmdState ein|aus
attr Test readingList mybutton
attr Test room 0_Test
attr Test setList mybutton:ein,aus
attr Test webCmd mybutton


[Damian]

Ich habe den ergänzten Code bereinigt, jetzt bleiben die Set-Vorgaben erhalten.

Auf erlaubte Readings wird im Allgemeinen ja nicht geprüft, z.B. bei userReadings.

Basis: $Id: 98_DOIF.pm Ver. 0.2 damian-s $

Zeile 73 ergänzt mit: setList readingList
Zeile 1922 -1937 Code aus Dummy angepasst und bereinigt

Hier nochmal mein Testgerät

Code Auswählen Erweitern


define Test DOIF (["$SELF:mybutton: ein"]) DOELSEIF (["$SELF:mybutton: aus"])
attr Test cmdState ein|aus
attr Test readingList mybutton
attr Test room 0_Test
attr Test setList mybutton:ein,aus
attr Test webCmd mybutton


Sieht schon ganz gut aus. Wenn du Zeit hast, kannst du auch schon die passende Doku in der 0.2-Version vornehmen. Ich kann dann ausgehend von dieser Version noch die ausstehenden Features vornehmen. U. A. neue Syntax bei Stati und Readingangaben: [mydevice:myreading,<default Value>] das entspricht der neuen Syntax bei Events und gibt dem User die Möglichkeit mit Default-Werten flexibler umzugehen, als über das Attribut noexist.

[Ellert]

O.K., die Doku werde ich ergänzen. Die Attribute sind ja schon in der Befehlsreferenz beschrieben. Ich werde darauf verweisen und ein Beispiel einfügen?

[Damian]

O.K., die Doku werde ich ergänzen. Die Attribute sind ja schon in der Befehlsreferenz beschrieben. Ich werde darauf verweisen und ein Beispiel einfügen?

OK.

Wir sollten ein kurzes Beispiel auswählen, welches nicht nur die Funktionalität aufzeigt, sondern den Mehrwert für dieses Modul in der Praxis darstellt.

[Ellert]

Ich habe die Doku ergänzt mit einem kurzen, eindrucksvollen Beispiel.

[Damian]

Ich habe die Doku ergänzt mit einem kurzen, eindrucksvollen Beispiel.

Schön. Das Beispiel ist praxisrelevant. Es wäre allerdings besser statt ein/aus on/off zu nehmen, denn in der englischen Commandref verweise ich auf die vielen Beispiele mit englischen Bezeichnern. Mit dieser Funktionalität dürften einige dummys wegfallen und damit einige kontroverser Diskussionen zum Thema DOIF oder notify   Ich muss dann noch Anpassungen vornehmen, um die "user"-readings nicht zu löschen. Evtl. noch ein set deletereadings einbauen, für den Fall, dass jemand alle Readings in seinem DOIF bereinigen möchte.