neue Features: defaultvalue, readingList, Ereignisfilter, Attribut checkall

Ellert · 10 Dezember 2016, 17:37:36

Über den Namen des DOIF damit man sieht, was im DOIF passiert.

Hiermit

define schrittSchalter_Labor001 DOIF ## 1 
(["button_Labor000:short"] and $cmd=~"0|4") 
   (set lamp1_Labor000 on) 
## 2 
DOELSEIF (["button_Labor000:short"] and $cmd==1) 
   (set lamp2_Labor000 on, set lamp1_Labor000 off) 
## 3 
DOELSEIF (["button_Labor000:short"] and $cmd==2) 
   (set lamp(1|2)_Labor000 on) 
## 4 
DOELSEIF (["button_Labor000:short"] and $cmd==3) 
   (set lamp(1|2)_Labor000 off) 
attr schrittSchalter_Labor001 alias Schrittschalter 
attr schrittSchalter_Labor001 cmdState Schritt 1|Schritt 2|Schritt 3|Schritt 4 
attr schrittSchalter_Labor001 group Labor: Mehrfachnutzung eines Tasters 
attr schrittSchalter_Labor001 room DOIF_Labor

sieht es dann so aus:

Damian · 10 Dezember 2016, 18:08:25

ja, ich bin etwas hin- und hergerissen. Auf der einen Seite hast du eine sehr komfortable Lösung in der ersten Version programmiert mit Zugriff auf andere Module (Logfile), auf der anderen Seite diese ohne Zugriff aber nicht so User-freundlich.

Übrigens funktioniert die Sache mit Ereignisdefinitionen der Art "<device>:<ereignis>" nicht richtig. Die Regex müsste eher heißen .*<device>.*:.*<ereignis>.* dafür bekommt du wieder Probleme bei "^<device>..." . Es ist alles nicht so einfach.

Da ich anders bei den globalen Ereignis-Triggern der Art "<device>:<event>" bei der Regex vorgehe als Logfile, könnte man sich damit ein Ei legen. Weil irgendetwas nicht richtig funktionieren wird und dann sind wir nur am nachbessern.

Auf der anderen Seite sollte jeder in der Lage sein ein Logfile zu erzeugen, indem auf alle Devices mit allen möglichen Events (.*) getriggert wird, die im DOIF vorkommen, denn darauf wird es vermutlich hinauslaufen. Dann hat man zumindest nicht den schwarzen Peter in der Hand, wenn etwas nicht funktioniert.

Ellert · 10 Dezember 2016, 19:17:48

Bei der Umsetzung der Regexp habe ich nachgebessert.

testdi kommt aus $hash->{devices}{all} und wird zu testdi:.* (das ist auch der DOIF-Name)
alles Andere kommt aus $hash->{regexp}{all}{$i} bis auf .*.* sieht alles gut aus. .*.* schadet nicht ist aber licht zu filtern.

Ich tendiere zunehmend zum Einbau der Lösung, die dem User mehr Spielraum und Verantwortung lässt. Denn mit Raw definition ist die Definition auch schnell angelegt und über defmod upgedated. Mehr kann man immer noch einbauen.

Damian · 10 Dezember 2016, 19:38:35

Zitat von: Ellert am 10 Dezember 2016, 19:17:48
Bei der Umsetzung der Regexp habe ich nachgebessert.

testdi kommt aus $hash->{devices}{all} und wird zu testdi:.* (das ist auch der DOIF-Name)
alles Andere kommt aus $hash->{regexp}{all}{$i} bis auf .*.* sieht alles gut aus. .*.* schadet nicht ist aber licht zu filtern.

Ich tendiere zunehmend zum Einbau der Lösung, die dem User mehr Spielraum und Verantwortung lässt. Denn mit Raw definition ist die Definition auch schnell angelegt und über defmod upgedated. Mehr kann man immer noch einbauen.

Was passiert bei "^mydevice$:^event$" ?

Ellert · 10 Dezember 2016, 20:53:41

Ich habe den Filter nochmal umgebaut, jetzt sieht es gut aus, aber ich bin kein Regexperte und von Sternen und Punkten habe ich langsam die Nase voll

Das hier

Code Auswählen

define testdi DOIF ([testdi:my] or [""] or [":1"] or ["di:2"] or ["^testdi$:^my: 3$"])
ergibt

Code Auswählen

testdi:my: 3|testdi:.*|.*:.*1.*|.*|.*di.*:.*2.*

Ich sehe gerade dass ": " noch durch ".." ersetzt werden muss.

Damian · 10 Dezember 2016, 21:10:59

Zitat von: Ellert am 10 Dezember 2016, 20:53:41
Ich habe den Filter nochmal umgebaut, jetzt sieht es gut aus, aber ich bin kein Regexperte und von Sternen und Punkten habe ich langsam die Nase voll

Das hier
Code Auswählen Erweitern
define testdi DOIF ([testdi:my] or [""] or [":1"] or ["di:2"] or ["^testdi$:^my: 3$"])
ergibt
Code Auswählen Erweitern
testdi:my: 3|testdi:.*|.*:.*1.*|.*|.*di.*:.*2.*

Ich sehe gerade dass ": " noch durch ".." ersetzt werden muss.

Wenn wir es einchecken, dann übernimmst du bitte die Verantwortung/Pflege, denn ich bin mir sicher, dass wir noch diverse Sachen übersehen haben - es ist ein heißes Eisen

Wir sollten noch ein paar Nächte drüber schlafen

Zum ausgebiegem Testen komme ich leider z. Zt. nicht.

JoeALLb · 11 Dezember 2016, 15:44:36

Wer verwalteet eigentlich das DOIF-Labor im Wiki?
ICh hätte da einen vereinfachungsvorschlag, will das aber nicht einfach abändern...

Ellert · 11 Dezember 2016, 16:50:18

Zitat von: JoeALLb am 11 Dezember 2016, 15:44:36
Wer verwalteet eigentlich das DOIF-Labor im Wiki?
ICh hätte da einen vereinfachungsvorschlag, will das aber nicht einfach abändern...

Das mache ich, was ist Dein Vorschlag?

Ellert · 11 Dezember 2016, 19:51:56

Zitat von: Damian am 10 Dezember 2016, 18:08:25
Auf der anderen Seite sollte jeder in der Lage sein ein Logfile zu erzeugen, indem auf alle Devices mit allen möglichen Events (.*) getriggert wird, die im DOIF vorkommen, denn darauf wird es vermutlich hinauslaufen. Dann hat man zumindest nicht den schwarzen Peter in der Hand, wenn etwas nicht funktioniert.

Ich dachte zunächst, dass es einfach sein müsste die DOIF Regexp-Regeln auf FileLog zu übersetzen. Inzwischen sehe ich es anders, es bleiben nur die Devices, die man automatisiert angeben könnte, so wie Du geschrieben hast. Dafür benötigt man eigentlich keine aufbereitete Anzeigemöglichkeit, also sollten wir es lassen.

Damian · 11 Dezember 2016, 20:11:27

Zitat von: Ellert am 11 Dezember 2016, 19:51:56
Ich dachte zunächst, dass es einfach sein müsste die DOIF Regexp-Regeln auf FileLog zu übersetzen. Inzwischen sehe ich es anders, es bleiben nur die Devices, die man automatisiert angeben könnte, so wie Du geschrieben hast. Dafür benötigt man eigentlich keine aufbereitete Anzeigemöglichkeit, also sollten wir es lassen.

So habe ich es schon vorhergesehen

Es kann trotzdem nicht schaden irgendwo im Wiki, wenn es da nicht schon drin steht, die Vorgehensweisen zum erforderlichen Loggen für eine Analyse zu beschreiben.

JoeALLb · 12 Dezember 2016, 09:58:20

Zitat von: Ellert am 11 Dezember 2016, 16:50:18
Das mache ich, was ist Dein Vorschlag?

Interessant, dass wir beide fast die selbe Lösung uns ausgedacht haben.
Ich arbeite bei den datepicker-widget weniger mit userreadings, stattdessen
speichere ich das komplette Datum in den readings on|off.

Um den Einschalt/Ausschalt-Trigger auszulösen, habe ich im DOIF lediglich diese Zeile, was es meiner Meinung nach kürzer/übersichtliche rmacht als mit den Userreadings...
Daher nur als Vorschlag:

Code Auswählen

[[$SELF:on:"(\d\d:\d\d)","00:00"]] and ([?$SELF:on:"(^\S*)\s"]== "$mday.$month.$year" ))
((bei deinem Beispiel wäre "on" natürlich mit "P_begin" zu ersetzen.))

Ellert · 12 Dezember 2016, 11:40:35

Zitat von: JoeALLb am 12 Dezember 2016, 09:58:20
Interessant, dass wir beide fast die selbe Lösung uns ausgedacht haben.
Ich arbeite bei den datepicker-widget weniger mit userreadings, stattdessen
speichere ich das komplette Datum in den readings on|off.

Um den Einschalt/Ausschalt-Trigger auszulösen, habe ich im DOIF lediglich diese Zeile, was es meiner Meinung nach kürzer/übersichtliche rmacht als mit den Userreadings...
Daher nur als Vorschlag:
Code Auswählen Erweitern
[[$SELF:on:"(\d\d:\d\d)","00:00"]] and ([?$SELF:on:"(^\S*)\s"]== "$mday.$month.$year" ))
((bei deinem Beispiel wäre "on" natürlich mit "P_begin" zu ersetzen.))

Das ist natürlich eine kürzere Variante, ich wollte in erster Linie zeigen, wie DOIF im Frontend ausehen kann.
Wenn Du Deinen Vorschlag einbauen möchtest, solltest Du nicht nur den Code und Text im Artikel ändern, sondern auch den Code in der Labor Übersichtsseite https://wiki.fhem.de/wiki/DOIF/Labor_-_ausf%C3%BChrbare,_praxisnahe_Beispiele_als_Probleml%C3%B6sung_zum_Experimetieren damit das gesamte Labor mit dem Artikel übereinstimmt.

Das mit dem == auch die führende 0 bei einstelligen Tagen und Monaten ignoriert wird, kannte ich noch nicht.

JoeALLb · 12 Dezember 2016, 12:08:26

Mir gefällt die Idee vom Labor ganz gut, aber vielleicht sollten wir extra fürs Labor einen eigenen Thread machen?

Ich hätte noch einen Vorschlag, um die Möglichkeiten mit DOIF zu zeigen:

Aber wie gesagt, da es deine Seiten sind, möchte ich mich da nicht zusehr einmichen...

Code Auswählen

([$SELF:P_weckzeit:sec]< 3)
  ## Aktiviert den Wecker automatisch, wenn eine neue Urzeit angegeben wird 
  (set $SELF P_einaus on )
DOELSEIF ([?$SELF:P_einaus,"off"] eq "on" and [[$SELF:P_weckzeit,"12:00"]])
  ##deaktiviert den Wecker, nachdem er ausgelöst wurde.
  (set $SELF P_einaus off)
  (## weitere Befehle)

Würde sich der Wecker direkt einschalten, sobald ich eine Uhrzeit abspeichere, und nach erfolgreichem Wecken würde er sich wieder deaktivieren.

Ellert · 12 Dezember 2016, 16:13:57

Die Seiten im Wiki sind für alle, da gibt es kein mein und dein und so lange alle Beiträge konstruktiv und stimmig bleiben ist das gut so.

Unter diesen Gesichtspunkten sollte es nicht notwendig sein, die Gestaltung der Wiki-Artikel zu diskutieren.

Dein Vorschlag folgt diesem Prinzip https://forum.fhem.de/index.php/topic,44715.msg365420.html#msg365420

und ist hier in abgewandelter Form beschrieben https://wiki.fhem.de/wiki/DOIF/Zeitgeber#Kurzzeitwecker

Das sollte Dich nicht davon abhalten einen Artikel über Deine Variante zu schreiben, das entscheidest Du.

Brockmann · 13 Dezember 2016, 08:14:46

Zitat von: JoeALLb am 12 Dezember 2016, 12:08:26
Code Auswählen Erweitern
([$SELF:P_weckzeit:sec]< 3) ## Aktiviert den Wecker automatisch, wenn eine neue Urzeit angegeben wird (set $SELF P_einaus on ) DOELSEIF ([?$SELF:P_einaus,"off"] eq "on" and [[$SELF:P_weckzeit,"12:00"]]) ##deaktiviert den Wecker, nachdem er ausgelöst wurde. (set $SELF P_einaus off) (## weitere Befehle)

Würde sich der Wecker direkt einschalten, sobald ich eine Uhrzeit abspeichere, und nach erfolgreichem Wecken würde er sich wieder deaktivieren.

Wie verhält sich das Konstrukt bei einem Neustart? Wird dann nicht P_weckzeit aus dem Save-File wiederhergestellt und erhält einen neuen Zeitstempel? Würde das den Wecker jedes Mal aktivieren?