DOIF neue Features: Generalisierung, $DEVICE, $EVENT, Attribut notexist

[Damian]

Liebe DOIF-Freunde,

ich habe u. a. Weihnachtstage genutzt und etwas an DOIF gebastelt.

1. Man kann nun in der Bedingung Eventtrigger wie folgt angeben:

["<Regexp für Devices>:<Regexp für Events>"]

Bespiele:

["FS"] triggert auf alle Devices, die "FS" im Namen beinhalten.
["^FS"] triggert auf alle Devices, die mit "FS" im Namen anfangen.
["FS:temp"] triggert auf alle Devices, die "FS" im Namen und "temp" im Event beinhalten
([":^temp"]) triggert auf beliebige Devices, die im Event mit "temp" beginnen.
(["^FS$:^temp$"] trigger auf Devices, die genau "FS" heißen und im Event genau "temp" vorkommt.
[""] triggert auf alles.

Selbstverständlich sind alle Möglichkeiten bei der Nutzung von regulären Ausdrücken gegeben.

2. In der Bedingung und im Ausführungsteil, kann nun  $DEVICE für das aktuelle Device und $EVENT genutzt werden.

3. Mit dem Attribut notexist, lässt sich ein Defaultwert für Readings, Stati usw. angeben, falls diese nicht existieren (wurde bereits mehrfach gewünscht)

Beispiel für Batteriezustandsanzeige für alle Devices mit einem DOIF:

Code Auswählen Erweitern

define Battery dummy

define di_battery DOIF ([":battery. low"] and [?Battery:$DEVICE] ne "low")
  ({Log 3, "Batteriewarnung von $DEVICE"}, setreading Battery $DEVICE low)
DOELSEIF ([":battery. ok"] and [?Battery:$DEVICE] ne "ok")
  ({Log 3, "Batterie wieder ok von $DEVICE"}, setreading Battery $DEVICE ok)

attr di_battery do always
attr di_battery notexist novalue


Damit hat man im Dummy Battery eine schöne Übersicht über den Batteriestatus aller Devices, die battery-Meldung senden.

Das Modul ist abwärtskompatibel zum bisherigen.

Es handelt sich um eine Testversion, sie kann hier zum Ausprobieren geladen werden. (Zum Einspielen muss das System durchgestartet werden, kein reload).

Viel Spaß beim Ausprobieren.

Edit: Aktuelle Version wurde eingecheckt.

Gruß

Damian

[marvin78]

Gibt es einen speziellen Grund, warum du $DEVICE verwendet hast und nicht $NAME, wie im notify?

Da man das hier ja aktuell immer dabei sagen muss: Das soll keine Kritik sein.

[Damian]

Gibt es einen speziellen Grund, warum du $DEVICE verwendet hast und nicht $NAME, wie im notify?

Da man das hier ja aktuell immer dabei sagen muss: Das soll keine Kritik sein.

ja, das steht noch zur Diskussion. Ich hatte zuerst $NAME drin gehabt, habe mich aber dann doch erst mal für $DEVICE entschieden, damit es keine Wechslung mit notifys gibt, da die Syntax bei DOIF oft ähnlich, aber doch anders als beim notify ist. Insb. z. B. bei der Angabe des Regexp wird bei notify intern ^ vorangestellt und $ am Ende hinzugefügt. Bei DOIF passiert das beim neuen Eventtrigger nicht, auch der Doppelpunkt gilt als Trennzeichen und gehört nicht zu Regexp, bei Events sind auch Leerzeichen erlaubt usw. usw.

Gruß

Damian

[marvin78]

Ich würde trotz allem $NAME bevorzugen. Das erleichtert am Ende ganz sicher den Support hier. Ich würde das "Verwechseln" mit notify eher als weniger problematisch sehen, als dass die Uneinheitlichkeit erstmal unlogisch wirkt (auch wenn Unterschiede ohnehin offensichtlich sind). Für jemanden, der nur DOIFS verwendet, ist das sicher gar kein Problem. Derjenige der aber denkt (und damit recht hat), dass manche Dinge doch deutlich einfacher mit notify zu lösen sind, wird die Inkonsistenz massiv stören. Für Umsteiger gilt das gleiche.

[Damian]

Ich würde trotz allem $NAME bevorzugen. Das erleichtert am Ende ganz sicher den Support hier. Ich würde das "Verwechseln" mit notify eher als weniger problematisch sehen, als dass die Uneinheitlichkeit erstmal unlogisch wirkt (auch wenn Unterschiede ohnehin offensichtlich sind). Für jemanden, der nur DOIFS verwendet, ist das sicher gar kein Problem. Derjenige der aber denkt (und damit recht hat), dass manche Dinge doch deutlich einfacher mit notify zu lösen sind, wird die Inkonsistenz massiv stören. Für Umsteiger gilt das gleiche.

ja, das können wir hier gerne besprechen. Andererseits könnte man DOIF mit notify kombinieren, wenn es unterschiedlich heißt (ob das jemals einer macht, ist eine andere Frage). Auch bei $EVENT bin ich mir noch nicht sicher, da es nicht das Gleiche ist wie beim notify.

[marvin78]

Ich habe nach dem Schreiben auch überlegt, dass man es kombinieren könnte und man konsequenterweise dann $EVENT auch anders bezeichnen müsste, weil es im DOIF, nach meinem Verständnis, ja nicht haargenau das gleiche sein muss, wie im notify. Schwierig.

Zunächst hatte ich hauptsächlich an Umsteiger gedacht, die ihre notifys zunächst 1zu1 zu DOIFs wandeln möchten. Betrachtet man es getrennt, verschwimmt die Argumentation.

[Damian]

Ich habe nach dem Schreiben auch überlegt, dass man es kombinieren könnte und man konsequenterweise dann $EVENT auch anders bezeichnen müsste, weil es im DOIF, nach meinem Verständnis, ja nicht haargenau das gleiche sein muss, wie im notify. Schwierig.

Zunächst hatte ich hauptsächlich an Umsteiger gedacht, die ihre notifys zunächst 1zu1 zu DOIFs wandeln möchten. Betrachtet man es getrennt, verschwimmt die Argumentation.

So ist das, denn das Schlimmste wäre den gleichen Bezeichner zu nutzen, der sich manchmal anders verhält, daher werde ich mir noch etwas für $EVENT einfallen lassen müssen, da es oft gleich, aber (funktionsbedingt) nicht immer das Gleiche ist, wie beim notify.

[kostra]

Einfach nur mal ein großes DANKE, da $EVENT und $DEVICE (oder welche Bezeichner man dann auch immer für wählt) wirklich SEHR gefehlt haben.
Ich nutze das DOIF u.a., um eine Warnung bei offenstehenden Fenstern zu erhalten, und da macht es schon Sinn zu wissen, welches Fenster da so lange offensteht

Also DANKE für die viele Arbeit.

kostra

[marvin78]

Stimmt. Das habe ich vergessen: Der Weg den DOIF jetzt nimmt, gefällt mir. DOIF war für mich und mein System bisher nur an wenigen Stellen brauchbar. Dieser Schritt ändert das

[AndreasHH]

Moin,

Vielen, vielen Dank für das Modul.

Ich bin gerade dabei meinen Wildwuchs an Notifies zu bereinigen,  da kommen mir die Neuerungen gerade recht.

Habe jetzt 2 Probleme, an denen ich seit Stunden hänge.

Gehe ich recht in der Annahme, dass $EVTPART im Gegensatz zu $EVENT nicht implementiert ist ?
Bekomme mit  folgender Definition Fehlermeldungen im DOIF:

e_regexp_c1:

Code Auswählen Erweitern


di_FHT_desired:error: { Log 3, "FHT-desired PID20.OGBad $EVTPART0"}: Global symbol "$EVTPART0" requires explicit package name at (eval 5943) line 1.


Code Auswählen Erweitern


error:
{ Log 3, "FHT-desired PID20.OGBad $EVTPART0"}: Global symbol "$EVTPART0" requires explicit package name at (eval 5943) line 1.


Code Auswählen Erweitern


define di_FHT_desired DOIF ([":desired"])\
  ({ Log 3, "FHT-desired $DEVICE" $EVTPART0})
# 
attr di_FHT_desired room Heizung
attr di_FHT_desired group Heizung
attr di_FHT_desired do always
#

Mir schwebt als Ziel etwas derartiges vor:

set $DEVICE_Zieltemp desired-temp $EVTPART1


Mein Zeites Problem besteht darin dass nicht getriggert wird, wenn ich die Bedingung erweitere um nur dann auslösen zu lassen, wenn die desired-temp grösser 11 ist.

Code Auswählen Erweitern


define di_FHT_desired DOIF ([":desired"] > 11)\
  ({ Log 3, "FHT-desired $DEVICE"})
# 
attr di_FHT_desired room Heizung
attr di_FHT_desired group Heizung
attr di_FHT_desired do always


freue mich über jeden Tipp.


Gruss

Andreas

[Ellert]

Moin,

Vielen, vielen Dank für das Modul.

Ich bin gerade dabei meinen Wildwuchs an Notifies zu bereinigen,  da kommen mir die Neuerungen gerade recht.

Habe jetzt 2 Probleme, an denen ich seit Stunden hänge.

Gehe ich recht in der Annahme, dass $EVTPART im Gegensatz zu $EVENT nicht implementiert ist ?
Bekomme mit  folgender Definition Fehlermeldungen im DOIF:

e_regexp_c1:

Code Auswählen Erweitern


di_FHT_desired:error: { Log 3, "FHT-desired PID20.OGBad $EVTPART0"}: Global symbol "$EVTPART0" requires explicit package name at (eval 5943) line 1.


Code Auswählen Erweitern


error:
{ Log 3, "FHT-desired PID20.OGBad $EVTPART0"}: Global symbol "$EVTPART0" requires explicit package name at (eval 5943) line 1.


Code Auswählen Erweitern


define di_FHT_desired DOIF ([":desired"])\
  ({ Log 3, "FHT-desired $DEVICE" $EVTPART0})
# 
attr di_FHT_desired room Heizung
attr di_FHT_desired group Heizung
attr di_FHT_desired do always
#

Mir schwebt als Ziel etwas derartiges vor:

set $DEVICE_Zieltemp desired-temp $EVTPART1


Mein Zeites Problem besteht darin dass nicht getriggert wird, wenn ich die Bedingung erweitere um nur dann auslösen zu lassen, wenn die desired-temp grösser 11 ist.

Code Auswählen Erweitern


define di_FHT_desired DOIF ([":desired"] > 11)\
  ({ Log 3, "FHT-desired $DEVICE"})
# 
attr di_FHT_desired room Heizung
attr di_FHT_desired group Heizung
attr di_FHT_desired do always


freue mich über jeden Tipp.


Gruss

Andreas

Die Ereignissteile könntest Du mit split(/ /,$EVENT) selbst erzeugen

zu Zweitens:

Code Auswählen Erweitern

([":desired"] and [?$DEVICE:desired-temp] > 11)

[Damian]

Moin,

Vielen, vielen Dank für das Modul.

Ich bin gerade dabei meinen Wildwuchs an Notifies zu bereinigen,  da kommen mir die Neuerungen gerade recht.

Habe jetzt 2 Probleme, an denen ich seit Stunden hänge.

Gehe ich recht in der Annahme, dass $EVTPART im Gegensatz zu $EVENT nicht implementiert ist ?
Bekomme mit  folgender Definition Fehlermeldungen im DOIF:

e_regexp_c1:

Code Auswählen Erweitern


di_FHT_desired:error: { Log 3, "FHT-desired PID20.OGBad $EVTPART0"}: Global symbol "$EVTPART0" requires explicit package name at (eval 5943) line 1.


Code Auswählen Erweitern


error:
{ Log 3, "FHT-desired PID20.OGBad $EVTPART0"}: Global symbol "$EVTPART0" requires explicit package name at (eval 5943) line 1.


Code Auswählen Erweitern


define di_FHT_desired DOIF ([":desired"])\
  ({ Log 3, "FHT-desired $DEVICE" $EVTPART0})
# 
attr di_FHT_desired room Heizung
attr di_FHT_desired group Heizung
attr di_FHT_desired do always
#

Mir schwebt als Ziel etwas derartiges vor:

set $DEVICE_Zieltemp desired-temp $EVTPART1


Mein Zeites Problem besteht darin dass nicht getriggert wird, wenn ich die Bedingung erweitere um nur dann auslösen zu lassen, wenn die desired-temp grösser 11 ist.

Code Auswählen Erweitern


define di_FHT_desired DOIF ([":desired"] > 11)\
  ({ Log 3, "FHT-desired $DEVICE"})
# 
attr di_FHT_desired room Heizung
attr di_FHT_desired group Heizung
attr di_FHT_desired do always


freue mich über jeden Tipp.


Gruss

Andreas

Hallo Andreas,

ich sehe schon, ich werde noch alle Features vom notify nachbauen müssen

Es wäre sicherlich ein Leichtes $EVTPART zu realisieren.

Wo man mit notifys ohne Perlcode insbesondere ohne if-Abfragen auskommt, da kann man sie auch gut weiternutzen.

Die Angabe ["..."] stellt einen Trigger dar, so wie vorher bereits [<DEVICE>] und kann nur wahr oder falsch sein.

Generalisierte Abfragen auf Stati und Readings gibt es nicht und kann es auch nicht geben, weil Abfragen der Art (["DEVICE1":temperature]> 0 and  ["DEVICE2":temperature]> 0) nicht funktionieren würden, wenn eines der beiden Devices triggert, denn das andere wäre nicht definiert.

Du kannst aber definieren:

Code Auswählen Erweitern

define di_FHT_desired DOIF ([":desired"] and [$DEVICE:desired] > 11)...

Gruß

Damian

[Damian]

Die Ereignissteile könntest Du mit split(/ /,$EVENT) selbst erzeugen

zu Zweitens:

Code Auswählen Erweitern

([":desired"] and [?$DEVICE:desired-temp] > 11)

Angabe mit [$DEVICE:...] triggert nicht (ich habe vorsorglich etwas mehr Intelligenz eingebaut als nur simples Ersetzen ), konsequenter Weise funktioniert natürlich das Fragezeichen hier auch.

[AndreasHH]

Moin,

Vielen Dank für Eure Hilfe.
Habe es wie folgt gelöst:

Code Auswählen Erweitern


define di_FHT_desired DOIF (["FHT_:desired-temp"] and [$DEVICE:desired-temp] > 11)\
( { my $Zieltemp=ReadingsVal("$DEVICE","desired-temp","18") ;;;;\
    fhem ("set $DEVICE_Zieltemp $Zieltemp")})


Würde mEn mit $EVTPART kürzer und übersichtlicher sein.
Möglicherweise habe ich aber auch nur nicht einen geschickteren Weg gefunden.

Gruss

Andreas

[Ralli]

Hallo Damian,

vielen herzlichen Dank für Deine Mühe! Das sind genau die Dinge, die (mir) noch gefehlt haben, toll dass Du sie nun realisierst.