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:
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
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.
Zitat von: marvin78 am 29 Dezember 2015, 10:57:53
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
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.
Zitat von: marvin78 am 29 Dezember 2015, 12:09:03
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.
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.
Zitat von: marvin78 am 29 Dezember 2015, 12:25:15
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.
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
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 ;)
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:
di_FHT_desired:error: { Log 3, "FHT-desired PID20.OGBad $EVTPART0"}: Global symbol "$EVTPART0" requires explicit package name at (eval 5943) line 1.
error:
{ Log 3, "FHT-desired PID20.OGBad $EVTPART0"}: Global symbol "$EVTPART0" requires explicit package name at (eval 5943) line 1.
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.
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
Zitat von: AndreasHH am 29 Dezember 2015, 16:46:33
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:
di_FHT_desired:error: { Log 3, "FHT-desired PID20.OGBad $EVTPART0"}: Global symbol "$EVTPART0" requires explicit package name at (eval 5943) line 1.
error:
{ Log 3, "FHT-desired PID20.OGBad $EVTPART0"}: Global symbol "$EVTPART0" requires explicit package name at (eval 5943) line 1.
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.
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:
([":desired"] and [?$DEVICE:desired-temp] > 11)
Zitat von: AndreasHH am 29 Dezember 2015, 16:46:33
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:
di_FHT_desired:error: { Log 3, "FHT-desired PID20.OGBad $EVTPART0"}: Global symbol "$EVTPART0" requires explicit package name at (eval 5943) line 1.
error:
{ Log 3, "FHT-desired PID20.OGBad $EVTPART0"}: Global symbol "$EVTPART0" requires explicit package name at (eval 5943) line 1.
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.
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:
define di_FHT_desired DOIF ([":desired"] and [$DEVICE:desired] > 11)...Gruß
Damian
Zitat von: Ellert am 29 Dezember 2015, 17:06:39
Die Ereignissteile könntest Du mit split(/ /,$EVENT) selbst erzeugen
zu Zweitens:
([":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.
Moin,
Vielen Dank für Eure Hilfe.
Habe es wie folgt gelöst:
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
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.
Zitat von: AndreasHH am 30 Dezember 2015, 01:03:59
Moin,
Vielen Dank für Eure Hilfe.
Habe es wie folgt gelöst:
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
Du willst doch nicht etwa wieder mit den Perl-Konstruktionen anfangen, wenn vier Semikolons nicht genug wäre ;)
define di_FHT_desired DOIF (["FHT_:desired-temp"] and [$DEVICE:desired-temp] > 11)
(set $DEVICE_Zieltemp [$DEVICE:desired-temp])
Gruß
Damian
Ich erlaube mir hier zwischendurch mal ein ganz großes Lob an die Macher von DOIF auszusprechen. Man kann damit wunderbar einfache Konstrukte schreiben, die ansonsten nur mühsam zu programmieren wären. Ich habe an der Zeitsteuerung für meine elektrische Weihnachtsbeleuchtung gebastelt, zuerst mit gefühlt unendlich vielen "at" und darin enthaltenen"if..elsif...", irgendwann habe ich dann aufgegeben und mich entschieden mal die commandref zu DOIF zu lesen (zum x-ten Male übrigens). Als Ergebnis komme ich nun mit wenigen Zeilen Code und 2 Attributen aus. Das zeigt, wie praxisgerecht das gemacht wurde. Der Preis dafür: quasi eine weitere Syntax lernen.
Keine Kritik, sondern ur eine Frage: warum sind die vielen guten Beispiel in der Commandref und nicht im Wiki geschrieben? Da ich mittlerweile immer beides lese, ist es letztendlich egal, aber gefühlsmäßig würde ich Beispiele immer im Wiki suchen, während die Commandref nur die "trockene" Theorie beschreibt - und ggf. auf das Wiki verweist :)
Also nochmals Danke und eine guten Rutsch!
Zitat von: ujaudio am 31 Dezember 2015, 11:45:06
Keine Kritik, sondern ur eine Frage: warum sind die vielen guten Beispiel in der Commandref und nicht im Wiki geschrieben? Da ich mittlerweile immer beides lese, ist es letztendlich egal, aber gefühlsmäßig würde ich Beispiele immer im Wiki suchen, während die Commandref nur die "trockene" Theorie beschreibt - und ggf. auf das Wiki verweist :)
Als ich mit dem Modul angefangen habe, war die Doku noch kürzer. Im Laufe der Zeit ist sie gewachsen. Mir war vom Anfang an wichtig jede Funktionalität des Moduls immer mit Hilfe von mir sorgfältig ausgewählten Beispiele zu erklären. Dieses Konzept scheint aufzugehen, sonst wäre das Modul nicht so erfolgreich. Denn man muss bedenken, dass hier die meisten nicht Informatiker und auch nicht Softwareentwickler sind. Doku die an diese Zielgruppe gerichtet wäre, würden hier viele nicht gut verstehen können.
Wiki-Beiträge kann jeder ergänzend erstellen, ich möchte dagegen nur eine Quelle mit gut ausgewählten Beispielen pflegen und auf dem aktuellen Stand halten und nicht mehrere.
ZitatDas zeigt, wie praxisgerecht das gemacht wurde
Das untermauert meine Vorgehensweise, zu jedem Feature, welches ich mir ausgedacht habe, gehört ein praxisgerechter Anwendungsfall (den ich bereits während der Entwicklung im Hinterkopf habe), nachdem man nicht lange suchen sollte.
Gruß
Damian
Hallo Damian,
Seit gestern benötige ich Die erweiterten Funktionen Deines DOIF's. Ich möchte auf alle TempFeuchtSensor* triggern lassen. Laut Deiner Erklärung wäre das dann
["^TempFeuchtSensor":temperature]
Ist das in etwa so richtig? Geht eigentlich auch ein
["^Heizungsthermostat.*._Clima":desired-temp]
Um auf alle Climakanäle meiner Thermostate zu Triggern? Ich habe die Events nicht in "" genommen weil ich da keine RegEx brauchem. Ist das richtig so?
Grüße
Leon
Zitat von: CoolTux am 03 Januar 2016, 14:57:13
Hallo Damian,
Seit gestern benötige ich Die erweiterten Funktionen Deines DOIF's. Ich möchte auf alle TempFeuchtSensor* triggern lassen. Laut Deiner Erklärung wäre das dann
["^TempFeuchtSensor":temperature]
Ist das in etwa so richtig? Geht eigentlich auch ein
["^Heizungsthermostat.*._Clima":desired-temp]
Um auf alle Climakanäle meiner Thermostate zu Triggern? Ich habe die Events nicht in "" genommen weil ich da keine RegEx brauchem. Ist das richtig so?
Wenn "Clima" ein Teil des Devicenamens ist, ja. Der Punkt hinter dem Sternchen dürfte überflüssig sein. Die erste Angabe ist auch ok.
Edit: Allerdings muss die zweite Angabe auch noch innerhalb der Anführungszeichen sein: also:
["^TempFeuchtSensor:temperature"]
und
["^Heizungsthermostat.*_Clima:desired-temp"]
Gruß
Damian
@Damian
Ich habe mal die Batteriewarnung probiert. Nun bekomme ich aber im DOIF folgfende Fehlermeldung:
error: Wrong timespec ":batterylow": either HH:MM:SS or {perlcode}
Ist etwas in deinem Beispiel noch zu ändern?
Danke Lutz
Zitat von: cruser1800 am 03 Januar 2016, 16:03:05
@Damian
Ich habe mal die Batteriewarnung probiert. Nun bekomme ich aber im DOIF folgfende Fehlermeldung:
error: Wrong timespec ":batterylow": either HH:MM:SS or {perlcode}
Ist etwas in deinem Beispiel noch zu ändern?
Danke Lutz
Dann hast du wohl nicht die neue Version bei dir aktiv.
Ich dachte mit dem Update von Heute war die Änderung schon mit drin! Kopiere wieder die alte Version rein!
Danke
Zitat von: cruser1800 am 03 Januar 2016, 16:45:06
Ich dachte mit dem Update von Heute war die Änderung schon mit drin! Kopiere wieder die alte Version rein!
Danke
Nein, das war nur ein bugfix. Die neue muss sich erst mal bewähren :)
Zitat von: Damian am 03 Januar 2016, 17:03:38
Nein, das war nur ein bugfix. Die neue muss sich erst mal bewähren :)
Ich habe den bugfix für die neue Version nachgezogen. Sie befindet sich im ersten Post.
Hallo Damian,
Vielen Dank für Deine Antwort. Ich schaue mir das dann mal Morgen in Ruhe an. Und vielen vielen Dank für Dein Modul. Das ist mega Top.
Grüße
Leon
Hallo Domain,
Fehlermeldungen sind weg. Mit
trigger Haustuer battery: low
wollte ich jetzt testen. Es reagiert aber leider nicht. Steht weiter auf initialized. Habe das Beispiel wie vorne beschrieben kopiert.
Kannst du mir mal auf die Sprünge helfen!
Danke
Lutz
Das trigger funktioniert so nicht. trigger an sich geht wohl führt aber nicht zum gewünschten Ergebniss, nämlich zum ausführen des DOIF's
Grüße
Danke für die Antwort.
Wie kann ich jetzt das Programm testen? Bis mal wieder eine Batterie leer geht habe ich es vergessen was ich wollte! ;)
Ich wüsste da nur die Holzhammermethode, von Hand ins Reading ein Low schreiben.
setreading Thermostat battery low
Ist aber nicht gerade ne gute Methode
Zitat von: cruser1800 am 03 Januar 2016, 19:04:08
Hallo Domain,
Fehlermeldungen sind weg. Mit
trigger Haustuer battery: low
wollte ich jetzt testen. Es reagiert aber leider nicht. Steht weiter auf initialized. Habe das Beispiel wie vorne beschrieben kopiert.
Kannst du mir mal auf die Sprünge helfen!
Danke
Lutz
Mit trigger kann man es schon testen. So wie es aussieht, habe ich in meinem Beispiel den obligatorischen Doppelpunkt vergessen, der im Eventmonitor sichtbar das Reading vom Wert trennt.
Daher müsste die Angabe in meinem Beispiel wohl so aussehen ([":battery: low"], dann sollte dein Test funktionieren.
Edit: Der Doppelpunkt ist beim DOIF ein Trenner, daher muss man wohl erstmal statt Doppelpunkt einen Punkt für ein beliebiges Zeichen angeben, daher:
[":battery. low"]
Gruß
Damian
ZitatEdit: Der Doppelpunkt ist beim DOIF ein Trenner, daher muss man wohl erstmal statt Doppelpunkt einen Punkt für ein beliebiges Zeichen angeben, daher:
[":battery. low"]
ich hatte das die Tage auch mal ausprobiert mit der Batterieanzeige und habe mich gewundert warum nichts kam...
Mit obiger Änderung im DOIF werden jetzt die Readings des Dummy gefüllt, aber das State vom Dummy hat weiterhin ??? drin
Zitat von: moonsorrox am 04 Januar 2016, 00:43:37
ich hatte das die Tage auch mal ausprobiert mit der Batterieanzeige und habe mich gewundert warum nichts kam...
Mit obiger Änderung im DOIF werden jetzt die Readings des Dummy gefüllt, aber das State vom Dummy hat weiterhin ??? drin
Der Status wird in meinem Beispiel auch nicht belegt. Es ist ja auch nur ein Beispiel. Du kannst aber die Herausforderung annehmen und das Bespiel bei dir so anpassen, dass z. B. im Status das Device der letzten Änderung drin steht.
Gruß
Damian
Hallo,
jetzt funktionierts! ;D
Klasse Arbeit!
Gruß Lutz
Zitat von: ujaudio am 31 Dezember 2015, 11:45:06Ich erlaube mir hier zwischendurch mal ein ganz großes Lob an die Macher von DOIF auszusprechen.
Dem muss ich mich, trotz nachfolgender Kritik (ja, ich nenne es so und dazu stehe ich!), vorbehaltlos anschließen.
Punkt 1:
Zitat von: ujaudio am 31 Dezember 2015, 11:45:06Keine Kritik, sondern ur eine Frage: warum sind die vielen guten Beispiel in der Commandref und nicht im Wiki geschrieben? Da ich mittlerweile immer beides lese, ist es letztendlich egal, aber gefühlsmäßig würde ich Beispiele immer im Wiki suchen, während die Commandref nur die "trockene" Theorie beschreibt - und ggf. auf das Wiki verweist :)
Zitat von: Damian am 31 Dezember 2015, 13:20:52Wiki-Beiträge kann jeder ergänzend erstellen, ich möchte dagegen nur eine Quelle mit gut ausgewählten Beispielen pflegen und auf dem aktuellen Stand halten und nicht mehrere.
Im Wiki steht es auf einer Seite und man kann gut navigieren (
Pos1,
Ende), in der Commandref ist es ein Punkt unter vielen, nimmt aber gefühlte 10% der Ref ein. Damit ist nicht nur das Navigieren innerhalb von DOIF schwer, sondern auch um DOIF herum.
Ich als Verantwortlicher würde in der Commandref eh nur interne Sachen auflisten. Externe Module (und noch ;) ist DOIF eins) alle extra (Wiki).
Zitat von: ujaudio am 31 Dezember 2015, 11:45:06Der Preis dafür: quasi eine weitere Syntax lernen.
Ein Punkt, mit dem DOIF aber nicht alleine steht. Warum gibt es so viele verschiedene Trennzeichen (z.B. in den Attribs): Doppelpunkt (wait) und Pipe (cmdState), von extern (z.B. floorplan) kommen noch Komma, Leezeichen dazu? Auch Klein- und Gemischtschreibung muss nicht sein: "timerWithWait" aber "cmdpause" und "wait"!
Trotz dieser Kritkpunkte werde ich jetzt weitere notifys durch neue DOIFs (mit .* :D) ersetzen, das ist besser zu lesen und viel übersichtlicher.
Zitat von: Per am 05 Januar 2016, 10:39:24
Dem muss ich mich, trotz nachfolgender Kritik (ja, ich nenne es so und dazu stehe ich!), vorbehaltlos anschließen.
Punkt 1:Im Wiki steht es auf einer Seite und man kann gut navigieren (Pos1, Ende), in der Commandref ist es ein Punkt unter vielen, nimmt aber gefühlte 10% der Ref ein. Damit ist nicht nur das Navigieren innerhalb von DOIF schwer, sondern auch um DOIF herum.
Ich als Verantwortlicher würde in der Commandref eh nur interne Sachen auflisten. Externe Module (und noch ;) ist DOIF eins) alle extra (Wiki).
Ein Punkt, mit dem DOIF aber nicht alleine steht. Warum gibt es so viele verschiedene Trennzeichen (z.B. in den Attribs): Doppelpunkt (wait) und Pipe (cmdState), von extern (z.B. floorplan) kommen noch Komma, Leezeichen dazu? Auch Klein- und Gemischtschreibung muss nicht sein: "timerWithWait" aber "cmdpause" und "wait"!
Trotz dieser Kritkpunkte werde ich jetzt weitere notifys durch neue DOIFs (mit .* :D) ersetzen, das ist besser zu lesen und viel übersichtlicher.
ja, das Problem mit der wachsenden Dokumentation des Moduls wurde in der letzten Zeit öfters diskutiert, was ich auch gut nachvollziehen kann. Es sind z. Zt. übrigens nur 5 % der gesamten Commandref ;)
Ich habe kein Problem, die Dokumentation anders zu gestalten, allerdings sollten folgende Punkte aus meiner Sicht Berücksichtigung finden:
1. Der Ausgangspunkt der Doku eines jeden FHEM-Moduls, sollte immer die Commandref sein, da man dort zuerst nachschaut.
2. Dokumentation für den FHEM-User sollte verständlich mit typischen Beispielen versehen sein, nach denen man nicht lange suchen sollte.
Der typische FHEM-User dürfte inzwischen kein Informatiker sein, der gewohnt ist z. B. UNIX-Referenzbücher zu lesen, Perl ist für die meisten hier schon Zumutung genug, auch wenn ich die Programmiersprache gut finde.
3. Es muss sichergestellt sein, dass die Dokumentation vom Autor 100 prozentig kontrollierbar ist. Sie muss immer stimmen, sie darf nicht veraltet sein, Bespiele müssen geradlinig sein, Sachverhalten dürfen nicht unnötig komplizieren dargestellt werden. All das trifft z. Zt. nicht auf die beiden Einträge der Wiki-DOIF-Seite zu (die nicht von mir stammen).
Für alles Weitere, was über die Dokumentation hinausgeht, sind Wiki-Beiträge eine sehr gute Bereicherung.
4. Die Dokumentation muss für den Autor (Entwickler) einfach zu pflegen sein und nur aus einer Dokumentationsquelle stammen.
Für alles andere habe ich keine Zeit.
Wenn jemand eine Lösung parat hat, die die obigen Punkte abdeckt, bitte schön ...
Zu der Schreibweise der Syntax: zum Zeitpunkt der Definition, war es eine schlüssige Entscheidung, die man später nicht mehr ohne Weiters ändern kann :(
Gruß
Damian
Hallo Damian!
zu 1.
Ja.
zu 2.
Ja. Deshalb ist es gut, wenn die Doku mit den Beispielen nicht überall verstreut ist. Lästig ist es mMn in commandref, Wiki, Forum und einer/mehreren Pdf(s) zu suchen. UliM hat bspw. vor Kurzem sein FLOORPLAN-Pdf ins Wiki überführt. Für mich ist es dann einfacher zu lesen/suchen, als in einer Pdf.
zu 3.
Die Beispiele auf der Wiki-Seite wurden in Absprache entfernt.
Auch jetzt gibt es schon Wiki-Seiten, die ausschließlich von einem eingeschränkten Personenkreis (bspw. http://www.fhemwiki.de/wiki/Erste_Schritte_in_fhem) oder durch den Entwickler (http://www.fhemwiki.de/wiki/SONOS) gepflegt und bearbeitet werden. Also dort gibt es sicherlich Lösungsmöglichkeiten.
zu 4.
Was für Dich einfach zu pflegen ist, kannst nur Du beurteilen. Dazu gibt es keine allgemeine Lösung. Das darfst (musst) Du für Dich entscheiden. ;)
Gruß, Christian
Ich bevorzuge die CommandRef. Es gab doch auch vor wenigen Wochen einen Thread, wo man über die theoretische Umstrukturierung der CommandRef gesprochen hatte. Ich habe aber keine Ahnung, wie da der letzte Stand ist.
Damian hat es mit der Pflege der CommandRef sicherlich auch einfacher, da er seine bisherigen Entwicklungstools (Editor, SVN/Git, etc.) weiternutzen kann. Man muss auch keine neue Wiki-Syntax lernen. :-)
Ich wollte keine OT-Diskussion in diesem Thread lostreten, ich hatte eine Frage, die ist auch gut beantwortet worden und gut ist es. Bitte entschuldigt, dass ich als Urheber dies hier hineingebracht habe. Ich werde zukünftig bei Fragen, die nicht direkt zu Thread passen immer einen neuen aufmachen.
Nebenbei: irgendwie veringert sich die Anzahl meiner notify in den letzen Tagen ;)
und jetzt weiter mit den neuen Features
Zitat von: ujaudio am 05 Januar 2016, 18:25:41
Ich wollte keine OT-Diskussion in diesem Thread lostreten, ich hatte eine Frage, die ist auch gut beantwortet worden und gut ist es. Bitte entschuldigt, dass ich als Urheber dies hier hineingebracht habe. Ich werde zukünftig bei Fragen, die nicht direkt zu Thread passen immer einen neuen aufmachen.
Nebenbei: irgendwie veringert sich die Anzahl meiner notify in den letzen Tagen ;)
und jetzt weiter mit den neuen Features
Die Doku gehört genauso zum Modul wie auch seine Features, daher finde ich die Diskussion gar nicht so falsch an dieser Stelle.
Ich habe bereits im August hier http://forum.fhem.de/index.php/topic,39854.msg320662.html#msg320662 einen Vorschlag genau zum Thema Commandref-Darstellung gemacht. Es sind auch ein paar vernünftige Vorschläge gekommen (inkl. globaler Suche innerhalb der Commandref). Die Diskussion ist dann wohl im Sande verlaufen - schade.
Die Sache liegt nicht in meiner Hand, sonst hätte ich schon längst eine hierarchische Darstellung der Commandref umgesetzt.
Gruß
Damian
@Damian: gibt's schon einen Zeitplan, wann die neuen Funktionen die Testphase verlassen und "scharf" geschaltet werden? Oder habe ich da was nicht mitbekommen?
Zitat von: l2r am 19 Januar 2016, 14:57:58
@Damian: gibt's schon einen Zeitplan, wann die neuen Funktionen die Testphase verlassen und "scharf" geschaltet werden? Oder habe ich da was nicht mitbekommen?
Wahrscheinlich Mitte Februar, ich betreibe noch Feintuning und habe gerade wenig Zeit zum Programmieren.
Gruß
Damian
Version 0.4 im ersten Post:
Folgende Schlüsselwörter werden in der Bedingung sowie im Ausführungsteil ersetzt:
$DEVICE (wie bisher)
$EVENT passendes Event, welches zu Regex-Angabe passt. (wie bisher)
$EVENTS alle Events des Triggers (neu)
daneben gibt es jetzt äquivalent "echte" Perlvariablen, die in der gewohnten Perl-Syntax in der Bedingung abgefragt werden können:
$device
$event
$events
In der Regexp kann jetzt auch ein Doppelpunkt angegeben werden.
Doku muss ich noch anpassen.
Gruß
Damian
Ich habe fertig!
Ich habe die Doku aktualisiert und noch ein paar Korrekturen vorgenommen. Beim Attribut notexist sollte man den Default-Wert in Anführungszeichen setzen. Damit lässt sich auch 0 und leere Zeichenkette definierten, Angaben, die man ja häufiger benutzt ;)
@Ellert
Ich habe die Kurzreferenz angepasst und ans Ende der Inhaltsübersicht gelegt, da es ja in erster Linie Nachschlag-Referenz für DOIF-Nutzer ist. Anfänger sollten erst mal vorne anfangen, bevor sie in der Kurzreferenz nachschlagen.
Wenn keiner mehr was meldet, checke ich diese Version in den nächsten Tagen ein.
Aktuelle Version 0.5 befindet sich im ersten Post.
Edit: In der Doku habe ich zu neuen Features ein Beispiel für: "Loggen aller Events in FHEM" und "Batterie-Warnung per E-Mail" hinzugefügt.
Gruß
Damian
Hallo Damian,
ich habe kleine Änderungen vorgenommen, Basis ist Version 0.5:
Da $device,$event und $events nur in den Bedingungen gültig sind, habe ich sie in der Kurzreferenz unter die Überschrift "Operanden in der Bedingung" verschoben.
Einmal "&" bei "nbsp;" ergänzt, bei der Überschrift "Filtern nach Zahlen".
Das Ende der Kurzreferenz markiert mit "<!-- Ende der Kurzreferenz -->"
Da es kein $EVTPART gibt, würdest Du ein Beispiel für sinnvoll halten, wie man es nachbilden kann?
((set einDummy {(my @evt = split(" ","$EVENT");; return $evt[<Nummer des Eventparts>])}))
Gruss
Ellert
Hi Damian,
wollte mich jetzt auch mal versuchen:
define di_rr_Julian_car2
(
["^rr_:^locationPresence$"] eq "absent" and
[?$DEVICE:location] eq "BMW"
)
(
(msg push @$DEVICE |Parkplatz für [$DEVICE:location]| Das Auto wurde hier geparkt O[{"URLTITLE":"'In Google Maps öffnen'","ACTION":"'comgooglemapsurl://maps.google.com/?q=[$DEVICE:locationLat],[$DEVICE:locationLong]'","RETRY":0,"EXPIRE":0}])
)
DOELSE
attr di_rr_Julian_car2 do always
attr di_rr_Julian_car2 wait 300
Allerdings wird cmd_1 nie ausgelöst.
Im Reading e_regexp_c1 sehe ich aber, dass das passende Event eigentlich vorbeiläuft:
rr_Julian:locationPresence: absent locationLat: 48.XXX locationLong: 11.XXX locationAddr: Strasse ABC PLZ Stadt location: BMW
Wo liegt denn hier der Fehler?
Gruß
Julian
Zitat von: Loredo am 24 Januar 2016, 20:15:22
define di_rr_Julian_car2
(
["^rr_:^locationPresence$"] eq "absent" and
[?$DEVICE:location] eq "BMW"
)
Event-Abfragen können nur wahr oder falsch sein und liefern keinen Wert eines Events selbst, du meinst wohl eher:
...["^rr_:^locationPresence: absent"] and [?$DEVICE:location] eq "BMW" ...Gruß
Damian
Zitat von: Ellert am 24 Januar 2016, 20:14:03
Hallo Damian,
ich habe kleine Änderungen vorgenommen, Basis ist Version 0.5:
Da $device,$event und $events nur in den Bedingungen gültig sind, habe ich sie in der Kurzreferenz unter die Überschrift "Operanden in der Bedingung" verschoben.
Einmal "&" bei "nbsp;" ergänzt, bei der Überschrift "Filtern nach Zahlen".
Das Ende der Kurzreferenz markiert mit "<!-- Ende der Kurzreferenz -->"
Da es kein $EVTPART gibt, würdest Du ein Beispiel für sinnvoll halten, wie man es nachbilden kann?
((set einDummy {(my @evt = split(" ","$EVENT");; return $evt[<Nummer des Eventparts>])}))
Gruss
Ellert
Ich habe auch noch ein paar Tippfehler gefunden. Zu den Variablen: Was ich noch nicht gesagt habe ist, dass man sie auch innerhalb einer Berechnung innerhalb eines FHEM-Befehls nutzen kann: set bla {($event/2)}, was z. Zt. nicht geht ist, diese Variablen innerhalb von reinen Perlsequenzen (set bla on, {irgendwas in Perl}) zu nutzen, da ich die Auswertung an eine fhem-Routine übergebe.
Die Frage ist ob $EVTPART so eine Bedeutung hat, wie beim notify, da man diese Informationen beim DOIF aussagekräftiger normalerweise als Reading mit [$DEVICE:reading] ansprechen kann. Wenn der Bedarf allerdings beim DOIF nach den $EVTPARTS gegeben sein wird, dann baue ich sie einfach ins Modul ein.
Gruß
Damian
Zitat(set bla on, {irgendwas in Perl})
Ich hatte mit (({Log 1, "$event"})) getestet, ob die Variablen in der Bedingung gültig sind.
Jetzt ist klar, warum das nicht funktionierte.
Unter "Verzögerungen" gibt es einen kleinen Fehler, der ist in irgendeinem Thema aufgefallen:
DOELSE (Bedingung2)
Danke Ellert
Zitat von: Ellert am 24 Januar 2016, 21:43:44
Ich hatte mit (({Log 1, "$event"})) getestet, ob die Variablen in der Bedingung gültig sind.
Jetzt ist klar, warum das nicht funktionierte.
Unter "Verzögerungen" gibt es einen kleinen Fehler, der ist in irgendeinem Thema aufgefallen:
DOELSE (Bedingung2)
Danke Ellert
Ob die Variablen eine große Bedeutung haben werden, weiß ich noch nicht. Normalerweise reichen die Platzhalter in Großbuchstaben. Ich hielt es für reizvoll die Variablen in der Bedingung zu haben, weil diese ja in Perl ausgewertet wird und damit hat man alle Möglichkeiten der Abfragen in Perl, auch wenn ich bisher keinen echten Anwendungsfall gefunden habe, der nicht mit den anderen Mitteln möglich wäre - kommt bestimmt noch.
Gruß
Damian
Zitat von: Damian am 24 Januar 2016, 20:39:33
Event-Abfragen können nur wahr oder falsch sein und liefern keinen Wert eines Events selbst, du meinst wohl eher:
...["^rr_:^locationPresence: absent"] and [?$DEVICE:location] eq "BMW" ...
Ok, den Hinweis hab ich nicht berücksichtigt. Danke dafür!
Allerdings funktioniert es so trotzdem nicht, der Trigger wird nicht ausgelöst.
Zitat von: Loredo am 24 Januar 2016, 22:33:54
Ok, den Hinweis hab ich nicht berücksichtigt. Danke dafür!
Allerdings funktioniert es so trotzdem nicht, der Trigger wird nicht ausgelöst.
Poste mal list deines Moduls. Aktuelle Version V 0.5 hast du schon?
Gruß
Damian
Hallo Damian,
folgendes Test-DOIF führt in Version 0.5 nicht zu dem erwünschten Verhalten:
define DOIF_lowbat_WS1 DOIF (["WS.:temperature"] < 30) (setreading UEA.Batterie_niedrig $DEVICE low) DOELSEIF (["WS.:temperature"] > 40) (setreading UEA.Batterie_niedrig $DEVICE ok)
Denn der Dummy UEA.Batterie_niedrig bekommt folgendes Reading verpasst:
DOIF_lowbat_WS1 low 2016-01-26 07:10:04
und nicht richtigerweise
WS1 low 2016-01-26 07:10:04
Also wird als $DEVICE nicht das triggernde Device genommen sondern das getriggerte DOIF.
Wobei ich es grundsätzlich gut fände, wenn tatsächlich mit einer weiteren Variable wie $SELF o.ä. der Name des getriggerten DOIF (wie auch $CMD / $CMD_SEQ) mit im Ausführungsteil verwandt werden könnte ;).
Zitat von: Ralli am 26 Januar 2016, 07:17:37
Hallo Damian,
folgendes Test-DOIF führt in Version 0.5 nicht zu dem erwünschten Verhalten:
define DOIF_lowbat_WS1 DOIF (["WS.:temperature"] < 30) (setreading UEA.Batterie_niedrig $DEVICE low) DOELSEIF (["WS.:temperature"] > 40) (setreading UEA.Batterie_niedrig $DEVICE ok)
Denn der Dummy UEA.Batterie_niedrig bekommt folgendes Reading verpasst:
DOIF_lowbat_WS1 low 2016-01-26 07:10:04
und nicht richtigerweise
WS1 low 2016-01-26 07:10:04
Also wird als $DEVICE nicht das triggernde Device genommen sondern das getriggerte DOIF.
Wobei ich es grundsätzlich gut fände, wenn tatsächlich mit einer weiteren Variable wie $SELF o.ä. der Name des getriggerten DOIF (wie auch $CMD / $CMD_SEQ) mit im Ausführungsteil verwandt werden könnte ;).
Mit der Angabe "WS.: triggerst du auf alle Devices die WS beinhalten, du willst aber offensichtich Devices, die mit WS beginnen dann musst du "^WS: für Device angeben. Das steht auch in der neuen Doku zum Modul.
Gruß
Damian
Das ist so weit verstanden (gewesen). Ich habe aber nicht bedacht, dass dieses DOIF durch WS im eigenen Namen sich selbst triggern kann. Böse Falle.
Edit:
Klappt trotzdem nicht. Neue Definition:
define DOIF_lowbat_WS1 DOIF (["^WS.:temperature"] < 30) (setreading UEA.Batterie_niedrig $DEVICE low) DOELSEIF (["^WS.:temperature"] > 40) (setreading UEA.Batterie_niedrig $DEVICE ok)
führt wieder zu gleichem Ergebnis, der Dummy UEA.Batterie_niedrig bekommt folgendes Reading verpasst:
DOIF_lowbat_WS1 low 2016-01-26 13:54:43
Der Event-Monitor brachte Folgendes:
Zitat
2016-01-26 13:54:33 DOIF DOIF_lowbat_WS1 wait_timer: 26.01.2016 13:54:43 cmd_1 WS3
2016-01-26 13:54:33 CUL_WS WS3 T: 23.0 H: 0
2016-01-26 13:54:33 CUL_WS WS3 temperature: 23.0
2016-01-26 13:54:33 CUL_WS WS3 humidity: 0
2016-01-26 13:54:43 DOIF DOIF_lowbat_WS1 wait_timer: no timer
2016-01-26 13:54:43 dummy UEA.Batterie_niedrig DOIF_lowbat_WS1: low
2016-01-26 13:54:43 DOIF DOIF_lowbat_WS1 cmd_nr: 1
2016-01-26 13:54:43 DOIF DOIF_lowbat_WS1 cmd_event: WS3
2016-01-26 13:54:43 DOIF DOIF_lowbat_WS1 cmd_1
2. Edit:
Problem besteht in Zusammenhang mit dem Attribut wait, z.B. wait 10:0 . Damit ist das reproduzierbar. Lösche ich das Attribut, tritt das erwartete/erwünschte Verhalten ein.
ZitatAlso wird als $DEVICE nicht das triggernde Device genommen sondern das getriggerte DOIF.
Wenn eine Regexp ein Gerät und das DOIF matcht, wird das Reading "Device" und "e_regexp_c1" mit dem "falschen" Namen belegt.
$DEVICE ist mit dem Namen des triggernden Gerätes belegt.
"du" ist ein Dummy der beim Setzen ein Event erzeugt. Ich führe ein "set du x42" aus.
di DOIF (["^d.$:"]) (({Log 1, "\nDOIF di: DEVICE: $DEVICE, EVENT: $EVENT, EVENTS: $EVENTS"}))Mit einem notify schreibe ich die Events des DOIF mit
notify di {Log 1, "notify $NAME: $EVENT"}Logeintrag:
Zitat
2016.01.26 14:16:03 1: DOIF di: DEVICE: du, EVENT: x42, EVENTS: x42
2016.01.26 14:16:03 1: notify di: cmd_nr: 1
2016.01.26 14:16:03 1: notify di: cmd_event: du
2016.01.26 14:16:03 1: notify di: cmd_1
2016.01.26 14:16:03 1: notify di: Device: di
2016.01.26 14:16:03 1: notify di: e_regexp_c1: di:cmd_nr: 1 cmd_event: du cmd_1 Device: di
Müsste das Reading "Device" nicht auf "du" gesetzt werden?
Zitat von: Ellert am 26 Januar 2016, 14:28:15
Wenn eine Regexp ein Gerät und das DOIF matcht, wird das Reading "Device" und "e_regexp_c1" mit dem "falschen" Namen belegt.
$DEVICE ist mit dem Namen des triggernden Gerätes belegt.
"du" ist ein Dummy der beim Setzen ein Event erzeugt. Ich führe ein "set du x42" aus.
di DOIF (["^d.$:"]) (({Log 1, "\nDOIF di: DEVICE: $DEVICE, EVENT: $EVENT, EVENTS: $EVENTS"}))
Mit einem notify schreibe ich die Events des DOIF mit
notify di {Log 1, "notify $NAME: $EVENT"}
Logeintrag:
Müsste das Reading "Device" nicht auf "du" gesetzt werden?
Das Device- und e_regexp-Reading wird ziemlich am Anfang in der Abarbeitung innerhalb des Moduls gesetzt. Durch die Regex-Angabe triggert sich das Modul selbst. Diese Rekursion wird neuerdings im Modul abgefangen, allerdings sind zu diesem Zeitpunkt die Readings bereits gesetzt.
Ich habe schon vorher überlegt das Reading Device komplett zu entfernen, da es jetzt für die Abfragen $DEVICE gibt.
Ich müsste schauen, ob ich im Modul bereits vor dem Setzen der Readings die Rekursion erkennen kann.
Gruß
Damian
Version 0.6 im ersten Post.
Diverse Korrekturen des Moduls und angepasste Doku.
Edit: In der Version 0.6 hat sich ein Initialisierungsfehler eingeschlichen - ist jetzt mit Version 0.7 behoben.
Gruß
Damian
Ich habe schon etliche Schreibweisen probiert, die richtige war aber noch nicht dabei :(.
Ich habe div. Sensoren (HM) und will NUR den State auswerten (open oder closed), leider funken mir entweder andere Readings dazwischen oder es geht gar nicht:
define DOIF ([".*\.Door$:^state$"] and [?$DEVICE] =~ "^open$|^closed$") (log $DEVICE $EVENT)
Wo ist mein dicker Denkfehler? :-[
Zitat von: Per am 28 Januar 2016, 10:33:36
Ich habe schon etliche Schreibweisen probiert, die richtige war aber noch nicht dabei :(.
Ich habe div. Sensoren (HM) und will NUR den State auswerten (open oder closed), leider funken mir entweder andere Readings dazwischen oder es geht gar nicht:
define DOIF ([".*\.Door$:^state$"] and [?$DEVICE] =~ "^open$|^closed$") (log $DEVICE $EVENT)
Wo ist mein dicker Denkfehler? :-[
Auf "state" kannst Du nicht ohne Weiteres triggern, s. http://fhem.de/commandref_DE.html#addStateEvent
Aha, danke.
Aber:
Zitat von: CommandRef■ dieses Attribut muss beim Empfänger (notify, FileLog, etc) gesetzt werden.
Und gerade bei notify funktionierte es bisher ohne :o , ich wollte ja auf DOIF umstellen.
Leider kann ich gerade nicht nachschauen, kann DOIF addStateEvent?
Zitat von: Damian am 25 Januar 2016, 11:21:34
Poste mal list deines Moduls. Aktuelle Version V 0.5 hast du schon?
Habe die 0.5 installiert gehabt und gerade nochmal mit der 0.6 getestet (inkl. shutdown restart). Funktioniert leider nicht.
Ich habe mal das List in eine Textdatei kopiert, falls Zeilenumbrüche ö.ä. relevant werden.
Zitat von: Loredo am 28 Januar 2016, 16:31:48
Habe die 0.5 installiert gehabt und gerade nochmal mit der 0.6 getestet (inkl. shutdown restart). Funktioniert leider nicht.
Ich habe mal das List in eine Textdatei kopiert, falls Zeilenumbrüche ö.ä. relevant werden.
2016-01-28 16:27:30 e_regexp_c1 rr_Julian:locationPresence: absent locationLat: xx.xxx locationLong: xx.xxxx locationAddr: Strasse 1A
Dein Event endet offenbar nicht mit "locationPresence", sondern mit "locationPresence: absent", deswegen kann es mit deiner Definition nicht funktionieren.
Deswegen solltest du eher:
["^rr_:^locationPresence"] oder ["^rr_:^locationPresence: absent"] definieren.
Gruß
Damian
Version 0.8.
$EVENT bzw. $EVENTS wird jetzt mit "timer_<nr>" belegt, wenn der Trigger vom Timer kommt.
Zitat von: Per am 28 Januar 2016, 11:49:18kann DOIF addStateEvent?
Hat es nicht.
Aber - ich habe es hinbekommen:
define DoorLog DOIF([".*\.Door$:^open$|^closed$"]) (log $DEVICE $EVENT)mit attr DoorLog do always (wg. nur einem Zustand).
Ich könnte zwar schwören, dass ich das schon mal probiert habe, aber vllt. hatte ich da auch nen Tippfehler dabei. Oder das "do always" vergessen. Egal, jetzt geht es :D.
Version 0.9
1) Events werden jetzt in $EVENTS nicht mit Leerzeichen, sondern mit Komma getrennt dargestellt. Damit kann man einzelne Ereignisse eines Triggers besser auseinander halten.
2) Bisherige Angabe für Event-Trigger [<Device>:?<Regex für Event>] lässt sich jetzt auch wie folgt angeben [<Device>:"<Regex für Event>"]
Damit wird zum Einen die neue Syntax (Regex in Anführungszeichen) vereinheitlicht zum Anderen ist das Fragezeichen an dieser Stelle immer etwas verwirrend gewesen, da es ja auch ein Fragezeichen für "nicht triggern" vor einem Device gibt. Die bisherige Syntax bleibt natürlich aus Kompatibilitätsgründen bestehen.
Gruß
Damian
Neue Version wurde eingecheckt.
Ab morgen per Update verfügbar.
Gruß
Damian
Zitat von: Damian am 28 Januar 2016, 17:29:46
Dein Event endet offenbar nicht mit "locationPresence", sondern mit "locationPresence: absent", deswegen kann es mit deiner Definition nicht funktionieren.
Hm, ok. Finde ich etwas verwirrend, dass das Regex auf einen langen state-ähnlichen String angewendet wird. Intuitiv hätte ich eher erwartet, dass pro Event das Regex ausgewertet wird und nicht zunächst aus allen Events ein langer String gebildet wird. Das ist definitiv ein großer Unterschied zu dem wie man ansonsten in FHEM mit Events umgeht. Hat das Performancegründe oder weshalb hast du dich dafür entschieden? Was hat es da mit der Trennung per , im Reading jetzt aufsich?
Zitat von: Loredo am 31 Januar 2016, 15:37:09
Hm, ok. Finde ich etwas verwirrend, dass das Regex auf einen langen state-ähnlichen String angewendet wird. Intuitiv hätte ich eher erwartet, dass pro Event das Regex ausgewertet wird und nicht zunächst aus allen Events ein langer String gebildet wird. Das ist definitiv ein großer Unterschied zu dem wie man ansonsten in FHEM mit Events umgeht. Hat das Performancegründe oder weshalb hast du dich dafür entschieden? Was hat es da mit der Trennung per , im Reading jetzt aufsich?
Es wird wie beim Notify
jede Eventzeile einzeln ausgewertet. Alle Events eines Triggers werden nur zur Information in einer Zeile dargestellt.
Gruß
Damian
Sehr gut, dann ist das doch so wie ich zunächst annahm.
Hatte mich zuerst gefragt weshalb ^locationPresence$ als Trigger nicht funktioniert. Mein Denkfehler war dabei, dass ich Reading und Value bei einem Event immer getrennt betrachte und es irgendwie nicht in meinen Schädel geht, dass das zusammen gehört...
Denke nun ist alles klar, danke ;)
Zitat von: Loredo am 31 Januar 2016, 17:14:31
Sehr gut, dann ist das doch so wie ich zunächst annahm.
Hatte mich zuerst gefragt weshalb ^locationPresence$ als Trigger nicht funktioniert. Mein Denkfehler war dabei, dass ich Reading und Value bei einem Event immer getrennt betrachte und es irgendwie nicht in meinen Schädel geht, dass das zusammen gehört...
Denke nun ist alles klar, danke ;)
Am besten nimmst du auch die aktuelle Version, die ich gestern eingecheckt habe. Ich habe noch an einigen Sachen gedreht.
Insbesondere heißt das neue Reading für die neue Regex-Syntax: "matched_event...", dort wird auch nur das Event angezeigt, was tatsächlich "gematched" hat.
Was man allerdings wissen sollte:
In einem Punkt unterscheidet sich funktionsbedingt die Vorgehensweise im Vergleich zu Notify. Im DOIF-Modul kann innerhalb eines Triggers höchstens nur eine Eventzeile "zutreffen" und nicht mehr.
Beispiel:
mit
DOIF ([""]) ({Log 3, "$EVENT"}) wird man nicht alle Events loggen, sondern nur jeweils die erste Eventzeile eines Triggers.
mit
DOIF ([""]) ({Log 3, "$EVENTS"}) werden dagegen alle Events dargestellt, allerdings pro Trigger alle in einer Zeile mit Komma getrennt.
Gruß
Damian
Zitat von: Damian am 31 Januar 2016, 17:42:58
Am besten nimmst du auch die aktuelle Version, die ich gestern eingecheckt habe. Ich habe noch an einigen Sachen gedreht.
Insbesondere heißt das neue Reading für die neue Regex-Syntax: "matched_event...", dort wird auch nur das Event angezeigt, was tatsächlich "gematched" hat.
Ja hab ich gesehen. Macht absolut Sinn und ist extrem benutzerfreundlich so ;)
Zitat von: Damian am 31 Januar 2016, 17:42:58
Was man allerdings wissen sollte:
Ja das sind gute Hinweise. Einer wäre vermutlich noch, dass man nur einen einzigen Regex-Trigger gleichzeitig anwenden kann bzw. dass mehrere Regex-Trigger durch "and" verknüpft keinen Sinn machen, höchstens mit "or". Richtig?
Zitat von: Loredo am 31 Januar 2016, 17:48:01
Ja das sind gute Hinweise. Einer wäre vermutlich noch, dass man nur einen einzigen Regex-Trigger gleichzeitig anwenden kann bzw. dass mehrere Regex-Trigger durch "and" verknüpft keinen Sinn machen, höchstens mit "or". Richtig?
ja, im Normalfall ja, es sei denn beide Regex-Angaben finden jeweils einen Treffen innerhalb der Eventzeilen
eines Triggers - das wird allerdings normalerweise weniger interessant sein.
Zitat von: Damian am 30 Januar 2016, 23:28:47
Neue Version wurde eingecheckt.
Ab morgen per Update verfügbar.
Gruß
Damian
Bombe, vielen Dank dafür! Ich glaube nun haben wir alle Funktionen die benötigt werden! Danke Damian!
Zitat von: P.A.Trick am 02 Februar 2016, 23:09:23
Bombe, vielen Dank dafür! Ich glaube nun haben wir alle Funktionen die benötigt werden! Danke Damian!
Noch nicht alle ;)
Es sollen noch Datumsangaben hinzukommen z. B. [2015-10-30 10:00] oder ähnlich.
Gruß
Damian
Zitat von: Damian am 03 Februar 2016, 08:46:40
Noch nicht alle ;)
Wenn wir schon am träumen sind... :)
Wir wäre es mit einer (einfachen) Verschachtelung von IFs ,ähnlich zu
(set lg_light on [DOIFsub $EVENT eq "TEMPL"])
oder gar
DOIF ([winter])
(set desired-temp 18 )
CASE ([light] eq "on")
(set xyy)
CASE ([garage] eq "offen")
(set xyyZZ)
CASEEND
DOELSEIF ([sommer])
(set desired-temp off )
Zum Hintergrund:
Ich habe in ein großes DOIF mit sehr vielen (set ...) Einträgen, manche haben aber bestimmte Bedingungen wie Lichteinfall, etc.
Mit reinen DOELSEIF ist das schwierig, mit notify auch ;-). Das alles in eigene DOIFS zu ziehen wird unübersichtlich...
Aber wie gesagt, nur ein Traum... vielen Dank für die tolle Arbeit!
Zitat von: P.A.Trick am 02 Februar 2016, 23:09:23Ich glaube nun haben wir alle Funktionen die benötigt werden!
Ich ich hätte da auch noch Ideen (http://forum.fhem.de/index.php/topic,47979.msg396361.html#msg396361).
@JoeALLb: ich könnte mir vorstellen dass sich mit "?:" da was basteln lässt...
http://forum.fhem.de/index.php/topic,48364.msg402589.html#msg402589 (http://forum.fhem.de/index.php/topic,48364.msg402589.html#msg402589)
Ich versuche gerade ein DOIF zu definieren mit
define doif DOIF ([Test:"test: "])
da kommt eine Fehlermeldung: DOIF: unknown expression format: ". Es liegt am Doppelpunkt in "test: ".
Ist der Doppelpunkt als Zeichen nicht erlaubt? Ich dachte in der neuen DOIF Version ist er erlaubt.
Ideen sind natürlich immer willkommen. Zu bedenken ist allerdings immer, das Modul nicht unnötig komplizierter zu machen als es schon ist. Manche Sachen lassen sich leicht einbauen, Manche Sachen würde man wieder gerne herausnehmen, weil sie im Nachhinein Verwirrung stiften. Dann gibt es das Problem der verfügbaren Programmierzeit. Und es gibt Dinge, die der Anwender zunächst nicht sieht, aber auf meiner Liste ganz oben stehen:
1. Nur ein Trigger bei gleichen Zeiten -> damit wird die Reihenfolge der Abarbeitung gewährleistet (ist zur Zeit nicht der Fall)
2. Setzen der Anfangszeit eines Zeitintervalls erst beim End-Trigger des Intervalls -> damit würde man bei Zeitintervallen nicht mehrfach triggern, wenn die neue Zeit sich noch innerhalb des alten Intervalls befindet z. B. [([10:00]+rand(120)) - 12:00]
Es gibt also genug zu tun. Es lebe der Karneval und die Zeit zum Programmieren ;)
Gruß
Damian
Zitat von: Ellert am 03 Februar 2016, 10:15:41
Ich versuche gerade ein DOIF zu definieren mit
define doif DOIF ([Test:"test: "])
da kommt eine Fehlermeldung: DOIF: unknown expression format: ". Es liegt am Doppelpunkt in "test: ".
Ist der Doppelpunkt als Zeichen nicht erlaubt? Ich dachte in der neuen DOIF Version ist er erlaubt.
ja, bei
(["Test:test: "]) habe ich es schon berücksichtigt, in dem anderen Fall wohl noch nicht.
Zitat von: JoeALLb am 03 Februar 2016, 09:25:08
Wenn wir schon am träumen sind... :)
Wir wäre es mit einer (einfachen) Verschachtelung von IFs ,ähnlich zu
(set lg_light on [DOIFsub $EVENT eq "TEMPL"])
oder gar
DOIF ([winter])
(set desired-temp 18 )
CASE ([light] eq "on")
(set xyy)
CASE ([garage] eq "offen")
(set xyyZZ)
CASEEND
DOELSEIF ([sommer])
(set desired-temp off )
Zum Hintergrund:
Ich habe in ein großes DOIF mit sehr vielen (set ...) Einträgen, manche haben aber bestimmte Bedingungen wie Lichteinfall, etc.
Mit reinen DOELSEIF ist das schwierig, mit notify auch ;-). Das alles in eigene DOIFS zu ziehen wird unübersichtlich...
Aber wie gesagt, nur ein Traum... vielen Dank für die tolle Arbeit!
Das geht schon:
DOIF ([winter])
(set desired-temp 18,
IF ([light] eq "on")
(set xyy),
IF ([garage] eq "offen")
(set xyyZZ))
DOELSEIF ([sommer])
(set desired-temp off )
Zitat von: Ellert am 03 Februar 2016, 10:30:56
Das geht schon:
VIELEN Dank!!! Das war mich echt nicht bewußt, und ich habe schon einiges darüber gesucht...
Auch aus der commandref kann ich das nicht herauslesen?!?
Beiträgen wie diese führten mich auch nicht weiter http://forum.fhem.de/index.php?topic=34935.0!!
Wie auch immer, VIELEN DANK!!! Mein Tag ist gerettet.
Zitat von: JoeALLb am 03 Februar 2016, 10:46:40
VIELEN Dank!!! Das war mich echt nicht bewußt, und ich habe schon einiges darüber gesucht...
Auch aus der commandref kann ich das nicht herauslesen?!?
Beiträgen wie diese führten mich auch nicht weiter http://forum.fhem.de/index.php?topic=34935.0!!
Wie auch immer, VIELEN DANK!!! Mein Tag ist gerettet.
Im Nachhinein denke ich, es hat nicht die gewünschte Funktionalität, denn IF ([ABC] eq "xyz") triggert nicht, es ist ein FHEM-Befehl, s. http://fhem.de/commandref_DE.html#IF
Zitat von: JoeALLb am 03 Februar 2016, 09:25:08
Wenn wir schon am träumen sind... :)
Wir wäre es mit einer (einfachen) Verschachtelung von IFs ,ähnlich zu
(set lg_light on [DOIFsub $EVENT eq "TEMPL"])
oder gar
DOIF ([winter])
(set desired-temp 18 )
CASE ([light] eq "on")
(set xyy)
CASE ([garage] eq "offen")
(set xyyZZ)
CASEEND
DOELSEIF ([sommer])
(set desired-temp off )
Zum Hintergrund:
Ich habe in ein großes DOIF mit sehr vielen (set ...) Einträgen, manche haben aber bestimmte Bedingungen wie Lichteinfall, etc.
Mit reinen DOELSEIF ist das schwierig, mit notify auch ;-). Das alles in eigene DOIFS zu ziehen wird unübersichtlich...
Aber wie gesagt, nur ein Traum... vielen Dank für die tolle Arbeit!
Es ist auch nicht klar, ob der CASE-Fall ohne Winter-Trigger ausgewertet werden soll oder nicht, auf der anderen Seite kann Winter und light nicht gleichzeitig triggern. Mit anderen Worten, wenn man sich eine Syntax überlegt, dann muss man auch alle Eventualitäten berücksichtigen.
Man könnte auch definieren:
DOIF ([winter] or [light] or [garage])
(set desired-temp 18,
IF ([light] eq "on")
(set xyy),
IF ([garage] eq "offen")
(set xyyZZ))
DOELSEIF ([sommer])
(set desired-temp off )Es gibt also auch jetzt schon vielfältige Möglichkeiten seine Wünsche umzusetzen.
Gruß
Damian
Zitat von: Damian am 03 Februar 2016, 13:21:48 DOIF ([winter] or [light] or [garage])
Sollte es nicht ([winter] and ([light] or [garage])) sein? Zumindest passend zur angegebenen Aufgabenstellung.
Zitat von: Per am 03 Februar 2016, 14:56:25
Sollte es nicht ([winter] and ([light] or [garage])) sein? Zumindest passend zur angegebenen Aufgabenstellung.
Nein, es geht hier nur um den Trigger, der Inhalt der Variablen ist egal und normalerweise immer wahr, weil ungleich "".
Zitat von: Damian am 03 Februar 2016, 15:32:17Nein, es geht hier nur um den Trigger
:-[ Danke!
Zitat von: Damian am 03 Februar 2016, 10:19:37
ja, bei
(["Test:test: "])
habe ich es schon berücksichtigt, in dem anderen Fall wohl noch nicht.
([Test:"test: "])funktioniert ab morgen auch.
Gruß
Damian
Danke, ich konnte es im Wirkbetrieb gleich anwenden.
Zitat von: JoeALLb am 03 Februar 2016, 09:25:08
Wenn wir schon am träumen sind... :)
Wir wäre es mit einer (einfachen) Verschachtelung von IFs ,ähnlich zu
(set lg_light on [DOIFsub $EVENT eq "TEMPL"])
oder gar
DOIF ([winter])
(set desired-temp 18 )
CASE ([light] eq "on")
(set xyy)
CASE ([garage] eq "offen")
(set xyyZZ)
CASEEND
DOELSEIF ([sommer])
(set desired-temp off )
Zum Hintergrund:
Ich habe in ein großes DOIF mit sehr vielen (set ...) Einträgen, manche haben aber bestimmte Bedingungen wie Lichteinfall, etc.
Mit reinen DOELSEIF ist das schwierig, mit notify auch ;-). Das alles in eigene DOIFS zu ziehen wird unübersichtlich...
Aber wie gesagt, nur ein Traum... vielen Dank für die tolle Arbeit!
Hallo,
Für weitergehende Verarbeitungen in Form von Abfragen kannst Du ja eine 99_myUtils anlegen. Nur so eine Idee.
Grüße
Hallo Damian,
ich bin gerade dabei mit der neuen Version eine Fenster-offen-Meldung zu basteln.
Das geht auch gut los. Allerdings wollte ich nicht immer die gleiche Meldung versenden, sondern je nach Relation von Innen- zu Außentemperatur verschiedene (im Sommer ist ein offenes Fenster nur beim Verlassen des Hauses wichtig, im Winter wird es halt auch kalt im Raum).
Deshalb brauche ich z.B. folgende Bedingung (altes Format für einen festen Raum/Fensterkontakt, ist jetzt nur exemplarisch eine Bedingung des ganzen Konstrukts):
[code]
([heizung_Schlafzimmer_FK_Links] eq open and [aussen_Temperatur:temperature] >= [heizung_Schlafzimmer_WT:desiredTemperatureWeekprofile]) ((
set telegram message
Zitat von: Reinerlein am 04 Februar 2016, 14:32:07
Hallo Damian,
ich bin gerade dabei mit der neuen Version eine Fenster-offen-Meldung zu basteln.
Das geht auch gut los. Allerdings wollte ich nicht immer die gleiche Meldung versenden, sondern je nach Relation von Innen- zu Außentemperatur verschiedene (im Sommer ist ein offenes Fenster nur beim Verlassen des Hauses wichtig, im Winter wird es halt auch kalt im Raum).
Deshalb brauche ich z.B. folgende Bedingung (altes Format für einen festen Raum/Fensterkontakt, ist jetzt nur exemplarisch eine Bedingung des ganzen Konstrukts):
([heizung_Schlafzimmer_FK_Links] eq open and [aussen_Temperatur:temperature] >= [heizung_Schlafzimmer_WT:desiredTemperatureWeekprofile]) ((
set telegram message
Zuerst würde ich mir ein Konzept für die Namensgebung machen: z. B. Kontakt: "Heizung_Schlafzimmer" und WT´s "WT_<Kontaktname>" hier dann "WT_Heizung_Schlafzimmer", ansonsten musst du irgendwo eine Abbildung vom Kontakt zum WT über readings, dummys etc. machen. Dann einfach definieren:
(["^Heizung_:open"] and [aussen_Temperatur:temperature] >= [^WT_$DEVICE:desiredTemperatureWeekprofile]) (set telegram message Fenster $DEVICE offen)Gruß
Damian
Hi Damian,
die ganzen Komponenten folgen schon einer Namenskonvention, nur andersherum, sprich die Komponenten werden hinten beschrieben, und die Räume vorne nach dem Schlüsselwort "heizung_".
Da das an vielen anderen Stellen schon berücksichtigt wird, kann ich das jetzt nicht mehr verändern...
Aber du erwähntest die Möglichkeit der Verbindung über ein Reading o.ä..
Wenn ich also im Fensterkontakt ein Reading hinterlegen würde, welches auf das Wandthermostat verweist. z.B.:
setreading heizung_Schlafzimmer_FK_Links associatedWT heizung_Schlafzimmer_WT
Danke für deine Hilfe...
Grüße
Reiner
Zitat von: Reinerlein am 04 Februar 2016, 15:05:07
Hi Damian,
die ganzen Komponenten folgen schon einer Namenskonvention, nur andersherum, sprich die Komponenten werden hinten beschrieben, und die Räume vorne nach dem Schlüsselwort "heizung_".
Da das an vielen anderen Stellen schon berücksichtigt wird, kann ich das jetzt nicht mehr verändern...
Aber du erwähntest die Möglichkeit der Verbindung über ein Reading o.ä..
Wenn ich also im Fensterkontakt ein Reading hinterlegen würde, welches auf das Wandthermostat verweist. z.B.:
setreading heizung_Schlafzimmer_FK_Links associatedWT heizung_Schlafzimmer_WT
Danke für deine Hilfe...
Grüße
Reiner
Ich sehe gerade, dass mein Ansatz vermutlich deinen Anforderungen nicht entsprechen würde, weil du ja insb. eine Meldung haben willst, wenn das Fenster bereits geöffnet ist und dann die Temperaturdifferenz zuschlägt. Das ist dann nicht mehr so einfach, weil der Trigger die Aussentemperatur ist und nicht das Fenster. Daher ist $DEVICE-Abfrage nicht möglich, weil $DEVICE der aussen_temp-Sensor ist. Da fällt mir auf Anhieb keine generalisierte Lösung ein. Vielleicht hat ein anderer DOIF-Experte einen Generalisierungsvorschlag parat.
Gruß
Damian
Hi Damian,
vielleicht könnte die Variable $device nur bei variablen Deviceangaben mit "" gefüllt werden.
Oder es gibt mehrere Device-Variablen, für jede Deviceangabe in der Bedingung eine (irgendwie durchnummeriert oder so)...
Letztendlich, wenn man seine Notifys großflächig durch Doifs ersetzen möchte, wird man öfter an so etwas geraten:
Man stellt Bedingungen aus mehreren Deviceinformationen zusammen, die gemeinsam in einem Resultat (bzw. einem Zustand) enden. Das ist ja auch genau die Stärke und Übersichtlichkeit von Doif...
In einem Notify baut man das ja zu dem Trigger selbst in den Code als zusätzliche If-Bedingung ein...
Momentan hat die Variable $device eher die Bedeutung von $triggerdevice. In meinem Fall bräuchte ich aber das Device der ersten Teilbedingung (die ja variabel ist). Hier wäre es egal, warum oder von wem eine Bedingung getriggert wurde, sondern nur der (Gesamt-)Zustand als solches (im Sinne einer zutreffenden Summe aller Bedingungen der Doif-Zeile) ist wichtig.
In meinem jetzigen Fall wären die anderen Devices egal, kann aber natürlich in einem anderen Fall auch mal anders sein...
Momentan wäre es mir noch nichtmal wichtig, dass nachträglich durch die gesunkene Temperatur getriggert würde... Da reicht mir die Aussage zum Zeitpunkt der Fensteröffnung.
Könnte man das denn jetzt schon erreichen?
Danke schonmal, trotz der komplizierten Lage :)
Grüße
Reiner
Zitat von: Reinerlein am 04 Februar 2016, 16:41:05
In meinem Fall bräuchte ich aber das Device der ersten Teilbedingung (die ja variabel ist).
Das ist aber nicht bekannt, wenn der Trigger von einem anderen Device kommt.
Ich habe mich lange gewährt diese Generalisierung a la notify einzubauen. Es gibt ja auch nicht umsonst keine Bezeichner (Variablen etc.) in höheren Sprachen, die man mit * verallgemeinern könnte.
Alternative mit angesprochener Einschränkung:
(["^Heizung_:open"] and [?aussen_Temperatur:temperature] >= [$DEVICE:associatedWT]) (set telegram message Fenster $DEVICE offen)
Das Reading associatedWT müsste immer das aktuelle desiredTemperatureWeekprofile haben. Das könnte man mit einem anderen DOIF aktualisieren.
Hi Damian,
ah... ich dachte man könnte als Reading einen Verweis auf das andere Device angeben (deswegen ja auch der Name associatedWT)...
hmmm... da muss ich jetzt mal in mich gehen, und eine Entscheidung treffen, ob ich für jeden Fensterkontakt doch ein konkretes Doif anlege, oder ob ich es doch über ein Notify löse... beides hat da Vor- und Nachteile...
Trotzdem Danke für deine Mühen.
Noch zu den *-Variablen: Natürlich gibt es sowas in höheren Programmiersprachen. Mittels Klassenstrukturen (bzw. deren Objekten zur Laufzeit) und Referenzen kannst du natürlich genau sowas hinbekommen.
Deswegen hatte ich mich schon gewundert, wie du die Generalisierung ohne Objekte (die es in Fhem ja nicht gibt) hingebogen hast. Dafür müsstest du ja schließlich bei jedem Event die entsprechende Ausprägung des damaligen kompletten Doif wiederherstellen können, um an der Stelle weitermachen zu können, wo das letzte mal bei der Eventausführung aufgehört wurde.
Man könnte natürlich ein Reading im Doif ablegen, welches für jedes gefundene Device den kompletten Doif-Zustand (die alten Werte bei den Bedingungen und den Cmd-Zustand) serialisiert ablegt. Das wird aber extrem unübersichtlich und sollte man wohl eher lassen :)
Oder man baut sowas wie einen Laufzeit-DOIF-Generator: Wenn man ein generisches Doif mit Platzhalter definiert hat, und es kommt ein Event, was passt, erzeugt man flugs eine temporäre Kopie des generischen DOIF bei dem alle erkannten Platzhalter (die ja auf dieses Event passen müssten) konkretisiert werden, sodass da wieder ein Standard-DOIF existiert, welches genau für dieses Event passt, und nun erstmal lebt und seine Arbeit macht :)
Sorry für diesen Erguss... ich finde das Modul großartig und finde es immer Schade, wenn man dann an Grenzen stößt...
Grüße
Reiner
Zitat von: Reinerlein am 04 Februar 2016, 21:59:32
Hi Damian,
ah... ich dachte man könnte als Reading einen Verweis auf das andere Device angeben (deswegen ja auch der Name associatedWT)...
[[[[[..]]]]] geht noch nicht.
Zitat
Noch zu den *-Variablen: Natürlich gibt es sowas in höheren Programmiersprachen. Mittels Klassenstrukturen (bzw. deren Objekten zur Laufzeit) und Referenzen kannst du natürlich genau sowas hinbekommen.
Deswegen hatte ich mich schon gewundert, wie du die Generalisierung ohne Objekte (die es in Fhem ja nicht gibt) hingebogen hast. Dafür müsstest du ja schließlich bei jedem Event die entsprechende Ausprägung des damaligen kompletten Doif wiederherstellen können, um an der Stelle weitermachen zu können, wo das letzte mal bei der Eventausführung aufgehört wurde.
Man könnte natürlich ein Reading im Doif ablegen, welches für jedes gefundene Device den kompletten Doif-Zustand (die alten Werte bei den Bedingungen und den Cmd-Zustand) serialisiert ablegt. Das wird aber extrem unübersichtlich und sollte man wohl eher lassen :)
Oder man baut sowas wie einen Laufzeit-DOIF-Generator: Wenn man ein generisches Doif mit Platzhalter definiert hat, und es kommt ein Event, was passt, erzeugt man flugs eine temporäre Kopie des generischen DOIF bei dem alle erkannten Platzhalter (die ja auf dieses Event passen müssten) konkretisiert werden, sodass da wieder ein Standard-DOIF existiert, welches genau für dieses Event passt, und nun erstmal lebt und seine Arbeit macht :)
Tja, FHEM ist nun mal nicht objektorientiert, sondern prozedural programmiert, daher muss man schon in dieser Welt bleiben. Der Begriff Generalisierung ist sicherlich hier nicht ganz richtig und stand entfremdet für die Möglichkeit verschiedene Devices mit einer Abfrage zu erschlagen, allerdings mit den Einschränkungen, die sich aus der Welt ohne dynamische Objekte ergeben.
Also schauen wir mal, was sich noch mit vertretbaren Programmieraufwand an Möglichkeiten im Sinne der "Generalisierung" für den FHEM-User ergibt.
Gruß
Damian
Hi Damian,
ich habe mich jetzt für einen eigenen Generator auf Basis einer Kopiervorlage (ein Deaktivierter DOIF mit Platzhaltern, die beim Erzeugen des Ziel-DOIFs ersetzt werden) entschieden.
Nun habe ich mein komplettes DOIF fertig, aber das Problem, dass es nicht auslöst. Wenn ich das Fenster öffne, steht für eine kurze Weile im Reading "wait_timer" der korrekte Auslösezeitpunkt (verzögert), mit dem korrekten Zielzustand (in dem Fall unten wurde auf cmd2 verwiesen).
Dann aber verschwindet dieses Reading "wait_timer" vor Ablauf, und er ändert auch nicht den Zustand des DOIFs, obwohl die Bedingungen immer noch stimmen (wie man am Listing bei den erkannten Werten in den Readings auch sehen kann).
Dann wird der "wait_timer" irgendwann wieder gesetzt (das war in diesem Beispiel also zwischen normaler Anzeige des DOIFs und dem Anzeigen per "list"), startet aber natürlich wieder von vorne.
Das geht so weiter, ohne das jemals ein anderer Zustand erreicht wird . Was für eine Offen-Meldung natürlich nicht so praktisch ist :)
[code]
Internals:
CFGFN
DEF ([heizung_Schlafzimmer_FK_Links] eq "opened" and [aussen_Temperatur:temperature] >= [heizung_Schlafzimmer_WT:desiredTemperatureWeekprofile]) ((
set telegram message
Zitat von: Reinerlein am 06 Februar 2016, 11:36:37
Hi Damian,
ich habe mich jetzt für einen eigenen Generator auf Basis einer Kopiervorlage (ein Deaktivierter DOIF mit Platzhaltern, die beim Erzeugen des Ziel-DOIFs ersetzt werden) entschieden.
Nun habe ich mein komplettes DOIF fertig, aber das Problem, dass es nicht auslöst. Wenn ich das Fenster öffne, steht für eine kurze Weile im Reading "wait_timer" der korrekte Auslösezeitpunkt (verzögert), mit dem korrekten Zielzustand (in dem Fall unten wurde auf cmd2 verwiesen).
Dann aber verschwindet dieses Reading "wait_timer" vor Ablauf, und er ändert auch nicht den Zustand des DOIFs, obwohl die Bedingungen immer noch stimmen (wie man am Listing bei den erkannten Werten in den Readings auch sehen kann).
Dann wird der "wait_timer" irgendwann wieder gesetzt (das war in diesem Beispiel also zwischen normaler Anzeige des DOIFs und dem Anzeigen per "list"), startet aber natürlich wieder von vorne.
Das geht so weiter, ohne das jemals ein anderer Zustand erreicht wird . Was für eine Offen-Meldung natürlich nicht so praktisch ist :)
Internals:
CFGFN
DEF ([heizung_Schlafzimmer_FK_Links] eq "opened" and [aussen_Temperatur:temperature] >= [heizung_Schlafzimmer_WT:desiredTemperatureWeekprofile]) ((
set telegram message
Der wait_timer wird immer dann gelöscht, wenn während der Wartezeit ein Trigger kommt, aufgrund dessen wieder der ursprünglicher Zustand erreicht wird.
Bsp.:
aktueller Zustand: cmd_1
Trigger (Bedingung für cmd_2 erfüllt) -> wait_timer für cmd_2
Trigger während der Wartezeit (Bedingung für cmd_1 erfüllt) wait_timer gelöscht, da man ja noch in cmd_1 ist.
Gruß
Damian
Hallo Damian,
ich habe die aktuelle DOIF-Version 2016-02-03 mal testweise aktiviert. Laut Beschreibung sollte ja die alte Event-Notation [<device>:?<event>] weiterhin verwendet werden können.
Bei meiner Trigger-Bedingung 'DOIF ([S0count:?Counter])' erhalte ich nun aber folgende Fehlermeldung:
2016-02-06 20:52:09 DOIF S0proc error: perl error in condition: EventDoIf('S0count',$hash->{helper}{triggerDev},$hash->{helper}{triggerEvents},'Counter'): Can't use string ("S0count") as a HASH ref while "strict refs" in use at ./FHEM/98_DOIF.pm line 141, line 172.
Hallo Damian,
das ist mir klar. Deshalb verwendet man ja ein DOIF. Nur hat sich bei mir nichts an den Bedingungen (bzw. den Werten dazu) geändert. Nach den Werten der Readings und des States müsste er in den Zustand 2 umschalten wollen. Er will aber in Zustand 4 bleiben.
Die Werte sind ja im DOIF-Listing zu erkennen, diese verändern sich nicht so stark, dass ein anderer Zustand eintreten müsste.
Es scheint so, als ob er irgendwie ein Event feststellt (der Temperatursensor liefert z.B. alle 5 Minuten einen neuen Wert und damit ein Event), und dabei den ursprünglichen Plan mit dem Umschalten auf Zustand 2 vergisst, obwohl alle Bedingungen noch passend dafür sind...
Um in Zustand 4 zu bleiben müsste ja der Fensterkontakt ein "closed" melden, dass passiert jedoch nachweislich nicht. Bei den anderen Werten könnten nur noch die Zustände 1 bis 3 eintreten. Er versucht aber kurz danach wieder in den Zustand 2 zu wechseln (nur dass dann der Timer halt neugestartet wurde), er stellt also die korrekten Werte fest...
Grüße
Reiner
Zitat von: Reinerlein am 06 Februar 2016, 21:55:19
Hallo Damian,
das ist mir klar. Deshalb verwendet man ja ein DOIF. Nur hat sich bei mir nichts an den Bedingungen (bzw. den Werten dazu) geändert. Nach den Werten der Readings und des States müsste er in den Zustand 2 umschalten wollen. Er will aber in Zustand 4 bleiben.
Die Werte sind ja im DOIF-Listing zu erkennen, diese verändern sich nicht so stark, dass ein anderer Zustand eintreten müsste.
Es scheint so, als ob er irgendwie ein Event feststellt (der Temperatursensor liefert z.B. alle 5 Minuten einen neuen Wert und damit ein Event), und dabei den ursprünglichen Plan mit dem Umschalten auf Zustand 2 vergisst, obwohl alle Bedingungen noch passend dafür sind...
Um in Zustand 4 zu bleiben müsste ja der Fensterkontakt ein "closed" melden, dass passiert jedoch nachweislich nicht. Bei den anderen Werten könnten nur noch die Zustände 1 bis 3 eintreten. Er versucht aber kurz danach wieder in den Zustand 2 zu wechseln (nur dass dann der Timer halt neugestartet wurde), er stellt also die korrekten Werte fest...
Grüße
Reiner
Poste mal list von dem Modul kurz nach dem wait_timer gelöscht wird.
Zitat von: crusader am 06 Februar 2016, 21:18:40
Hallo Damian,
ich habe die aktuelle DOIF-Version 2016-02-03 mal testweise aktiviert. Laut Beschreibung sollte ja die alte Event-Notation [<device>:?<event>] weiterhin verwendet werden können.
Bei meiner Trigger-Bedingung 'DOIF ([S0count:?Counter])' erhalte ich nun aber folgende Fehlermeldung:
2016-02-06 20:52:09 DOIF S0proc error: perl error in condition: EventDoIf('S0count',$hash->{helper}{triggerDev},$hash->{helper}{triggerEvents},'Counter'): Can't use string ("S0count") as a HASH ref while "strict refs" in use at ./FHEM/98_DOIF.pm line 141, line 172.
Hast du das System für die neue Version neu gestartet?
Zitat von: Damian am 06 Februar 2016, 22:07:51
Hast du das System für die neue Version neu gestartet?
Soeben probiert.
Fehlermeldung taucht dann nicht mehr auf.
Danke!
Hallo Damian,
gerade mal provoziert:
Internals:
DEF ([heizung_Schlafzimmer_FK_Links] eq "opened" and [aussen_Temperatur:temperature] >= [heizung_Schlafzimmer_WT:desiredTemperatureWeekprofile]) ((
set telegram message Du hast vergessen das Fenster "Schlafzimmer FK Links" zu schließen, es ist aussen aber warm genug.
)) DOELSEIF ([heizung_Schlafzimmer_FK_Links] eq "opened" and [heizung_Schlafzimmer_WT:temperature] >= [heizung_Schlafzimmer_WT:desiredTemperatureWeekprofile]) ((
set telegram message Du hast vergessen das Fenster "Schlafzimmer FK Links" zu schließen, es ist innen aber warm genug.
)) DOELSEIF ([heizung_Schlafzimmer_FK_Links] eq "opened") ({
my $duration = ReadingsVal("heizung_Schlafzimmer_FK_Links", 'stateChanged', '');;
$duration = (time() - SONOS_GetTimeFromString($1)) if ($duration =~ m/.*\|(.*)/);;
fhem("set telegram message Du hast vergessen das Fenster \"Schlafzimmer FK Links\" zu schließen.\nEs ist seit ".(FormatDauer($duration))
." geöffnet, und es sind nun ".ReadingsVal("heizung_Schlafzimmer_WT", 'temperature', '-')."°C in dem Raum (anstatt der gewünschten "
.ReadingsVal("heizung_Schlafzimmer_WT", 'desiredTemperatureWeekprofile', '-')."°C).")
}) DOELSE ({
sendPlot("heizung_Schlafzimmer_Plot", 'Das Fenster "Schlafzimmer FK Links" wurde wieder geschlossen!')
})
NAME heizung_FTK_Mailer_Schlafzimmer_FK_Links
NR 1613
NTFY_ORDER 50-heizung_FTK_Mailer_Schlafzimmer_FK_Links
STATE Geschlossen gemeldet
TYPE DOIF
Readings:
2016-02-06 23:25:56 Device aussen_Temperatur
2016-02-04 23:29:44 cmd_event heizung_Schlafzimmer_WT
2016-02-04 23:29:44 cmd_nr 4
2016-02-06 23:25:56 e_aussen_Temperatur_temperature 5.3125
2016-02-06 23:12:25 e_heizung_Schlafzimmer_FK_Links_STATE opened
2016-02-06 23:24:09 e_heizung_Schlafzimmer_WT_desiredTemperatureWeekprofile 16.5
2016-02-06 23:24:09 e_heizung_Schlafzimmer_WT_temperature 16.5
2016-02-04 23:29:44 state Geschlossen gemeldet
2016-02-06 23:25:56 wait_timer no timer
Condition:
0 InternalDoIf('heizung_Schlafzimmer_FK_Links','STATE','',AttrVal($hash->{NAME},'notexist',undef)) eq "opened" and ReadingValDoIf('aussen_Temperatur','temperature','',AttrVal($hash->{NAME},'notexist',undef)) >= ReadingValDoIf('heizung_Schlafzimmer_WT','desiredTemperatureWeekprofile','',AttrVal($hash->{NAME},'notexist',undef))
1 InternalDoIf('heizung_Schlafzimmer_FK_Links','STATE','',AttrVal($hash->{NAME},'notexist',undef)) eq "opened" and ReadingValDoIf('heizung_Schlafzimmer_WT','temperature','',AttrVal($hash->{NAME},'notexist',undef)) >= ReadingValDoIf('heizung_Schlafzimmer_WT','desiredTemperatureWeekprofile','',AttrVal($hash->{NAME},'notexist',undef))
2 InternalDoIf('heizung_Schlafzimmer_FK_Links','STATE','',AttrVal($hash->{NAME},'notexist',undef)) eq "opened"
Devices:
0 heizung_Schlafzimmer_FK_Links aussen_Temperatur heizung_Schlafzimmer_WT
1 heizung_Schlafzimmer_FK_Links heizung_Schlafzimmer_WT
2 heizung_Schlafzimmer_FK_Links
all heizung_Schlafzimmer_FK_Links aussen_Temperatur heizung_Schlafzimmer_WT
Do:
0:
0 ( set telegram message Du hast vergessen das Fenster "Schlafzimmer FK Links" zu schließen, es ist aussen aber warm genug.)
1:
0 ( set telegram message Du hast vergessen das Fenster "Schlafzimmer FK Links" zu schließen, es ist innen aber warm genug.)
2:
0 { my $duration = ReadingsVal("heizung_Schlafzimmer_FK_Links", 'stateChanged', '');; $duration = (time() - SONOS_GetTimeFromString($1)) if ($duration =~ m/.*\|(.*)/);; fhem("set telegram message Du hast vergessen das Fenster \"Schlafzimmer FK Links\" zu schließen.\nEs ist seit ".(FormatDauer($duration)) ." geöffnet, und es sind nun ".ReadingsVal("heizung_Schlafzimmer_WT", 'temperature', '-')."°C in dem Raum (anstatt der gewünschten " .ReadingsVal("heizung_Schlafzimmer_WT", 'desiredTemperatureWeekprofile', '-')."°C).")}
3:
0 { sendPlot("heizung_Schlafzimmer_Plot", ' Das Fenster "Schlafzimmer FK Links" wurde wieder geschlossen!')}
Helper:
event temperature: 5.3125,alarm: 0
globalinit 1
last_timer 0
sleepdevice heizung_Schlafzimmer_WT
sleepsubtimer 0
sleeptimer -1
timerdev aussen_Temperatur
timerevent temperature: 5.3125,alarm: 0
triggerDev aussen_Temperatur
timerevents:
temperature: 5.3125
alarm: 0
triggerEvents:
temperature: 5.3125
alarm: 0
Internals:
0 heizung_Schlafzimmer_FK_Links:STATE
1 heizung_Schlafzimmer_FK_Links:STATE
2 heizung_Schlafzimmer_FK_Links:STATE
all heizung_Schlafzimmer_FK_Links:STATE
Itimer:
Readings:
0 aussen_Temperatur:temperature heizung_Schlafzimmer_WT:desiredTemperatureWeekprofile
1 heizung_Schlafzimmer_WT:temperature heizung_Schlafzimmer_WT:desiredTemperatureWeekprofile
all aussen_Temperatur:temperature heizung_Schlafzimmer_WT:desiredTemperatureWeekprofile heizung_Schlafzimmer_WT:temperature
Regexp:
0:
1:
2:
All:
State:
Trigger:
Attributes:
alias Schlafzimmer FK Links FTK Mailer
cmdState Offen - Aussen warm|Offen - Innen warm|Offen gemeldet|Geschlossen gemeldet
group Heizung
icon edit_settings
repeatcmd 0:0:3600
room _Server,Heizung,Schlafzimmer
wait 1800:1800:1800
Hilft das?
Der erste Versuch kam hier nur verstümmelt an... deshalb editiert... Der kommt irgendwie mit den Unicode-Zeichen hier nicht klar...
Grüße
Reiner
Der Trigger ist der Aussensensor, die ersten beiden Bedingung sind nicht wahr, die dritte wird nicht ausgewertet, weil Aussensensor dort nicht vorkommt - es bleibt der letzte Fall übrig, daher cmd_4.
Hi Damian,
soll das bedeuten, dass sich das so korrekt verhält?
Sollte beim Auswerten der Events nicht berücksichtigt werden, was unter wait_timer vorher mal entschieden wurde? Es kann doch nicht nur das auslösende Device wichtig sein... Dann müsste man die Bedingungen ja immer vollständig aufschreiben, und die Aussage mit "die Bedingungen werden alle der Reihe nach ausgewertet" wäre dann unwichtig, da ja nur die Bedingungen berücksichtigt werden, die das Event-Device enthalten...
Ich bin mir auch irgendwie sicher, dass es mit der "alten" Version so noch ging. Dann habe ich auf die neue generalisierte Version geupdatet, und versucht, das damit umzusetzen (wie beschrieben)...
Grüße
Reiner
Zitat von: Reinerlein am 07 Februar 2016, 00:31:11
Hi Damian,
soll das bedeuten, dass sich das so korrekt verhält?
Sollte beim Auswerten der Events nicht berücksichtigt werden, was unter wait_timer vorher mal entschieden wurde? Es kann doch nicht nur das auslösende Device wichtig sein... Dann müsste man die Bedingungen ja immer vollständig aufschreiben, und die Aussage mit "die Bedingungen werden alle der Reihe nach ausgewertet" wäre dann unwichtig, da ja nur die Bedingungen berücksichtigt werden, die das Event-Device enthalten...
Ich bin mir auch irgendwie sicher, dass es mit der "alten" Version so noch ging. Dann habe ich auf die neue generalisierte Version geupdatet, und versucht, das damit umzusetzen (wie beschrieben)...
Grüße
Reiner
Das Verhalten hat sich mit der neuen Version nicht geändert. "die Bedingungen werden
alle der Reihe nach ausgewertet" ist falsch. In der Commandref steht:
ZitatZu beachten ist, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event das dazughörige Device bzw. die dazugehörige Triggerzeit beinhalten.
Vielleicht baue ich noch ein Attribut
checkall ein, da einige User danach fragten - für Nebenwirkungen bin ich dann aber nicht verantwortlich.
Gruß
Damian
Habe gerade das Problem, dass beim Einsatz von
wait für "$DEVICE $EVENT" "wait_timer: no timer" zurückgegeben wird. Werden die Werte nicht gecached?
Zitat von: Damian am 07 Februar 2016, 08:46:34Vielleicht baue ich noch ein Attribut checkall ein, da einige User danach fragten
:D
Zitat von: Per am 07 Februar 2016, 18:28:21
Habe gerade das Problem, dass beim Einsatz von wait für "$DEVICE $EVENT" "wait_timer: no timer" zurückgegeben wird. Werden die Werte nicht gecached?
:D
Ich habe das Problem nicht, es sei denn du triggerst auf dein DOIF-Modul selbst.
Hallo Damian,
ich versuche gerade $DEVICE in einem Finite-DOIF Bedingungsteil zu nutzen:
Internals:
DEF (
[":^currentAlbum.*Sprachdurchsagen"] and
[?di_HouseAnn] ne "on"
)
(
setreading HouseAnn lastDevice $DEVICE,
setreading HouseAnn:FILTER=state!=active lastState [HouseAnn:state],
set HouseAnn active,
set LR_AVR:FILTER=mute=off mute on
)
DOELSEIF
(
[":^currentAlbum"] and
[?HouseAnn:lastDevice] eq $DEVICE
[?di_HouseAnn] eq "on"
)
(
set HouseAnn [HouseAnn:lastState],
set LR_AVR:FILTER=mute=on mute off
)
DOELSE
NAME di_HouseAnn
NR 253
NTFY_ORDER 50-di_HouseAnn
STATE initialized
TYPE DOIF
Readings:
2016-02-14 18:00:27 state initialized
Condition:
0 EventDoIf('',$hash,'^currentAlbum.*Sprachdurchsagen',0) and InternalDoIf('di_HouseAnn','STATE','',AttrVal($hash->{NAME},'notexist',undef)) ne "on"
1 EventDoIf('',$hash,'^currentAlbum',0) and ReadingValDoIf('HouseAnn','lastDevice','',AttrVal($hash->{NAME},'notexist',undef)) eq $DEVICE InternalDoIf('di_HouseAnn','STATE','',AttrVal($hash->{NAME},'notexist',undef)) eq "on"
Devices:
Do:
0:
0 setreading HouseAnn lastDevice $DEVICE, setreading HouseAnn:FILTER=state!=active lastState [HouseAnn:state], set HouseAnn active, set LR_AVR:FILTER=mute=off mute on
1:
0 set HouseAnn [HouseAnn:lastState], set LR_AVR:FILTER=mute=on mute off
2:
0
Helper:
globalinit 1
last_timer 0
sleeptimer -1
Internals:
0 di_HouseAnn:STATE
1 di_HouseAnn:STATE
all di_HouseAnn:STATE
Itimer:
Readings:
1 HouseAnn:lastDevice
all HouseAnn:lastDevice
Regexp:
0:
0 :^currentAlbum.*Sprachdurchsagen
1:
0 :^currentAlbum
All:
0 :^currentAlbum.*Sprachdurchsagen
1 :^currentAlbum
State:
Attributes:
DbLogExclude .*
alias Announcement: Activity
cmdState on|off|off
devStateIcon on:general_an@green off:general_aus
event-on-change-reading state
room Apartment,Automation,Living
Es wird aber hier bei der 2. Kommando-Bedingung wohl nicht aufgelöst, weshalb ich diesen Fehler erhalte:
perl error in condition: EventDoIf('',$hash,'^currentAlbum',0) and ReadingValDoIf('HouseAnn','lastDevice','',AttrVal($hash->{NAME},'notexist',undef)) eq $DEVICE InternalDoIf('di_HouseAnn','STATE','',AttrVal($hash->{NAME},'notexist',undef)) eq "on": syntax error at (eval 84711) line 1, near "Sonos_Living_Room InternalDoIf"
Was läuft denn hier schief?
Übrigens:
Zuerst wollte ich das Reading "Device" vom DOIF Device selbst nehmen, in welchem das zuletzt getriggerte Device ja steht. Das würde mir auch genügen, aber offenbar werden alle vorherigen Readings vor dem Zeitpunkt der Abarbeitung des Befehlsteils schon gelöscht, so dass man auf diese nicht mehr zurückgreifen kann. Ich hätte halt gerne, dass das zweite Kommando nur von dem Device ausgelöst werden kann, welches das erste Kommando ausgelöst hat.
$DEVICE ist nur ein Platzhalter für das aktuelle Device. Wenn du es in der Bedingung außerhalb der eckigen Klammern benutzen willst, dann musst du bedenken, dass du in der Perl-Welt bist und mit einem Device als Bezeichner kann Perl nichts anfangen. Du hast zwei Möglichkeiten:
1. $DEVICE in Anführungszeichen zu setzen: [?HouseAnn:lastDevice] eq "$DEVICE"
oder eleganter:
2. direkt die Variable $device zu nutzen: [?HouseAnn:lastDevice] eq $device
Gruß
Damian
Zitat von: Damian am 14 Februar 2016, 19:06:43
2. direkt die Variable $device zu nutzen: [?HouseAnn:lastDevice] eq $device
Danke! Hätte schwören können das schonmal drin gehabt zu haben. Hm! ;D
War nen bissl offline, dehalb erst jetzt:
Zitat von: Damian am 07 Februar 2016, 19:01:10Ich habe das Problem nicht, es sei denn du triggerst auf dein DOIF-Modul selbst.
Komisch, gerade wieder probiert: jetzt gehts :o
Vllt. hatte ich ein update verpasst?!
Dann kann ich mich der nächsten Baustelle (AMAD) widmen.
Zitat von: Loredo am 24 Januar 2016, 20:15:22
Hi Damian,
wollte mich jetzt auch mal versuchen:
define di_rr_Julian_car2
(
["^rr_:^locationPresence$"] eq "absent" and
[?$DEVICE:location] eq "BMW"
)
(
(msg push @$DEVICE |Parkplatz für [$DEVICE:location]| Das Auto wurde hier geparkt O[{"URLTITLE":"'In Google Maps öffnen'","ACTION":"'comgooglemapsurl://maps.google.com/?q=[$DEVICE:locationLat],[$DEVICE:locationLong]'","RETRY":0,"EXPIRE":0}])
)
DOELSE
attr di_rr_Julian_car2 do always
attr di_rr_Julian_car2 wait 300
Allerdings wird cmd_1 nie ausgelöst.
Im Reading e_regexp_c1 sehe ich aber, dass das passende Event eigentlich vorbeiläuft:
rr_Julian:locationPresence: absent locationLat: 48.XXX locationLong: 11.XXX locationAddr: Strasse ABC PLZ Stadt location: BMW
Wo liegt denn hier der Fehler?
Gruß
Julian
Wie verhinderst du eigentlich, dass folgendes passiert:
- Auto steht im Carpot
- Du musst fegen
- kommst zu nahe am Auto vorbei, wirst dort vom Sensor (iBeacon?) erfasst
- bist wieder zwei Meter vom Auto weg, die Zone meldet sich ab
- befindest dich aber noch immer in der Home-Zone und hast dadurch kein neues Entry-Event
- wirst als absent markiert, was zum einen der falsche Status ist und zum anderen auch noch die Parkplatz-MSG auslöst
Oder verhinderst du wirkungsvoll, dass du von Auto-Zone erfasst wirst, solange du in der Home-Zone bist?
Viele Grüße,
kjmEjfu
Zitat von: kjmEjfu am 19 Februar 2016, 12:55:42
Wie verhinderst du eigentlich, dass folgendes passiert:
- Auto steht im Carpot
- Du musst fegen
- kommst zu nahe am Auto vorbei, wirst dort vom Sensor (iBeacon?) erfasst
- bist wieder zwei Meter vom Auto weg, die Zone meldet sich ab
- befindest dich aber noch immer in der Home-Zone und hast dadurch kein neues Entry-Event
- wirst als absent markiert, was zum einen der falsche Status ist und zum anderen auch noch die Parkplatz-MSG auslöst
Oder verhinderst du wirkungsvoll, dass du von Auto-Zone erfasst wirst, solange du in der Home-Zone bist?
Ich habe keinen Carport und die TG fegt der Hausmeister ;)
Aber selbst wenn der iBeacon auslöst, da passiert einfach dann nix, da ich als zusätzliche Bedingung noch die Home-presence!=present meines ROOMMATE Devices abfrage (ist nur zum testen hinderlich ;) ). Der Homestatus wird nicht vom iBeacon im Auto gesteuert.
Zitat von: Loredo am 21 Februar 2016, 11:04:54
Ich habe keinen Carport und die TG fegt der Hausmeister ;)
Aber selbst wenn der iBeacon auslöst, da passiert einfach dann nix, da ich als zusätzliche Bedingung noch die Home-presence!=present meines ROOMMATE Devices abfrage (ist nur zum testen hinderlich ;) ). Der Homestatus wird nicht vom iBeacon im Auto gesteuert.
Ah, da war mein Denkfehler. Wenn der iBeacon (bzw. das Auto) natürlich seinen eigenen Webhook hat, löst sich das Problem generell sehr angenehm. Man lernt hier nie aus :-)
Dafür braucht man keinen eigenen Webhook, geht alles über einen.
Gruß
Julian
Ich probiere nun erstmals die Generalisierung aus und wollte aus einem NOTIFY wie der folgende (im Forum gefunden) ...
define not_missingack notify .*:.(MISSING.ACK.*|.*NACK.*) { bla }
... ein DOIF machen. Ich habe es wie folgt ausprobiert. Ist das folgende richtig?
(
[":^MISSING.ACK"] or
[":^NACK"]
)
(ausführungsteil)
Oder kann man das auch weiter verschlanken in Form von "(MISSING.ACK.*|.*NACK.*)"?
Zitat von: FunkOdyssey am 22 Februar 2016, 16:37:13
Ich probiere nun erstmals die Generalisierung aus und wollte aus einem NOTIFY wie der folgende (im Forum gefunden) ...
define not_missingack notify .*:.(MISSING.ACK.*|.*NACK.*) { bla }
... ein DOIF machen. Ich habe es wie folgt ausprobiert. Ist das folgende richtig?
(
[":^MISSING.ACK"] or
[":^NACK"]
)
(ausführungsteil)
Oder kann man das auch weiter verschlanken in Form von "(MISSING.ACK.*|.*NACK.*)"?
.*NACK.* entspricht dann einfach "NACK"
es geht auch
[":^MISSING.ACK|NACK"] Gruß
D. Sordyl
Danke. Ich probiere das mal aus. Man kann den Fall halt so schlecht reproduzieren und deswegen habe ich vorsichtshalber im Forum gefragt. merci
Zitat von: Loredo am 21 Februar 2016, 13:43:27
Dafür braucht man keinen eigenen Webhook, geht alles über einen.
dann verstehe ich leider doch nicht ganz, wie du das machst.
Denn auch wenn der iBeacon auslöst, wird doch im Geofancy die DeviceUUID vom iPhone übergeben. Durch das entsprechend im Roommate gesetzte Attribut rr_geofenceUUIDs wird aber doch eine Veränderung durchgeführt. Ein rr_locationIgnore o.ä. gibt es ja nicht.
Kannst du mich noch in die richtige Richtung schubsen?
Das ist jetzt wirklich OT hier, ich habe dir im Geofancy Thread (http://forum.fhem.de/index.php/topic,18485.msg414935.html#msg414935) geantwortet.
Gruß
Julian
Hallo Damian,
ich hätte da noch eine Idee/einen Wunsch:
Die Syntax bei Filtern nach Ausdrücken mit Ausgabeformatierung (http://fhem.de/commandref_DE.html#DOIF_Filtern_nach_Zahlen) erweitern auf
[<Device>:<Reading>|<Internal>:d|"<Regex>":"<Output>":"<notexist>"]
So könnte man für jede Abfrage noch einen eigenen notexist Wert Vergeben. So wie es aktuell mit ReadingsVal auch funktioniert.
Grüße
igami
Zitat von: igami am 29 März 2016, 20:58:41
Hallo Damian,
ich hätte da noch eine Idee/einen Wunsch:
Die Syntax bei Filtern nach Ausdrücken mit Ausgabeformatierung (http://fhem.de/commandref_DE.html#DOIF_Filtern_nach_Zahlen) erweitern auf
[<Device>:<Reading>|<Internal>:d|"<Regex>":"<Output>":"<notexist>"]
So könnte man für jede Abfrage noch einen eigenen notexist Wert Vergeben. So wie es aktuell mit ReadingsVal auch funktioniert.
Grüße
igami
Da in den meisten Fällen die zusätzlichen Optionen nicht benutzt werden, müsste man [device:reading:::"Defaultwert"] angeben - ist nicht so schön.
Hast du einen Fall, wo das Attribut notexist nicht ausreicht?
Gruß
Damian
Eigentlich wollte ich damit das Konstrukt
("[HM_2C10D8_Sw:state]" eq "on")?"eingeschaltet":"ausgeschaltet")
abkürzen.
Wobei ich hier ja auch den Wert des Reading auf "on" überprüfe und nicht ob das Reading existiert.
habe es nun folgendermaßen gelöse
[HM_2C10D8_Sw:state:"(.*)":($1 =~ /on/?"eingeschaltet":"ausgeschaltet")]
Eine Frage als Nicht-Perl-Nativ-Speaker: Wie sieht das ganze DOIF aus? Ab und zu bräuchte ich sowas, um Gerätenamen in Meldungen "sprechender" zu machen. Küchenfenster auf liest sich besser als ku.window auf :D.
Zitat von: igami am 31 März 2016, 17:46:43
habe es nun folgendermaßen gelöse
[HM_2C10D8_Sw:state:"(.*)":($1 =~ /on/?"eingeschaltet":"ausgeschaltet")]
Mit den neuen Filteroptionen ist das sicherlich möglich. Allerdings gibt es hier genauso eine Fehlermeldung, wenn das Reading nicht vorhanden ist.
Zitat von: Damian am 31 März 2016, 18:56:02
Mit den neuen Filteroptionen ist das sicherlich möglich. Allerdings gibt es hier genauso eine Fehlermeldung, wenn das Reading nicht vorhanden ist.
Ist eigentlich auch ein Mapping des Werts als eine Abfrage ob das Reading existiert.
Zitat von: igami am 01 April 2016, 13:08:33
Ist eigentlich auch ein Mapping des Werts als eine Abfrage ob das Reading existiert.
Im Ausführungsteil ist das sicherlich gut nutzbar. In der Bedingung kann man ja auch mit =~ auf "on" abfragen.
Gruß
Damian
Hallo,
ich möchte das ich eine EMail erhalte, wenn ein Fensterkontakt "open" signalisiert und der Dummy "ALARM_armed" aktiv ist.
Alle Fensterkontakte beginnen mit "Fensterkontakt_".
Leider bekomme ich nicht cmd 1. Es bleibt auf cmd2.
Erst hatte ich diese Variante:
(["^Fensterkontakt_"] eq "open" and [?ALARM_armed] eq "an") ({DebianMail(xxxxxx)})
Aus der Commandref habe ich dann dies hier probiert (da ist mein Anwendungsfall ja eigentlich beschrieben)
(["^Fensterkontakt_:open"] and [?ALARM_armed] eq "an") ({DebianMail(xxxxxx)})
Wie gesagt, ich bekomme immer nur cmd2. Kann mir bitte jemand unter die Arme greifen? Wo habe ich den Fehler gemacht?
Herzlichen Dank und viele Grüße
gib mal bitte ein list von deinem DOIF
Hallo.
Sehr gern.
Hier für die Variante 1:
Internals:
DEF (["^Fensterkontakt_"] eq "open" and [?ALARM_armed] eq "an") ({DebianMail('xxxxxxx')})
NAME DOIF_Alarm_Fenster_Kontakt_EMail
NR 284
NTFY_ORDER 50-DOIF_Alarm_Fenster_Kontakt_EMail
STATE initialized
TYPE DOIF
Readings:
2016-11-25 00:03:15 cmd 0
2016-11-25 00:03:15 state initialized
Condition:
0 EventDoIf('^Fensterkontakt_',$hash,'',0) eq "open" and InternalDoIf($hash,'ALARM_armed','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "an"
Devices:
Do:
0:
0 {DebianMail(xxxxxxxx)}
Helper:
globalinit 1
last_timer 0
sleeptimer -1
Internals:
0 ALARM_armed:STATE
all ALARM_armed:STATE
Itimer:
Regexp:
0:
0 ^Fensterkontakt_
All:
0 ^Fensterkontakt_
State:
Attributes:
room Alarm
und dann noch für die andere Variante:
Internals:
DEF (["^Fensterkontakt_:open"] and [?ALARM_armed] eq "an") ({DebianMail('xxxxx')})
NAME DOIF_Alarm_Fenster_Kontakt_EMail2
NR 284
NTFY_ORDER 50-DOIF_Alarm_Fenster_Kontakt_EMail2
STATE initialized
TYPE DOIF
Readings:
2016-11-25 00:07:58 cmd 0
2016-11-25 00:07:58 state initialized
Condition:
0 EventDoIf('^Fensterkontakt_',$hash,'open',0) and InternalDoIf($hash,'ALARM_armed','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "an"
Devices:
Do:
0:
0 {DebianMail('xxxxxxx')}
Helper:
globalinit 1
last_timer 0
sleeptimer -1
Internals:
0 ALARM_armed:STATE
all ALARM_armed:STATE
Itimer:
Regexp:
0:
0 ^Fensterkontakt_:open
All:
0 ^Fensterkontakt_:open
State:
Attributes:
room Alarm
hi,
sieht erstmal gut aus.
probier mal die Abfrage ob der Alarm scharf ist zum testen rauszulassen und mach dann das Fenster los. Dann sollte er eig 1 mal in cmd_1 wechseln.
(["^Fensterkontakt_:open"]) ({DebianMail('xxxxx')})
und schau auch bitte im Eventmonitor wie das Event genau aussieht.
EDIT:
Zusätzlich könnte noch ein Grund gewesen sein, dass ALARM_armed noch kein Event generiert hat und das DOIF somit den aktuellen Status noch nicht kennt. Das ist der kleine, aber feine Unterschied zwischen triggerden und nicht triggernden Bedingungen. Die Werte werden in beiden Fällen erst bei Events dem DOIF bekannt. Nur das bei nicht triggernden Bedingungen die Auswertung bei Aktualisierung des Readings nicht stattfindet.
Dazu noch eine Anmerkung:
Du hast ALARM_armed nicht triggernd definiert. Gesetzt der Fall, dass dein Fenster offen steht und du scharf schaltest, wird nichts passieren, da die Bedingungen nur überprüft werden wenn dein Fensterkontakt ein "open" sendet. Das open wurde aber in diesem Fall gesendet BEVOR scharf geschaltet wurde und somit war die Bedigung nicht wahr.
Sendet er das zyklisch, dann ist es wieder fast egal, da dann beim nächsten "open" überprüft wird und dann die Mail rausgeht
Gruß Michael
Zitat von: lestat.le am 25 November 2016, 00:10:10
Hier für die Variante 1:
(["^Fensterkontakt_"] eq "open" and [?ALARM_armed] eq "an") ({DebianMail('xxxxxxx')})
Das kann so nicht funktionieren. Du kannst zwar auf Events triggern, aber nicht gleichzeitig den "Wert" des Events auswerten (bzw. das wird wohl in der nächsten DOIF-Version möglich sein, an der Damian gerade arbeitet).
Aktuell müsste es nach meinem Verständnis immer noch so gelöst werden:
(["^Fensterkontakt_"] and [$DEVICE:state] eq "open" and [?ALARM_armed] eq "an")
Oder Du triggerst eben direkt auf den Schlüsselwort open in Events.
@Brockmann
Dankeschön!
Jetzt funktioniert es.
Deine Variante hatte ich eigentlich auch schon probiert aber wahrscheinlich irgendwo mit Drehern.
@Michael
Auch herzlichen Dank.
Das ALARM_armed nicht triggert ist für mich ok. Dann kann ich schon mal scharf schalten ohne das es Alarm gibt, falls noch ein Fenster geöffnet ist.
Aber ich müsste mir dennoch dringend einen Workflow überlegen, wie ich die Alarmierung angehen möchte. Hauptsache das System muss transparent und simple bleiben.
Viele Grüße
Hallo,
ich versuche gerade meine etwas komplexe Rollladen-Steuerung zu vereinfache.
Aktuell gibt es für jedes Fenster/Rollladen ein DOIF. (Auf, Zu, Beschattung, Lüften mit unterschiedlichen Bedingungen)
Änderungen in der grundsätzlichen Logik müssen ziemlich mühsam auf alle übertragen werden.
Ist es möglich Teile des $DEVICE in der set-Anweisung weiter zu verwenden?
Also in der Art:
["*.fensterkontakt.*:open|tilted"] (set *.gurtwickler.* Lueften)
z.b. ["buero.fensterkontakt.ostseite:open|tilted"] (set buero.gurtwickler.ostseite Lueften)
Ist so etwas überhaupt möglich?
Bräuchte hier einen Denkanstoß. Bekomme das Thema leider nicht richtig gegriffen.
Gruß Chris
Zitat von: hatamoto am 23 Februar 2017, 21:03:08
Ist es möglich Teile des $DEVICE in der set-Anweisung weiter zu verwenden?
Ist so etwas überhaupt möglich?
Bräuchte hier einen Denkanstoß. Bekomme das Thema leider nicht richtig gegriffen.
DOIF selbst bietet dafür kein Werkzeug. Aber Du kannst ja beliebige Perl-Funktionen einsetzen, um Strings zu zerlegen und wieder zusammenzusetzen.
Alternative: Du könntest bei den Fensterkontakten jeweils den Namen des dazugehörenden Gurtwicklers als Userreading ablegen. Darauf kannst Du ja mit DOIF direkt referenzieren, also
set buero.fensterkontakt.ostseite userReadings mein_gurtwickler {"buero.gurtwickler.ostseite"}
und dann
["*.fensterkontakt.*:open|tilted"] (set [$DEVICE:mein_gurtwickler] Lueften)
Ungetestet und ohne Gewähr
Im Prinzip müsste es so klappen
({"$DEVICE"=~/\.(.*)\./;;fhem ("set *.$1.* Luften")})
Bei einer Namensgebung a.B.c findet /\.(.*)\./ B und schreibt den Inhalt der ersten Klammer in die Variable $1. Die benutzt Du dann im set-Befehl.
Ich sehe gerade, Du möchtest a,c verwenden
dann geht's mit
({"$DEVICE"=~/(.*)\..*\.(.*)/;;fhem ("set $1.gurtwickler.$2 Luften")})
siehe http://perldoc.perl.org/perlre.html
Ich habe hier https://forum.fhem.de/index.php/topic,67351.0.html eine neue Version abgelegt (v0.7)
Nun werden Angaben im Ausführungsteil, die Perlcode in {(...)} beinhalten differenzierter betrachtet. Bisher wurden die runden Klammern an Perl übergeben, dass hatte den Vorteil, dass man z. B. set bla {(2+3)/2} angeben konnte, allerdings den Nachteil, dass aufgrund der runden Klammern kein beliebiger Perl-Code ausführbar war. Die neue Version erkennt nun, ob die dazugehörige runde Klammer "zu" ganz am Ende ist und eliminiert beide runden Klammern. Damit bleibt die alte Kompatibilität erhalten und es lässt sich nun beliebiger Perlcode ausführen. z. B.
set bla {(my $test=2;return ($test+3))}
damit lässt sich jetzt auch das Filter-Problem wie folgt lösen:
(set {("$DEVICE"=~/(.*)\..*\.(.*)/;"$1.gurtwickler.$2")} on)
Danke für den Input. Das hat so auch geklappt. :D
Jetzt würde ich gerne im Bedingungsteil noch ein paar Infos abfragen.
z.B. welchen Zustand der betroffene Gurtwickler hat (auf, zu, lüften,...). Ein offener Rollladen muss ja nicht auf Lüften gefahren werden.
Das müsste dann ja ungefähr so lauten:
([".fensterkontakt.:offen|gekippt"] and
[?{("$DEVICE"=~/(.*)\..*\.(.*)/;"$1.gurtwickler.$2")}] eq "auf")
(set {("$DEVICE"=~/(.*)\..*\.(.*)/;"$1.gurtwickler.$2")} Lueften)
Ist das möglich oder wird $DEVICE erst mit Ende des Durchlaufen der Bedingung generiert?
Mir ist außerdem noch aufgefallen, dass wenn man, in der regex-Angabe, "*" als Wildcard verwendet, fhem komplett abschießt. Zumindest ist es mir so gegangen...
Also z.B. (["*.fensterkontakt.*:offen|gekippt"])
Gruß Chris
*. ist auch kein regex ;-)
[?{("$DEVICE"=~/(.*)\..*\.(.*)/;"$1.gurtwickler.$2")}] eq "auf")
Nette Idee :) funktioniert aber leider nicht.
Die Syntax {(...)} wurde eingeführt um innerhalb eines FHEM-Befehls Perl ausführen zu können. Die Bedingung von DOIF ist aber bereits schon Perl und innerhalb der eckigen Klammern ist es nicht vorgesehen.
Da du noch mehr Abfragen machen willst und bereits mit Perl hantierst, bietet sich in diesem Fall an, das neue Device in eine Perlvariable zu packen und dann auf der Perlebene weiter zu machen, z. B.
DOIF ([".fensterkontakt.:offen|gekippt"])
({"$DEVICE"=~/(.*)\..*\.(.*)/;
my $gw="$1.gurtwickler.$2";
if (Value($gw) eq "auf) {fhem "set $gw 80";};
if ....
...
})
Alternativ könnte man auch den Gurtwickler per setreading in ein temporäres Reading des DOIF-Moduls legen und dann mit FHEM-IF-Befehl auf der FHEM-Ebene weiter machen.
ZitatJetzt würde ich gerne im Bedingungsteil noch ein paar Infos abfragen.
z.B. welchen Zustand der betroffene Gurtwickler hat (auf, zu, lüften,...). Ein offener Rollladen muss ja nicht auf Lüften gefahren werden.
Du könntest im Befehl FILTER verwenden
set {("$DEVICE"=~/(.*)\..*\.(.*)/;"$1.gurtwickler.$2")}:FILTER=state!=offen Lueftensiehe https://fhem.de/commandref_DE.html#devspec
Ich stehe gerade vermutlich am Schlauch:
Ich habe schon verschiedenstes probiert, aber es klappt nicht.
Was ich gerne möchte ist, die userReadings von dummy1 nach dummy2 zu kopieren.
Das klappt bis num ersten Kommentar (#) im Code.
({ my $a = AttrVal("dummy1","userReadings","");; fhem("attr dummy2 userReadings $a")})
Gibt es eine bessere Möglichkeit, dieses Attribut 1:1 zu kopieren?
So etwas in dieser Art fnktioniert ja nicht, da das § für den Zugriff auf Attribute nicht umgesetzt wurde, oder habe ich da was übersehen?
(attr dummy2 userReadings [dummy1:userReadings])
Zitat von: JoeALLb am 22 März 2017, 12:52:48
Ich stehe gerade vermutlich am Schlauch:
Ich habe schon verschiedenstes probiert, aber es klappt nicht.
Was ich gerne möchte ist, die userReadings von dummy1 nach dummy2 zu kopieren.
Das klappt bis num ersten Kommentar (#) im Code.
({ my $a = AttrVal("dummy1","userReadings","");; fhem("attr dummy2 userReadings $a")})
Gibt es eine bessere Möglichkeit, dieses Attribut 1:1 zu kopieren?
So etwas in dieser Art fnktioniert ja nicht, da das § für den Zugriff auf Attribute nicht umgesetzt wurde, oder habe ich da was übersehen?
(attr dummy2 userReadings [dummy1:userReadings])
Funktioniert
{fhem("attr dummy2 userReadings ".AttrVal("dummy1","userReadings",""))}?
Zitat von: Ellert am 22 März 2017, 15:20:12
Funktioniert {fhem("attr dummy2 userReadings ".AttrVal("dummy1","userReadings",""))}?
Nein. Danke für die Hilfe! Übernommen wird bis zum ersten ;
dummy1:userReadings sieht in etwa so aus;
desired-manual:(desired-temp|controlMode|set_desired-temp).* {
my $tempProfile="";
my $wTagN = strftime('%w', localtime);
}in
dummy2:userReadings kommt dann folgendes an:
desired-manual:(desired-temp|controlMode|set_desired-temp).* {
my $tempProfile="";
Hier stimmt ja schon die normale Klammerprüfung nicht.
im DOIF- "error" erhalte ich damit:
{fhem("attr dummy2 userReadings ".AttrVal("dummy1","userReadings",""))}: Unknown command my, try help. Bei mehr Zeilen wiederholt sich das "Unknown command my, try help", so als ob jede zeile einzeln ausgeführt wird?!?
Hast Du noch eine weitere Idee dazu?
sG
joe
Hallo,
Die ; müssen maskiert werden, das heißt, suchen nach ; und ersetzen durch ;; - geht u. A. mit RegEx, müsste ich aber erstmal raussuchen (bin gerade nur an Handy)
Ronny
Gesendet von meinem SM-G935F mit Tapatalk
Zitat von: RoBra81 am 22 März 2017, 18:41:45
Die ; müssen maskiert werden, das heißt, suchen nach ; und ersetzen durch ;; - geht u. A. mit RegEx, müsste ich aber erstmal raussuchen (bin gerade nur an Handy)
Hallo Ronny, danke für die Idee, das hatte ich schon versucht doch die Fehlermeldung bleibt die selbe....
Zitat von: JoeALLb am 22 März 2017, 18:01:48
Nein. Danke für die Hilfe! Übernommen wird bis zum ersten ;
dummy1:userReadings sieht in etwa so aus;
desired-manual:(desired-temp|controlMode|set_desired-temp).* {
my $tempProfile="";
my $wTagN = strftime('%w', localtime);
}
in
dummy2:userReadings kommt dann folgendes an:
desired-manual:(desired-temp|controlMode|set_desired-temp).* {
my $tempProfile="";
Hier stimmt ja schon die normale Klammerprüfung nicht.
im DOIF- "error" erhalte ich damit:
{fhem("attr dummy2 userReadings ".AttrVal("dummy1","userReadings",""))}: Unknown command my, try help.
Bei mehr Zeilen wiederholt sich das "Unknown command my, try help", so als ob jede zeile einzeln ausgeführt wird?!?
Hast Du noch eine weitere Idee dazu?
sG
joe
Gibt es auch eine Fehlermeldung, wenn Du
{fhem("attr dummy2 userReadings ".AttrVal("dummy1","userReadings",""))} in der Befehlszeile ausführst? Wenn ja, dann ist es kein DOIF Problem.
Eventuell müssen die Anführungszeichen und Zeilenumbrüche im Code maskiert werden.
Zitat von: Ellert am 23 März 2017, 23:04:52
Gibt es auch eine Fehlermeldung, wenn Du {fhem("attr dummy2 userReadings ".AttrVal("dummy1","userReadings",""))} in der Befehlszeile ausführst? Wenn ja, dann ist es kein DOIF Problem.
Eventuell müssen die Anführungszeichen und Zeilenumbrüche im Code maskiert werden.
Vielen Dank für die Hilfe!!
Ja, die selbe Fehlermeldung. kann ich den Wert aus der fhem.cfg irgendwie direkt auslesen? Dieser müsste ja das korrekte Encoding schon haben.
Wenn ich selbst ein Encoding versuche umzusetzen, habe ich die Sorge, etwas zu vergessen bzw. ein unvollständiges Encoding zu schreiben.....
Oder kann ich irgendwo direkt auf das Encoding zugreifen, dass dher fhem-editor selbst nutzt?
sG
Joe
Du könntest versuchen direkt im %attr-Hash zu kopieren, ist aber nicht empfohlen, s. https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Attribute
Oder Du fragst im entsprechenden Forenbereich nach.
Hallo zusammen,
ich versuche $DEVICE einzusetzen, scheitere aber bei der Umsetzung.
Ich habe mich im commandref und Forum belesen, finde aber nicht heraus, was ich falsch mache.
Ich habe verschiedene Devices, die ein Reading "Zeitstempel" haben.
Ich möchte Meldungen generieren, die mir eine Nachtricht zusenden, wenn die Zeitspanne eines Readings älter als 120 Sekunden ist.
Es kommen gar keine Nachrichten, nicht mal verstümmelte.
define Sensor.Aktualitaet DOIF ([+:02] and [":^Zeitstempel$"] and [$DEVICE:Zeitstempel:sec] > 120)
((set Pushover.Nachricht msg 'Sensor außer Betrieb' '$DEVICE:\n[$DEVICE:Zeitstempel]'))
((set PushNotifier.Nachricht message Sensor außer Betrieb_$DEVICE:_[$DEVICE:Zeitstempel]))
(set Pushbullet.Nachricht message $DEVICE: [$DEVICE:Zeitstempel] | Sensor außer Betrieb)
Warum bekomme ich keine Nachrichten?
Viele Grüße Gisbert
Hallo,
zur Ergänzung, so sieht ein Reading "Zeitstempel" aus:
defmod Heizung MQTT_DEVICE DS18B20
setstate Heizung 2017-09-23 16:05:19 Zeitstempel 2017-09-23 16:05:19
Kann es sein, dass die Zeitspanne bei Verwendung des obigen Readings nicht richtig dargestellt wird bzw. verarbeitet wird?
Viele Grüße Gisbert
Nimm mal die +2 bitte erstmal raus. Mir kommt das seltsam vor. Kann mir nicht vorstellen das beides wahr sein kann. Also Event Zeitstempel und gleichzeitig die plus 2
Genau. Und noch weniger, dass die 3 gleichzeitig wahr sind:
[+:02] in 2 Minuten
[":^Zeitstempel$"] ein "Zeitstempel Event
[$DEVICE:Zeitstempel:sec] > 120) der vor mehr als 2 Minuten passiert ist
Und do always setzen.
Hier sollte doch eine Abfrage reichen
[?$DEVICE:Zeitstempel:sec] > 120)
Die beiden letzten können auch nicht gleichzeitig wahr sein, egal ob mit ? oder nicht.
Sagen wir mal, das Event "Zeitstempel" kommt um 17:00:00
[":^Zeitstempel$"] ist um 17:00:00 wahr
[?$DEVICE:Zeitstempel:sec] > 120 ist um 17:00:00 nicht wahr da dann :sec = 0
Hallo anemonade und Leon,
vielen Dank für euren Input.
Ich fürchte auch, dass kein Event zustande kommt (zumindest nicht mit der Generalisierung $DEVICE), da die Sensoren sich dann ja aufgehangen haben oder aus irgeneinem Grund keine Daten mehr nach Fhem liefern.
Eure Vorschläge habe ich ausprobiert, ohne Erfolg.
Do always war schon vorher gesetzt.
Was funktioniert, ist folgendes, was ich aber für jedes Device einzeln angelegt habe.
Ich dachte ich könnte mir mit der Generalisiserung $DEVICE einige Zeilen Code ersparen.
define SensorAktualitaet DOIF ([+:02] and ReadingsAge("Heizung","Zeitstempel","") > 120)
((set Pushover.Nachricht msg 'Sensor außer Betrieb' 'Heizung:\n[Heizung:Zeitstempel]'))
((set PushNotifier.Nachricht message Sensor außer Betrieb_Heizung:_[Heizung:Zeitstempel]))
(set Pushbullet.Nachricht message Heizung: [Heizung:Zeitstempel] | Sensor außer Betrieb)
Falls ihr noch eine Idee habt, dann teste ich gerne.
Viele Grüße Gisbert
Für Ausfall eines Sensors
siehe das Beispiel hier: https://fhem.de/commandref_DE.html#DOIF_do_resetwait
Hallo Damian,
Attribut resetwait statt always: kein Erfolg
Ich hatte noch ein Attribut wait, welches ich auf Null gesetzt habe: kein Erfolg
Die Abfrage [":^Zeitstempel$"] alleine ohne irgendeine weitere Bedingung liefert keine Nachrichten, sehr merkwürdig.
Wenn ich die Bedingung [":Zeitstempel"] benutze, kommen im Halbsekunden-Takt Nachrichten herein.
Benutze ich [":Zeitstempel"] und irgendeine weitere Bedingung z.B. [?$DEVICE:Zeitstempel:sec] > 60, bekomme ich keinerlei Meldung.
Die letztere Bedingung war nachweislich erfüllt.
Ich habe diesen Beitrag gelesen, Ausfallerkennung von Sensoren:
https://forum.fhem.de/index.php/topic,63223.msg544611.html#msg544611 (https://forum.fhem.de/index.php/topic,63223.msg544611.html#msg544611)
Dort wird geraten: Funktion vor Schönheit - ich werde diesen Rat beherzigen, da sich kein Erfolg bei der Generalisierung einstellen will.
Viele Grüße Gisbert
1) [":^Zeitstempel$"] kann schon deswegen nicht funktionieren, da hinter Zeitstempel ja noch was kommt ;)
daher wäre hier [":^Zeitstempel"] besser.
2) [":^Zeitstempel"] and [?$DEVICE:Zeitstempel:sec] > 60 macht keinen Sinn, da zum Triggerzeitpunkt [?$DEVICE:Zeitstempel:sec] gleich Null ist.
3) Wait-Attribut mit do resetwait, macht nur bei konkreten Deviceangaben Sinn, da DOIF nur einen Wait-Timer verwaltet und nicht mehrere. Hier ist Generalisierung für mehrere Devices mit wait nicht möglich
4) Du musst entweder pro Device, wie im Anwendungsbeispiel ein DOIF definieren, oder du generalisierst mit einem DOIF in Kombination mit sleep bzw. at, wie in diesen Beispielen:
ZitatVerzögerte "Fenster offen"-Meldung
define di_window_open DOIF ["^window_:open|tilted"])
(defmod at_$DEVICE at +00:05 set send window $DEVICE open)
DOELSEIF (["^window_:closed"])
(delete at_$DEVICE)
attr di_window_open do always
Alternative mit sleep
define di_window_open DOIF ["^window_:open|tilted"])
(sleep 300 $DEVICE quiet;set send window $DEVICE open)
DOELSEIF (["^window_:closed"])
(cancel $DEVICE quiet)
Ich pack es mal hier mit rein: kann ich $EVENT irgendwie formatieren? Also $EVENT:d geht schon mal nicht.
Und weil ich das Problem öfter habe und immer nur durch Probieren rausbekomme: wie wird zwischen ["device:event"] und ["device:reading"] mit beliebigen Event unterschieden? ["device:reading:"]?
Den Fall, dass ein Reading oder Event "d" haben soll, ist bei mir zumindest bisher nicht vorgekommen. Ich denke, dann muss man irgendwie maskieren. Oder "weiterzählen": ["device:reading:d:"]?
Zitat von: Per am 29 Dezember 2017, 00:42:12
Ich pack es mal hier mit rein: kann ich $EVENT irgendwie formatieren? Also $EVENT:d geht schon mal nicht.
Und weil ich das Problem öfter habe und immer nur durch Probieren rausbekomme: wie wird zwischen ["device:event"] und ["device:reading"] mit beliebigen Event unterschieden? ["device:reading:"]?
Den Fall, dass ein Reading oder Event "d" haben soll, ist bei mir zumindest bisher nicht vorgekommen. Ich denke, dann muss man irgendwie maskieren. Oder "weiterzählen": ["device:reading:d:"]?
Du kannst mit dieser Syntax:
["regex for trigger":"<regex filter>":<output>,<default value>]Filter setzen.
Zitat aus der Commanref:
Zitat
Wenn kein Filter, wie obigen Beispiel, angegeben wird, so wird intern folgende Regex vorbelegt: "[^\:]*: (.*)" Damit wird der Wert hinter der Readingangabe genommen. Durch eigene Regex-Filter-Angaben kann man beliebige Teile des Events herausfiltern, ggf. über Output formatieren und in der Bedingung entsprechend auswerten, ohne auf Readings zurückgreifen zu müssen.
:d für Zahlen bei Events ist noch nicht realisiert, der passende Filter könnte so aussehen:
"[^\:]*: (\d*)"Das gilt allerdings nur für die DOIF-Bedingung, nicht für den Ausführungsteil.
Zitat von: Damian am 29 Dezember 2017, 18:00:50der passende Filter könnte so aussehen:
"[^\:]*: (\d*)"
Kannst du mich (und bestimmt andere Nicht-Perler) abholen?
Beispiel: ... and $EVENT > 12
wo kommt dann dein Vorschlag rein? Und mit/ohne geschweifte Klammern?
Zitat von: Damian am 29 Dezember 2017, 18:00:50nicht für den Ausführungsteil.
Lohnt da das warten?
Zitat von: Per am 29 Dezember 2017, 18:14:07
Kannst du mich (und bestimmt andere Nicht-Perler) abholen?
Beispiel: ... and $EVENT > 12
wo kommt dann dein Vorschlag rein? Und mit/ohne geschweifte Klammern?
Lohnt da das warten?
z. B.:
DOIF (["FS":"[^\:]*: (\d*)",0] > 12) (set bla {("$EVENT" =~ "[^\:]*: (\d*)";$1)})
Bei dieser Abfrage sollten keine Zahlen im Reading vorkommen, ansonsten müsste man die Abfrage noch weiter verfeinern.Im Ausführungsteil wird mit Hilfe des Operators =~ nach der Zahl per Perl gefiltert.
Edit: Zahlen im Reading sind unkritisch, da erst nach dem Doppelpunkt ausgewertet wird.
Zitat von: Damian am 29 Dezember 2017, 18:47:30
(set bla {("$EVENT" =~ "[^\:]*: (\d*)";$1)})
Irgendwie funktionierte nur
(set bla {("$EVENT" =~ "[^\:]*: (.*)";$1)})Zum Glück weiss ich nicht warum :D.
Zitat von: Damian am 29 Dezember 2017, 18:47:30
Edit: Zahlen im Reading sind unkritisch, da erst nach dem Doppelpunkt ausgewertet wird.
Du meinst hoffentlich im Reading-Namen.
Zitat von: Per am 29 Dezember 2017, 22:06:00
Irgendwie funktionierte nur
(set bla {("$EVENT" =~ "[^\:]*: (.*)";$1)})
Zum Glück weiss ich nicht warum :D.
Du meinst hoffentlich im Reading-Namen.
dann probiere mal:
(set bla {("$EVENT" =~ "[^\:]*: (-?\d+(\.\d+)?)";$1)})(-?\d+(\.\d+)?) entspricht dem Filter
:d bei Readings.
Dann steht der komplette Ausdruck
"wert: 12" =~ "[^\:]*: (-?\d+(\.\d+)?)"
in "bla". Klammerwert durch .* ersetzt ergibt 12. Ich weiss, dass damit "nur" der Wert vom Readingnamen getrennt wird, würde mir in dem Fall aber erstmal reichen.
Zitat von: Per am 29 Dezember 2017, 23:42:56
Dann steht der komplette Ausdruck
"wert: 12" =~ "[^\:]*: (-?\d+(\.\d+)?)"
in "bla". Klammerwert durch .* ersetzt ergibt 12. Ich weiss, dass damit "nur" der Wert vom Readingnamen getrennt wird, würde mir in dem Fall aber erstmal reichen.
ohne $1 ist das nachvollziehbar.
Mit
(set d_test {("bla: 12" =~ "[^\:]*: (.*)";$1)})wird bei mir d_test mit 12 korrekt belegt.
Zitat von: Damian am 29 Dezember 2017, 23:55:17
ohne $1 ist das nachvollziehbar.
Keine Angst, dass hatte ich drin. Im Code-Tag hatte ich das Ergebnis stehen.
OK. Jetzt aber:
(set d_test {("bla: 12" =~ /[^\:]*: (-?\d+(\.\d+)?)/;$1)})
Jap, das geht.
Keine Ahnung, warum. ;)
Zitat von: Per am 30 Dezember 2017, 00:31:15
Jap, das geht.
Keine Ahnung, warum. ;)
Das ist halt Perl:
\d in Anführungszeichen ergibt in Perl
d statt
\d
Zitat von: Damian am 30 Dezember 2017, 08:34:36
in Anführungszeichen ergibt in Perl ...
BTW: vllt. ist es hilfreich, in der CommandRef zu erwähnen, dass $_ (vllt. auch an anderer Stelle) in doppelten Anführungszeichen verwendet werden sollten. In den Beispielen ist es zwar auch so gemacht, aber z.B.
Zitatdefine di_Fenster DOIF (["^Window:open"]) {foreach (AggrDoIf('@','^windows','state','"open"')) {Log3 "di_Fenster",3,"Das Fenster $_ ist noch offen"}}
werden beide Varianten "bunt" durcheinander gemixt. Einem Perler ist der Grund vllt. ohne weiters erkennbar, mir nicht.
Ein paar Perlkenntnisse schaden nie ;)
Variablen in doppelten Anführungszeichen werden aufgelöst, in einfachen Anführungszeichen nicht.
Die Variable $var habe den Wert ABC, dann ergibt
"$var Schütze" --> ABC Schütze
'$var Schütze' --> $var Schütze
Übrigens, reguläre Ausdrücke sind eine Beschreibungssprache für Zeichenkettenmengen, die unabhängig von Perl existiert, s. https://de.wikipedia.org/wiki/Regul%C3%A4rer_Ausdruck
Zitat von: Ellert am 31 Dezember 2017, 09:22:00
Ein paar Perlkenntnisse schaden nie ;)
Klar ;), aber immerhin liegt der "DOIF-Interpreter" drüber.
Zitat von: Ellert am 31 Dezember 2017, 09:22:00
Variablen in doppelten Anführungszeichen werden aufgelöst, in einfachen Anführungszeichen nicht.
Die Variable $var habe den Wert ABC, dann ergibt
"$var Schütze" --> ABC Schütze
'$var Schütze' --> $var Schütze
Ist genau dann ein Problem, wenn:
Zitat von: Damian am 29 Dezember 2017, 18:47:30
DOIF (["FS":"[^\:]*: (\d*)",0] > 12) (set bla {("$EVENT" =~ "[^\:]*: (\d*)";$1)})
doppelte hier nicht gehen, aber einfache oder Slashs eine Fehlermeldung
DOIF: wrong filter Regex: /[^\:]*im Editor erzeugen.
Zitat von: Per am 01 Januar 2018, 20:34:46
Klar ;), aber immerhin liegt der "DOIF-Interpreter" drüber.
Ist genau dann ein Problem, wenn:doppelte hier nicht gehen, aber einfache oder Slashs eine Fehlermeldung
DOIF: wrong filter Regex: /[^\:]*
im Editor erzeugen.
OK. Man muss natürlich wissen, was gehört noch zum DOIF-Interpreter und was wird an Perl-Interpreter weitergegeben.
Man kann allgemein sagen, alles was in eckigen Klammern ist, wird in erster Linie vom DOIF-Interpreter verarbeitet - auch die doppelten Anführungszeichen, daher gelten hier nicht unbedingt die Perl-Regeln. Sachen in geschweiften Klammern gehören der Perl-Welt - meistens ;)
Aber was verwende ich jetzt? Oder muss ich das in der cfg. ändern, weil der Editor das falsch erkennt?
Zitat von: Per am 01 Januar 2018, 20:58:38
Aber was verwende ich jetzt? Oder muss ich das in der cfg. ändern, weil der Editor das falsch erkennt?
DOIF (["FS":"[^\:]*: (\d*)",0] > 12) (set bla {("$EVENT" =~ /[^\:]*: (\d*)/;$1)})So wie ich geschrieben habe: eckige Klammern DOIF-Syntax, hier sind Anführungszeichen, wie in der Commandref beschrieben angesagt. In geschweiften Klammern: Perl-Syntax mit allen Feinheiten von Perl und das sind ja bekanntlich einige ;)
Sorry, mein Fehler. Dort wars ja ok. Außer man nimmt "[^\:]*: (-?\d+(\.\d+)?)".
Hier (in Bedingung)
(("$EVENT" =~ "[^\:]*: (\d*)") < 100)
kommt:
timer_01_c01 error: Wrong timespec ^\:: either HH:MM:SS or {perlcode}
/ oder ' bringen keine Besserung.
Zitat von: Per am 01 Januar 2018, 21:37:18
Sorry, mein Fehler. Dort wars ja ok. Außer man nimmt "[^\:]*: (-?\d+(\.\d+)?)".
Hier (in Bedingung)
(("$EVENT" =~ "[^\:]*: (\d*)") < 100)
kommt:
timer_01_c01 error: Wrong timespec ^\:: either HH:MM:SS or {perlcode}
/ oder ' bringen keine Besserung.
In der Bedingung funktioniert das nicht, sondern nur so, wie ich es zuvor definiert habe, statt "FS" musst du deine Trigger-Regex angeben.
Zitat von: Damian am 01 Januar 2018, 21:43:22statt "FS" musst du deine Trigger-Regex angeben.
Also 2x das Selbe. Wenn das keine Probleme ($DEVICE,$EVENT,Performance) gibt, soll es mich nicht stören.
Zitat von: Per am 01 Januar 2018, 21:46:47
Also 2x das Selbe. Wenn das keine Probleme ($DEVICE,$EVENT,Performance) gibt, soll es mich nicht stören.
Natürlich sind das Ressourcenfresser, wenn man den Trigger nicht genau spezifiziert. Daher möglichst genau angeben, was triggern soll - das gilt für alle Eventhandler.
Zitat von: Per am 01 Januar 2018, 20:34:46
Klar ;), aber immerhin liegt der "DOIF-Interpreter" drüber.
Ist genau dann ein Problem, wenn:doppelte hier nicht gehen, aber einfache oder Slashs eine Fehlermeldung
DOIF: wrong filter Regex: /[^\:]*
im Editor erzeugen.
ZitatIst genau dann ein Problem, wenn:
Ab dort, konnte ich Deiner Argumentation nicht mehr folgen.
Zitat von: Damian am 05 Januar 2016, 15:01:28Es sind z. Zt. übrigens nur 5 % der gesamten Commandref
Wie ist eigentlich der Stand jetzt?
Zitat von: Per am 04 April 2018, 11:18:29
Wie ist eigentlich der Stand jetzt?
Das kannst du selbst überprüfen. Die Commandref wird sicherlich immer weiter wachsen, ich versuche den Anteil gleich zu halten, Stichwort: uiTable, Perl-Modus ;)
Hallo,
kann mir jmd. bzgl. der Funktion den Unterschied zwischen
["^steuerung$:^b1:.push"]
und
["^steuerung$:^b1:.push$"]
erklären?
Gruß Chris
Zitat von: chq am 11 April 2019, 12:14:33
Hallo,
kann mir jmd. bzgl. der Funktion den Unterschied zwischen
["^steuerung$:^b1:.push"]
und
["^steuerung$:^b1:.push$"]
erklären?
Gruß Chris
Im ersten Fall darf noch etwas nach "push" kommen, beim zweiten nicht, da muss der Ausdruck mit "push" enden.
Hi,
kurze Frage, ich überleg schon die ganze Zeit finde aber keine wirkliche Lösung...
Ich nutze folgendes DOIF
([16:00-22:00] and [BM_Garage04:luminance] < 100) (set Aussenbeleuchtung on-for-timer 7200) DOELSE (set Aussenbeleuchtung off)
Das funktioniert auch soweit, aber es wirft einen kleinen Fehler und zwar folgenden:
2020.05.13 20:42:02 1: PERL WARNING: Argument "4906.7 Lux" isn't numeric in numeric lt (<) at (eval 691106) line 1.
2020.05.13 20:42:02 3: eval: doif_Aussenlicht_Timer: warning in condition c01
Der Grund ist ja, das das Event:
2020-05-14 15:54:42 ZWave BM_Garage04 luminance: 4653.4 Lux
keine Zahl ist.
Kann ich in der Bedingung schon irgendwie nur auf den ersten Teil des Events, quasi EVENTPART0 zugreifen?
Dann wäre es sauberer... FHEM versteht es trotzdem, aber es muss ja auch richtig sein...
VG
René
Nimm nach lumance :d dazu um die Zahlen zu extrahieren.
hehe, danke, hätte ich in der Referenz einen Block weiter gelesen da stands dann, aber ich bin da schon über alle Bsp. geflogen, ich habe den Wald echt nicht mehr gesehen :)
Sollte gehen, die Meldung im Log ist weg.
VG
Hallo,
warum wird mir hier für $DEVICE nichts ausgegeben ?
defmod di_Luftbefeuchter_Wasser DOIF ( ["^Luftbe:water"] ne "ok") ({prowl("Wassertank leer","Geraet:-> $DEVICE <-","1","T")})\
DOELSEIF ( ["^Luftbe:tank"] ne "installed") ({{ prowl("Wassertank fehlt","Geraet:-> $DEVICE <-","1","T")}})
attr di_Luftbefeuchter_Wasser do always
DOIF funktioniert, nur es wird kein Devicenamen übermittelt .
Vielen Dank für Eure Hife
Hallo zusammen,
ich habe Homematic Lichtschalter mit einer custom Firmware.
Internals:
DEF 4594A304
FUUID 5cb57029-f33f-357a-1f25-094fdc9b79ade7bf
NAME Lichtschalter_EG_Galerie
NOTIFYDEV global
NR 1100
NTFY_ORDER 50-Lichtschalter_EG_Galerie
STATE <div><img src="/fhem/images/default/li_wht_off.png"> current:1</div>
TYPE CUL_HM
chanNo 04
device Dev_Lichtschalter_Galerie
peerList self01,self02
Helper:
DBLOG:
current:
logdb:
TIME 1611296831.68698
VALUE 1
deviceMsg:
logdb:
TIME 1611296040.29848
VALUE off (to VCCU)
level:
logdb:
TIME 1611296040.29848
VALUE 0
pct:
logdb:
TIME 1611296040.29848
VALUE 0
state:
logdb:
TIME 1611296040.29848
VALUE off
timedOn:
logdb:
TIME 1611296040.29848
VALUE off
trigLast:
logdb:
TIME 1611295448.71501
VALUE fhem:02
READINGS:
2021-01-22 07:04:08 CommandAccepted
2020-10-12 10:15:51 cfgState ok
2021-01-22 07:27:11 current 1
2021-01-22 07:14:00 deviceMsg off (to VCCU)
2021-01-22 07:14:00 level 0 %
2021-01-22 07:14:00 pct 0
2021-01-22 05:18:29 peerList self01,self02
2021-01-22 07:14:00 recentStateType info
2021-01-22 07:14:00 state off
2021-01-22 07:14:00 timedOn off
2021-01-22 07:04:08 trigLast fhem:02
2020-08-05 13:20:36 trig_Lichtschalter_Galerie_SchalterO Short_0
2021-01-01 18:47:22 trig_Lichtschalter_Galerie_SchalterU Short_0
helper:
dlvl 00
dlvlCmd ++A0112302794594A30204000000
peerFriend peerSens,peerVirt
peerIDsState complete
peerOpt 3:remoteAndSwitch
regLst 1,3p
cmds:
TmplKey self01,self02:no:1611289109.92466
TmplTs 1611289109.92466
cmdKey 1:0:0::Dev_Lichtschalter_Galerie:F0A9:04:self01,self02
cmdLst:
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
eventL -peer- -cond-
eventS -peer- -cond-
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
inhibit [(on|{off})]
off noArg
on noArg
on-for-timer -ontime-
on-till -time-
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self04})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{self04})]
pressS [(-peer-|{self04})]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
sign [(on|{off})]
statusRequest noArg
toggle noArg
tplDel -tplDel-
tplSet_0 -tplChan-
tplSet_self01 -tplPeer-
tplSet_self02 -tplPeer-
lst:
condition slider,0,1,255
peer Names,Lichtschalter_EG_Galerie
peerOpt Bewegungsmelder_Eingang,Bewegungsmelder_Terasse,Bewegungsmelder_Terasse_kl,Dev_Garage_Zustand_Tr,FB_Bewaesserung_Garten_AUS,FB_Bewaesserung_Garten_EIN,FB_Bewaesserung_Vorgarten_AUS,FB_Bewaesserung_Vorgarten_EIN,Fenster_Ankleide,Fenster_Arbeitszimmer_gr,Fenster_Bad_oben,Fenster_Bad_unten,Fenster_Kueche,Fenster_Terasse_gr,Fenster_Terasse_kl,HM_51B37E_Btn_01,HM_51B37E_Btn_02,Haustuer,Lichtschalter2_KZ1_1,Lichtschalter2_KZ1_2,Lichtschalter2_KZ2_1,Lichtschalter2_KZ2_2,Lichtschalter_EZ_SchalterO,Lichtschalter_EZ_SchalterU,Lichtschalter_Galerie_SchalterO,Lichtschalter_Galerie_SchalterU,Lichtschalter_Kueche_SchalterO,Lichtschalter_Kueche_SchalterU,Multischalter_EG_Btn_01,Multischalter_EG_Btn_02,Multischalter_EG_Btn_03,Multischalter_EG_Btn_04,Multischalter_EG_Btn_05,Multischalter_EG_Btn_06,Multischalter_EG_Btn_07,Multischalter_EG_Btn_08,Multischalter_EG_Btn_09,Multischalter_EG_Btn_10,Multischalter_EG_Btn_11,Multischalter_EG_Btn_12,Multischalter_EG_Btn_13,Multischalter_EG_Btn_14,Multischalter_EG_Btn_15,Multischalter_EG_Btn_16,Multischalter_EG_Btn_17,Multischalter_EG_Btn_18,Multischalter_EG_Btn_19,Multischalter_EG_Btn_20,Steckdose_TV_SenF,Steckdose_TV_SenI,Steckdose_TV_SenPwr,Steckdose_TV_SenU,VCCU_Btn1,VCCU_Btn2,VCCU_Btn3,VCCU_Btn4,VCCU_Btn5,Zwischensteckdose_PC_SenF,Zwischensteckdose_PC_SenI,Zwischensteckdose_PC_SenPwr,Zwischensteckdose_PC_SenU
tplChan
tplDel
tplPeer SwCondAbove_long,SwOnCond_short,SwOff_short,SwOff_long,SwCondBelow_long,autoOff_long,SwToggle_long,SwOn_short,SwOn_long,SwOnCond_long,SwCondAbove_short,SwToggle_short,SwCondBelow_short,motionOnSw_long,autoOff_short,motionOnSw_short
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 1
raw 0
tpl 0
peerIDsH:
00000000 broadcast
4594A301 self01
4594A302 self02
role:
chn 1
tmpl:
Attributes:
expert defReg,allReg
group Licht
model HM-LC-Sw1PBU-FM-CustomFW
peerIDs 00000000,4594A301,4594A302
room 04_Licht
sortby 12
stateFormat {
my $state = ReadingsVal($name, "state", "off");
return '<div><img src="/fhem/images/default/li_wht_on.png">'.sprintf(" current:%.0f", ReadingsVal($name,"current",0)).'</div>' if($state eq "on");
return '<div><img src="/fhem/images/default/li_wht_off.png">'.sprintf(" current:%.0f", ReadingsVal($name,"current",0)).'</div>' if($state eq "off");
}
webCmd statusRequest:toggle:on:off
Dieser neigt sporadisch dazu den state nicht korrekt darzustellen.
Im device gibt es ein reading "current" dieses wird zyklisch ausgegeben und erzeugt auch Events:
2021-01-22 07:08:26 CUL_HM Lichtschalter_EG_Galerie on
2021-01-22 07:08:26 CUL_HM Lichtschalter_EG_Galerie timedOn: off
2021-01-22 07:08:31 CUL_HM Lichtschalter_EG_Galerie deviceMsg: off (to VCCU)
2021-01-22 07:08:31 CUL_HM Lichtschalter_EG_Galerie level: 0 %
2021-01-22 07:08:31 CUL_HM Lichtschalter_EG_Galerie pct: 0
2021-01-22 07:08:31 CUL_HM Lichtschalter_EG_Galerie off
2021-01-22 07:08:31 CUL_HM Lichtschalter_EG_Galerie timedOn: off
2021-01-22 07:08:39 CUL_HM Lichtschalter_EG_Galerie current: 100
2021-01-22 07:08:58 CUL_HM Lichtschalter_EG_Galerie current: 298
2021-01-22 07:09:17 CUL_HM Lichtschalter_EG_Galerie current: 310
2021-01-22 07:09:36 CUL_HM Lichtschalter_EG_Galerie current: 309
2021-01-22 07:09:55 CUL_HM Lichtschalter_EG_Galerie current: 310
2021-01-22 07:10:13 CUL_HM Lichtschalter_EG_Galerie current: 309
2021-01-22 07:10:32 CUL_HM Lichtschalter_EG_Galerie current: 310
2021-01-22 07:10:51 CUL_HM Lichtschalter_EG_Galerie current: 310
2021-01-22 07:11:10 CUL_HM Lichtschalter_EG_Galerie current: 310
2021-01-22 07:11:29 CUL_HM Lichtschalter_EG_Galerie current: 311
2021-01-22 07:11:48 CUL_HM Lichtschalter_EG_Galerie current: 311
2021-01-22 07:12:07 CUL_HM Lichtschalter_EG_Galerie current: 311
2021-01-22 07:12:25 CUL_HM Lichtschalter_EG_Galerie current: 311
2021-01-22 07:12:44 CUL_HM Lichtschalter_EG_Galerie current: 312
2021-01-22 07:13:04 CUL_HM Lichtschalter_EG_Galerie current: 312
2021-01-22 07:13:22 CUL_HM Lichtschalter_EG_Galerie current: 311
Nun dachte ich, es kann ja kein Hexenwerk mit den Daten und einem DOIF den state zu korrigieren, gesagt getan:
Internals:
DEF (["^Lichtschalter_EG:current"] < 50 and [?$DEVICE:state] eq "on")
(set $DEVICE off)
DOELSEIF
(["^Lichtschalter_EG:current"] > 100 and [?$DEVICE:state] eq "off")
(set $DEVICE on)
FUUID 5cb57024-f33f-357a-d9c0-fc7201f8de05324b
MODEL FHEM
NAME di.Lichtschalter_EG_Zustandskorrektur
NOTIFYDEV Lichtschalter_EG.*,global
NR 100
NTFY_ORDER 50-disabl.di.Lichtschalter_EZ_Zustandskorrektur
STATE initialized
TYPE DOIF
VERSION 23466 2021-01-03 17:14:46
READINGS:
2021-01-22 07:13:04 Device Lichtschalter_EG_Galerie
2021-01-22 07:12:19 cmd 0
2021-01-22 07:12:19 mode enabled
2021-01-22 07:12:19 state initialized
Regex:
accu:
cond:
:
0:
"^Lichtschalter_EG:current" ^Lichtschalter_EG:current
1:
"^Lichtschalter_EG:current" ^Lichtschalter_EG:current
attr:
cmdState:
wait:
0:
30
1:
30
waitdel:
condition:
0 ::EventDoIf('^Lichtschalter_EG',$hash,'current',0) < 50 and ::ReadingValDoIf($hash,'$DEVICE','state') eq "on"
1 ::EventDoIf('^Lichtschalter_EG',$hash,'current',0) > 100 and ::ReadingValDoIf($hash,'$DEVICE','state') eq "off"
do:
0:
0 set $DEVICE off
1:
0 set $DEVICE on
2:
helper:
DEVFILTER ^global$|^Lichtschalter_EG
NOTIFYDEV global|Lichtschalter_EG.*
event current: 312
globalinit 1
last_timer 0
sleeptimer -1
triggerDev Lichtschalter_EG_Galerie
triggerEvents:
current: 312
triggerEventsState:
current: 312
internals:
readings:
trigger:
uiState:
uiTable:
Attributes:
DbLogExclude .*
disable 0
do always
group Licht_Automatisierung
icon helper_doif
room 04_Licht
sortby 64
verbose 5
wait 30:30
leider funktioniert es nicht so wie ich mir vorstelle, siehe Eventmonitor log, der state ist off, current ist >> 100 und das DOIF tut nichts.
cmd1 scheint halbwegs zu funktionieren, cmd2 bekomme ich einfach nicht aktiviert
Ich komme hier leider nicht weiter und hoffe hier Hilfe zu finden.
Gruß
Alex
Hallo,
ich verstehe das so: dein Trigger ["^Lichtschalter_EG:current"] < 50 macht nicht das, was Du willst. Du triggerst nur auf den Event "current", der Vergleich findet nicht statt. Genauer: der Teil in eckigen Klammern liefert nur wahr zum Zeitpunkt, wenn er eintritt: alle Devices die mit Lichtschalter_EG beginnen und current im Reading vorkommt. Entweder Du triggerst auf den Zustand:
[Lichtschalter_EG:current] < 50
oder Du must den Event-Trigger anders schreiben:
aus der cref:
Allgemeine Ereignistrigger können ebenfalls so definiert werden, dass sie nicht nur wahr zum Triggerzeitpunkt und sonst nicht wahr sind, sondern Inhalte des Ereignisses zurückliefern. Initiiert wird dieses Verhalten durch die Angabe eines Default-Wertes.
Syntax:
["regex for trigger",<default value>]
Anwendungsbeispiel:
define di_warning DOIF ([":^temperature",0]< 0) (set pushmsg danger of frost $DEVICE)
attr di_warning do always
Viel Erfolg!
Hallo auch von mir,
ich weiß, das ist schon ein älterer Fred, allerdings passt es genau hierher und meine Frage ist identisch wie diese:
Zitat von: Freibeuter am 18 Januar 2021, 15:01:55
Hallo,
warum wird mir hier für $DEVICE nichts ausgegeben ?
defmod di_Luftbefeuchter_Wasser DOIF ( ["^Luftbe:water"] ne "ok") ({prowl("Wassertank leer","Geraet:-> $DEVICE <-","1","T")})\
DOELSEIF ( ["^Luftbe:tank"] ne "installed") ({{ prowl("Wassertank fehlt","Geraet:-> $DEVICE <-","1","T")}})
attr di_Luftbefeuchter_Wasser do always
DOIF funktioniert, nur es wird kein Devicenamen übermittelt .
Vielen Dank für Eure Hife
und leider gab es hierzu keine Antwort. Ich meine das hat mal funktioniert...
Verallgemeinert: für DOIF, sollte $DEVICE den Namen des auslösenden Gerätes zurückliefern?
Und $EVENT, bzw. $EVENTS die dazugehörigen Ereignisse?
Danke und VG - Speedy
Zitat von: Speedy am 26 Oktober 2022, 14:42:15
Hallo auch von mir,
ich weiß, das ist schon ein älterer Fred, allerdings passt es genau hierher und meine Frage ist identisch wie diese:
und leider gab es hierzu keine Antwort. Ich meine das hat mal funktioniert...
Verallgemeinert: für DOIF, sollte $DEVICE den Namen des auslösenden Gerätes zurückliefern?
Und $EVENT, bzw. $EVENTS die dazugehörigen Ereignisse?
Danke und VG - Speedy
$DEVICE, $EVENT bzw. $EVENTS ist im FHEM-Modus ein Platzhalter und wird beim Trigger eines Devices entsprechend ersetzt.
Im Perl-Modus gibt zusätzlich auch die Perlvariable $device, $event bzw. $events.
Bei Zeittriggern werden diese natürlich nicht belegt.
Hallo Damian,
das ist bekannt und wird von mir - und offensichtlich auch vom initialen Fragensteller - genauso eingesetzt. Leider werden im FHEM-Modus diese Platzhalter bei mir nicht mehr richtig belegt. Ich versuche morgen/übermorgen ein Beispiel zu bauen und das hier zu posten.
Vielen Dank für die schnelle Antwort!
Zitat von: Speedy am 26 Oktober 2022, 18:57:15
Hallo Damian,
das ist bekannt und wird von mir - und offensichtlich auch vom initialen Fragensteller - genauso eingesetzt. Leider werden im FHEM-Modus diese Platzhalter bei mir nicht mehr richtig belegt. Ich versuche morgen/übermorgen ein Beispiel zu bauen und das hier zu posten.
Vielen Dank für die schnelle Antwort!
Dann warte ich auf das Beispiel, welches nicht funktioniert.
Sorry, war leider etwas ausser Gefecht.
Beim Erstellen des Beispiels auf meinem Test-FHEM konnte ich den Fehler replizieren, allerdings ist auch klar geworden, dass die Befüllung der Platzhalter $DEVICE, $EVENT bzw. $EVENTS weiterhin funktioniert!
Es lag an den doppelten eckigen Klammern, die ich seit Jahr und Tag zur besseren Lesbarkeit um die Platzhalter setze. Nehme ich diese weg, klappt es auch wieder. Allerdings ist es tatsächlich so, daß sich hier irgendetwas geändert hat, denn das hat nachweislich vorher lange Zeit funktioniert. Nun ja - es gibt einen Workaround mit den Leerzeichen, den ich nun eben nutzen werde.
Als Beispiel ein DOIF "di" das durch ein anderes Device getriggert, ein eigenes Reading setzt:
Internals:
CFGFN
DEF ##
(["^Luftbe:water"] ne "ok") (
setreading $SELF UR_device_bislang_doppelt "triggered: [[$DEVICE]] ",
setreading $SELF UR_device_ohne "triggered: $DEVICE",
setreading $SELF UR_device_einfach "triggered: [$DEVICE]",
setreading $SELF UR_device_einfach_Abstand "triggered: [ $DEVICE ]"
)
DOELSE
FUUID 635a2919-f33f-b86d-7b88-58d2af51c69b5502
MODEL FHEM
NAME di
NOTIFYDEV global,.*(^Luftbe).*
NR 58
NTFY_ORDER 50-di
STATE cmd_1
TYPE DOIF
VERSION 26444 2022-09-25 16:29:19
eventCount 94
OLDREADINGS:
READINGS:
2022-11-06 15:26:28 Device Luftbefeuchter
2022-11-06 15:26:28 UR_device_bislang_doppelt "triggered: [???] "
2022-11-06 15:26:28 UR_device_einfach "triggered: ???"
2022-11-06 15:26:28 UR_device_einfach_Abstand "triggered: [ Luftbefeuchter ]"
2022-11-06 15:26:28 UR_device_ohne "triggered: Luftbefeuchter"
2022-11-06 15:26:28 cmd 1
2022-11-06 15:26:28 cmd_event Luftbefeuchter
2022-11-06 15:26:28 cmd_nr 1
2022-11-06 15:25:34 mode enabled
2022-11-06 15:26:28 state cmd_1
Regex:
accu:
collect:
cond:
:
0:
"^Luftbe:water" ^Luftbe:water
attr:
cmdState:
wait:
waitdel:
condition:
0 ::EventDoIf('^Luftbe',$hash,'water',0) ne "ok"
do:
0:
0 setreading di UR_device_bislang_doppelt "triggered: [[$DEVICE]] ", setreading di UR_device_ohne "triggered: $DEVICE", setreading di UR_device_einfach "triggered: [$DEVICE]", setreading di UR_device_einfach_Abstand "triggered: [ $DEVICE ]"
1:
0
helper:
NOTIFYDEV global,.*(^Luftbe).*
event water: ok
globalinit 1
last_timer 0
sleeptimer -1
timerdev Luftbefeuchter
timerevent water: ok
triggerDev Luftbefeuchter
DOIF_eventa:
cmd_nr: 1
cmd: 1
cmd_event: Luftbefeuchter
cmd_1
DOIF_eventas:
cmd_nr: 1
cmd: 1
cmd_event: Luftbefeuchter
state: cmd_1
timerevents:
water: ok
timereventsState:
water: ok
triggerEvents:
water: ok
triggerEventsState:
water: ok
internals:
readings:
trigger:
uiState:
uiTable:
Attributes:
do always
Danke trotzdem für die Hilfe!
Wenn es mit der Doppelklammer funktioniert hatte, dann zufällig. Eckige Klammern sind ja bei DOIF reserviert und haben bestimmte Bedeutung:
[[$DEVICE]] das ist eine indirekte Zeitangabe
[$DEVICE] das ist der STATUS von $DEVICE
Danke Damian - wieder was gelernt!
VG - Speedy
Ich wollte kein neues Thema aufmachen, zumal es hier gut reinpasst.
Eine gute Ergänzung zu $DEVICE und $EVENT empfände ich $VALUE, eine Variable, welche ausschließlich den Wert des Events beinhaltet. Vllt noch ein $VALUED (was sinnvolleres ist mir gerade nicht eingefallen) mit nur dem Zahlenwert.
Ob ein $READING nötig ist, weiß ich nicht, würde wahrscheinlich aber gleich mit abfallen, ob eine Unterscheidung zu Iternals oder so möglich/notwendig ist, müsste man dann sehen. Oder einen besseren Namen vergeben (auch wenn es zu 99% Readings sein werden).
Nicht jedes Event muss ein Reading beinhalten. Man kann sich das Reading bzw. Value auch selber basteln:
my($reading,$value)=split(": |,","$EVENT");
oder
my($reading,$value)=split(": |,",$event);
Dass das geht, war mir klar, auch wenn es bei mir nicht sooo kompakt geworden wäre.
Allerdings fände ich eine "interne" Erzeugung eleganter, gerade für den DOIF Mode.
Zitat von: Per am 18 Oktober 2023, 23:39:56Dass das geht, war mir klar, auch wenn es bei mir nicht sooo kompakt geworden wäre.
Allerdings fände ich eine "interne" Erzeugung eleganter, gerade für den DOIF Mode.
ja, allerdings werden im $EVENT ggf. mehrere Reading mit Komma getrennt abgelegt, wenn sie in einem gemeinsamen Event-Block liegen und dann hat man evtl. das falsche Reading (falschen Wert), nämlich das erste des Eventblocks
Wenn ein Timer der Trigger ist, hat man mit $DEVICE auch ein Problem. Und bei mehreren Readings hat man mit der split-Methode auch ein Problem. Ohne "Eigenverantwortung" kommt man so oder so nicht aus.
BTW: kann man mit [$DEVICE:reading] oder [$device:reading] bzw [$_:reading] auch im Perl-Mode im Ausführungsteil arbeiten? Ich bekomme bei den verschiedenen Versuchen entweder eine Fehlermeldung oder "komische" Werte ("HASH(xxxxxx)"...). Mit ReadingsVal geht es natürlich, ist aber viel umständlicherer Code.
Zitat von: Per am 21 Oktober 2023, 22:59:47Wenn ein Timer der Trigger ist, hat man mit $DEVICE auch ein Problem. Und bei mehreren Readings hat man mit der split-Methode auch ein Problem. Ohne "Eigenverantwortung" kommt man so oder so nicht aus.
BTW: kann man mit [$DEVICE:reading] oder [$device:reading] bzw [$_:reading] auch im Perl-Mode im Ausführungsteil arbeiten? Ich bekomme bei den verschiedenen Versuchen entweder eine Fehlermeldung oder "komische" Werte ("HASH(xxxxxx)"...). Mit ReadingsVal geht es natürlich, ist aber viel umständlicherer Code.
Also $DEVICE wird konsequent im Perl- und FHEM-Modus durch das triggernde Device ersetzt. Daher ist [$DEVICE:reading] die optimale Lösung, um aus einem allgemeinen Event-Trigger den Inhalt eines bestimmten Readings in beiden Modi zu erhalten. Das ist auch so beabsichtigt und im Modul programmiert.
Daher ist es nicht unbedingt sinnvoll noch mehr Platzhalter wie z. B. $READING einzubauen. Denn solche Platzhalter wie z. B. $DEVICE oder eben $READING müssen bei jedem Trigger im Code durchsucht und ersetzt werden. Das kostet unnötig Performance insb. für die, die es nicht brauchen.
Und Teil 2 des Postes?
Zitat von: Per am 22 Oktober 2023, 23:17:11Und Teil 2 des Postes?
Was ist damit?
[$DEVICE:reading] geht, die anderen nicht. Zu bedenken ist, dass im Perlmodus eine Perlfunktion an dieser Stelle eingesetzt wird, im FHEM-Modus wird dagegen der Wert selbst eingestellt.
Hallo @all,
ich buddel das hier noch Mal aus, da ich $EVENT gern verwenden möchte und mein Problem (meine Meinung) hier sehr gut zum Tread passt!?
Es geht um meinen Bewegungsmelder (BM): https://forum.fhem.de/index.php?msg=1241211 der leider einen Schönheitsfehler hat. Obwohl niemand mehr in der Küche ist, wird das Licht ab und an Mal eingeschaltet. Inzwischen sind 3 BM verbaut und als Event werden von: "presence/occupancy" "true" und "false" gefeuert.
Die TRADFRI (IKEA) und Lidl BM melden teilweise erst 90 Sekunden später, dass keine Bewegung mehr festgestellt wurde und wenn das doif bei dem "false" Event prüft, ist einer von den "langsamen" BM manchmal immer noch "true" und das doif schaltet das Licht wieder an.
Ich möchte jetzt nur noch reagieren, wenn "true" gefeuert wird, finde aber auch nach mehreren Tagen Suche kein Beispiel. Leider verstehe ich auch die Logik hinter $EVENT / $EVENT
S nicht und das trifft bei mir auch noch zu:
Zitat von: Damian am 19 Oktober 2023, 22:21:46ja, allerdings werden im $EVENT ggf. mehrere Reading mit Komma getrennt abgelegt, wenn sie in einem gemeinsamen Event-Block liegen und dann hat man evtl. das falsche Reading (falschen Wert), nämlich das erste des Eventblocks
Log Auszug:
2024.10.08 23:13:20.689 1: event: presence: true
2024.10.08 23:13:20.690 1: events: presence: true
2024.10.08 23:13:20.690 1: gesplittet: presence, true - Das Device: MQTT2_OMG_Kueche
2024.10.08 23:13:21.914 1: event: presence: false
2024.10.08 23:13:21.914 1: events: presence: false
2024.10.08 23:13:21.915 1: gesplittet: presence, false - Das Device: MQTT2_OMG_Kueche
2024.10.08 23:13:24.680 1: event: batteryPercent: 60,occupancy: false
2024.10.08 23:13:24.680 1: events: batteryPercent: 60,occupancy: false
2024.10.08 23:13:24.680 1: gesplittet: batteryPercent, 60 - Das Device: MQTT2_zigbee_TRADFRI_MotionSensor1
2024.10.08 23:14:21.838 1: event: occupancy: false,last_seen: 2024-10-08T23:14:21+02:00
2024.10.08 23:14:21.838 1: events: occupancy: false,last_seen: 2024-10-08T23:14:21+02:00
2024.10.08 23:14:21.839 1: gesplittet: occupancy, false - Das Device: MQTT2_zigbee_Lidl_BWM_1
2024.10.08 23:16:27.084 1: event: occupancy: true,last_seen: 2024-10-08T23:16:27+02:00,batteryPercent: 60
2024.10.08 23:16:27.084 1: events: occupancy: true,last_seen: 2024-10-08T23:16:27+02:00,batteryPercent: 60
2024.10.08 23:16:27.084 1: gesplittet: occupancy, true - Das Device: MQTT2_zigbee_TRADFRI_MotionSensor1
2024.10.08 23:16:32.029 1: event: last_seen: 2024-10-08T23:16:31+02:00,occupancy: true
2024.10.08 23:16:32.030 1: events: last_seen: 2024-10-08T23:16:31+02:00,occupancy: true
2024.10.08 23:16:32.030 1: gesplittet: last_seen, 2024-10-08T23:16:31+02:00 - Das Device: MQTT2_zigbee_Lidl_BWM_1
2024.10.08 23:16:37.089 1: event: occupancy: false,batteryPercent: 60
2024.10.08 23:16:37.089 1: events: occupancy: false,batteryPercent: 60
2024.10.08 23:16:37.089 1: gesplittet: occupancy, false - Das Device: MQTT2_zigbee_TRADFRI_MotionSensor1
2024.10.08 23:17:33.923 1: event: presence: true
2024.10.08 23:17:33.923 1: events: presence: true
2024.10.08 23:17:33.924 1: gesplittet: presence, true - Das Device: MQTT2_OMG_Kueche
2024.10.08 23:17:35.163 1: event: presence: false
2024.10.08 23:17:35.163 1: events: presence: false
2024.10.08 23:17:35.163 1: gesplittet: presence, false - Das Device: MQTT2_OMG_Kueche
2024.10.08 23:17:39.715 1: event: occupancy: false,last_seen: 2024-10-08T23:17:39+02:00
2024.10.08 23:17:39.716 1: events: occupancy: false,last_seen: 2024-10-08T23:17:39+02:00
2024.10.08 23:17:39.716 1: gesplittet: occupancy, false - Das Device: MQTT2_zigbee_Lidl_BWM_1
In dem doif habe ich die Log Ausgabe rein gebastelt, darum stelle ich es hier mal als RAW rein:
defmod doif_BM_Kueche DOIF {\
Log 1, " event: $event";;\
Log 1, " events: $events";;\
# my $Ereignis = $events;; # neuer Test\
# my $Ereignis = $EVENT;; # funktioniert nicht?\
my($reading,$value)=split(": |,",$event);;\
Log 1, "gesplittet: $reading, $value - Das Device: $DEVICE";;\
# Log 1, "Das Device hat ausgelöst: $DEVICE - Der Event sah so aus: $EVENT";;\
if (([MQTT2_OMG_Kueche:presence] eq "true" or [MQTT2_zigbee_TRADFRI_MotionSensor1:occupancy] eq "true" or [MQTT2_zigbee_Lidl_BWM_1:occupancy] eq "true") and ([?MQTT2_OMG_Kueche:lux:d] < 50) and [?Automatik] eq "on" ) {\
# Es rennt jemand rum, es ist zu dunkel und ich soll was tun!\
if ([?TasmStd_8A9714_LichtKueche:state] eq "on") { # Das Licht ist schon an!\
if (get_Exec("BM_Kueche_off") > 0) { # Gibt es auch einen Timer?\
set_Reading("IchWars","on");; # Dann war ich das!\
}\
else { # Timer ist abgelaufen, ich hab das Licht nicht eingeschaltet!\
set_Reading("IchWars","off");; # Merker zurück setzen.\
# eine halben Stunde ohne Bewegung, bestimmt vergessen Licht auszuschalten. \
set_Exec("BM_Kueche_long_off",1800,'fhem_set("TasmStd_8A9714_LichtKueche off")');;\
}\
}\
else { # Licht ist aus -> einschalten.\
fhem_set("TasmStd_8A9714_LichtKueche on");;\
Log("3", "Küche: Bewegungsmelder hat Licht angeschaltet!");;\
set_Reading("IchWars","on");; # Merker setzen, das das DOIF geschaltet hat\
}\
if (get_Reading("IchWars") eq "on") { # Da ich das war, Ausschalttimer setzen\
if ([?MQTT2_myMQTT2Client:LutzesPC] eq "present") { # der Rechner läuft, langer Timer\
set_Exec("BM_Kueche_off",[?$SELF:work],'fhem_set("TasmStd_8A9714_LichtKueche off")');;\
Log("3", "Küche: Bewegungsmelder: Der Rechner läuft, langer Timer!");;\
set_State("Timer:Work");;\
}\
elsif ([?shelly3em:emeter_1_power] > 5) { # Herd ist an / kochen, normaler Timer\
set_Exec("BM_Kueche_off",[?$SELF:food],'fhem_set("TasmStd_8A9714_LichtKueche off")');;\
Log("3", "Küche: Bewegungsmelder: Es wird gekocht, Licht Kochzeit an!");;\
set_State("Timer:Food");;\
}\
elsif ([?22:00-09:00]) { # In der Nacht, alle schlafen, kurzer Timer\
set_Exec("BM_Kueche_off",[?$SELF:night],'fhem_set("TasmStd_8A9714_LichtKueche off")');;\
Log("3", "Küche: Bewegungsmelder: Bewohner schlafen, Licht kurz an!");;\
set_State("Timer:Night");;\
}\
else {\
set_Exec("BM_Kueche_off",[?$SELF:default],'fhem_set("TasmStd_8A9714_LichtKueche off")');;\
Log("3", "Küche: Bewegungsmelder: Nichts los, Licht normal an!");;\
set_State("Timer:Default");;\
}\
}\
}\
}\
attr doif_BM_Kueche DbLogExclude .*
attr doif_BM_Kueche alias doif_BM_Kueche
attr doif_BM_Kueche event-on-change-reading .*
attr doif_BM_Kueche group Bewegungsmelder
attr doif_BM_Kueche icon motion_detector
attr doif_BM_Kueche readingList state work food night default
attr doif_BM_Kueche room Geräte->Virtuell,Zimmer->Küche
attr doif_BM_Kueche setList work:slider,0,10,1800 food:slider,0,5,600 night:slider,0,1,60 default:slider,0,10,300
attr doif_BM_Kueche verbose 5
attr doif_BM_Kueche webCmd work:food:night:default
setstate doif_BM_Kueche initialized
setstate doif_BM_Kueche 2024-10-09 00:19:45 Device MQTT2_OMG_Kueche
setstate doif_BM_Kueche 2024-10-09 00:19:43 IchWars off
setstate doif_BM_Kueche 2024-10-09 00:19:45 block_01 executed
setstate doif_BM_Kueche 2023-11-28 02:48:27 default 80
setstate doif_BM_Kueche 2024-10-09 00:19:45 e_MQTT2_OMG_Kueche_presence false
setstate doif_BM_Kueche 2024-10-08 23:53:15 e_MQTT2_zigbee_Lidl_BWM_1_occupancy false
setstate doif_BM_Kueche 2024-10-08 23:52:15 e_MQTT2_zigbee_TRADFRI_MotionSensor1_occupancy false
setstate doif_BM_Kueche 2022-10-23 02:28:07 food 450
setstate doif_BM_Kueche 2024-10-08 23:12:52 mode enabled
setstate doif_BM_Kueche 2021-11-15 02:37:25 motion detect
setstate doif_BM_Kueche 2023-11-28 03:05:24 night 40
setstate doif_BM_Kueche 2024-10-08 23:12:53 state initialized
setstate doif_BM_Kueche 2024-10-08 23:12:53 timer_01_c01 09.10.2024 22:00:00
setstate doif_BM_Kueche 2024-10-08 23:12:53 timer_02_c01 09.10.2024 09:00:00
setstate doif_BM_Kueche 2024-10-09 00:19:43 timer_BM_Kueche_long_off 09.10.2024 00:49:43
setstate doif_BM_Kueche 2023-09-19 19:34:42 work 600
Ich hoffe, keinen neuen Traed aufgemacht zu haben, ist OK? Ich finde mein Problem hier echt dazu passend.
Herzliche Grüße, Lutz
Dann antworte ich mir mal selber. Mit "index" scheint es zu funktionieren:
defmod doif_BM_Kueche DOIF {\
if (index($event, "occupancy: true") != -1 or index($event, "presence: true") != -1) {\
Log 1, " event: $event - TRUE";;\
}\
else {\
Log 1, " event: $event - FALSE";;\
}\
[...]
Gruß Lutz