Liebe DOIF-Nutzer,
ich bin gerade dabei die Generalisierung des Moduls weiter zu entwickeln.
Bisher konnte man eine Ereignisabfrage nur auf wahr oder nicht wahr abfragen.
Wollte man z. B. die Temperatur aller Temperatursensoren abfragen, so musste man einen Ereignistrigger mit Readingauswertung definieren, z. B.
([":^temperature"] and [$DEVICE:temperature] < 0) (set pushmsg Frostgefahr!)
Nun habe ich die Syntax für allgemeine Ereignistrigger erweitert, sie lautet:
["Regex für Trigger":"<Regex-Filter>":<Output>,<Default>]
Regex-Filter- und Ouput-Parameter sind optional. Der Default-Wert ist verpflichtend.
Das Beispiel von oben wird dann einfach definiert:
([":^temperature",0] < 0) (set pushmsg Frostgefahr)
Damit wird auf alle Devices getriggert, die mit "temperature" im Event beginnen. Zurückgeliefert wird der Wert, der im Event hinter "temperature: " steht. Wenn kein Event stattfindet, wird der Defaultwert zurückgeliefert. Das ist insb. bei kombinierten logischen Abfragen wichtig, wenn noch andere Trigger in der Bedingung vorkommen.
Die Angaben zum Filter und Output funktionieren, wie die beim Reading-Filter. Siehe:
http://fhem.de/commandref_DE.html#DOIF_Filtern_nach_Zahlen
Wenn kein Filter, wie oben, angegeben wird, so wird intern folgende Regex vorbelegt: "[^\:]*: (.*)" Damit wird der Wert hinter der Readingangabe genommen. Durch eigene Regex-Filter-Angaben kann man beliebige Dinge des Events zurückgeben und in der Bedingung entsprechend auswerten, ohne auf Readings zurückgreifen zu müssen.
Wenn meine Tests abgeschlossen sind, werde ich diese Version zum Testen hier hochladen.
Anregungen zur neuen Syntax sind willkommen.
Edit: Die Version ist selbstverständlich abwärtskompatibel zur bisherigen. Ohne Default-Wert-Angabe verhält sich ein Ereignistrigger wie bisher: er liefert wahr beim Trigger bzw. unwahr sonst.
Gruß
Damian
Edit: aktuelle Version eingecheckt
Version 0.1 im ersten Post angehängt.
Version 0.2
Neues Attribut: checkall
Wenn das Attribut checkall auf 1 gesetzt wird, so werden alle DOIF/DOELSEIF-Zweige abgeprüft unabhängig davon, ob das triggernde Device in der Bedingung vorkommt oder nicht.
Bemerkung: Es kann wie bisher immer nur ein Zweig ausgeführt werden.
Hallo Damian,
ausgehend von dieser Frage https://forum.fhem.de/index.php/topic,44941.msg367322.html#msg367322 ,
wäre es möglich und sinnvoll dem DOIF die zwei Attribute "readingList" und "setList" hinzuzufügen, wie beim Dummy?
Damit wäre es möglich die Kombination von Dummy im Frontend als Eingabe zum Schalten eines DOIF, durch ein DOIF zu ersetzen.
Also, damit so etwas möglich wird
define Schalter DOIF (["$SELF:mybutton: on"]) (set ...)
DOELSEIF (["$SELF:mybutton: off]) (set ...)
attr Schalter readingList mybutton
attr Schalter setList Schalter mybutton:on,off
attr Schalter webCmd mybutton
Bei einem Dummy sieht das so aus
define Schalter Dummy
attr Schalter readingList mybutton
attr Schalter setList Schalter mybutton:on,off
attr Schalter webCmd mybutton
Zitat von: Ellert am 07 November 2016, 16:47:57
Hallo Damian,
ausgehend von dieser Frage https://forum.fhem.de/index.php/topic,44941.msg367322.html#msg367322 ,
wäre es möglich und sinnvoll dem DOIF die zwei Attribute "readingList" und "setList" hinzuzufügen, wie beim Dummy?
Damit wäre es möglich die Kombination von Dummy im Frontend als Eingabe zum Schalten eines DOIF, durch ein DOIF zu ersetzen.
Also, damit so etwas möglich wird
define Schalter DOIF (["$SELF:mybutton: on"]) (set ...)
DOELSEIF (["$SELF:mybutton: off]) (set ...)
attr Schalter readingList mybutton
attr Schalter setList Schalter mybutton:on,off
attr Schalter webCmd mybutton
Bei einem Dummy sieht das so aus
define Schalter Dummy
attr Schalter readingList mybutton
attr Schalter setList Schalter mybutton:on,off
attr Schalter webCmd mybutton
Das Einbauen der beiden Attribute dürfte nicht das Problem sein. Das Problem dürfte allerdings die Tatsache sein, dass ich durch modify des DOIFs zunächst alle Readings lösche, ich weiß nicht was dann mit mybutton passieren würde. Es gab schon mal Anfragen selbstdefinierte Readings im DOIF nicht zu löschen - da müsste ich mir noch genauer Gedanken machen, diesen Wunsch ohne Nebenwirkungen umzusetzen. Das wäre vermutlich Voraussetzung für readingList.
Das Problem dürfte allerdings die Tatsache sein, dass ich durch modify des DOIFs zunächst alle Readings lösche, ich weiß nicht was dann mit mybutton passieren würde.
Man könnte in diesem Fall das DOIF über "RAW definition" ändern, dann bleiben die Readings erhalten.
Bei einem "Modify" wäre "mybutton" gelöscht, die nächste Auswahl eines Wertes erzeugt das Reading wieder.
Es wird eigentlich nur der Status im Frontend nicht angezeigt.
Ich denke der Funktionsgewinn ist nicht zu unterschätzen.
Zitat von: Ellert am 07 November 2016, 18:32:44
Das Problem dürfte allerdings die Tatsache sein, dass ich durch modify des DOIFs zunächst alle Readings lösche, ich weiß nicht was dann mit mybutton passieren würde.
Man könnte in diesem Fall das DOIF über "RAW definition" ändern, dann bleiben die Readings erhalten.
Bei einem "Modify" wäre "mybutton" gelöscht, die nächste Auswahl eines Wertes erzeugt das Reading wieder.
Es wird eigentlich nur der Status im Frontend nicht angezeigt.
Ich denke der Funktionsgewinn ist nicht zu unterschätzen.
Ja. Ich werde es auf die todo-Liste setzen und gleichzeitig nur noch von DOIF erstellte Readings beim Modify löschen. Damit könnten User komplexere Dinge innerhalb eines DOIF programmieren ohne Sachen in irgendwelchen Dummys auszulagern.
Ich habe mal den entsprechenden Code aus dem Dummy in das DOIF kopiert und angepasst, nicht schön, aber zum Probieren reicht es.
Vielleicht gibts ja einen kleinen Positionsgewinn in der ToDo-Liste ;)
Basis: $Id: 98_DOIF.pm Ver. 0.2 damian-s $
Zeile 24: use SetExtensions;
Zeile 74 ergänzt mit: setList readingList useSetExtensions
Zeile 1923 -1944 Code aus Dummy angepasst
Hiermit habe ich probiert (zum Import mit Raw definiton):
define Test DOIF (["$SELF:mybutton: ein"]) DOELSEIF (["$SELF:mybutton: aus"])
attr Test cmdState ein|aus
attr Test readingList state mybutton
attr Test room 0_Test
attr Test setList state:disable,enable,initialize mybutton:ein,aus
attr Test webCmd state:mybutton
Zitat von: Ellert am 07 November 2016, 20:26:39
Ich habe mal den entsprechenden Code aus dem Dummy in das DOIF kopiert und angepasst, nicht schön, aber zum Probieren reicht es.
Vielleicht gibts ja einen kleinen Positionsgewinn in der ToDo-Liste ;)
Basis: $Id: 98_DOIF.pm Ver. 0.2 damian-s $
Zeile 24: use SetExtensions;
Zeile 74 ergänzt mit: setList readingList useSetExtensions
Zeile 1923 -1944 Code aus Dummy angepasst
Hiermit habe ich probiert (zum Import mit Raw definiton):
define Test DOIF (["$SELF:mybutton: ein"]) DOELSEIF (["$SELF:mybutton: aus"])
attr Test cmdState ein|aus
attr Test readingList state mybutton
attr Test room 0_Test
attr Test setList state:disable,enable,initialize mybutton:ein,aus
attr Test webCmd state:mybutton
Funktioniert schon ganz gut. Allerdings muss man natürlich ohne die neuen Attribute die bisherige set-Auswahl (disable, enable, initialize) auswählen können.
Ich habe den ergänzten Code bereinigt, jetzt bleiben die Set-Vorgaben erhalten.
Auf erlaubte Readings wird im Allgemeinen ja nicht geprüft, z.B. bei userReadings.
Basis: $Id: 98_DOIF.pm Ver. 0.2 damian-s $
Zeile 73 ergänzt mit: setList readingList
Zeile 1922 -1937 Code aus Dummy angepasst und bereinigt
Hier nochmal mein Testgerät
define Test DOIF (["$SELF:mybutton: ein"]) DOELSEIF (["$SELF:mybutton: aus"])
attr Test cmdState ein|aus
attr Test readingList mybutton
attr Test room 0_Test
attr Test setList mybutton:ein,aus
attr Test webCmd mybutton
Zitat von: Ellert am 08 November 2016, 10:49:15
Ich habe den ergänzten Code bereinigt, jetzt bleiben die Set-Vorgaben erhalten.
Auf erlaubte Readings wird im Allgemeinen ja nicht geprüft, z.B. bei userReadings.
Basis: $Id: 98_DOIF.pm Ver. 0.2 damian-s $
Zeile 73 ergänzt mit: setList readingList
Zeile 1922 -1937 Code aus Dummy angepasst und bereinigt
Hier nochmal mein Testgerät
define Test DOIF (["$SELF:mybutton: ein"]) DOELSEIF (["$SELF:mybutton: aus"])
attr Test cmdState ein|aus
attr Test readingList mybutton
attr Test room 0_Test
attr Test setList mybutton:ein,aus
attr Test webCmd mybutton
Sieht schon ganz gut aus. Wenn du Zeit hast, kannst du auch schon die passende Doku in der 0.2-Version vornehmen. Ich kann dann ausgehend von dieser Version noch die ausstehenden Features vornehmen. U. A. neue Syntax bei Stati und Readingangaben: [mydevice:myreading,<default Value>] das entspricht der neuen Syntax bei Events und gibt dem User die Möglichkeit mit Default-Werten flexibler umzugehen, als über das Attribut noexist.
O.K., die Doku werde ich ergänzen. Die Attribute sind ja schon in der Befehlsreferenz beschrieben. Ich werde darauf verweisen und ein Beispiel einfügen?
Zitat von: Ellert am 08 November 2016, 17:15:26
O.K., die Doku werde ich ergänzen. Die Attribute sind ja schon in der Befehlsreferenz beschrieben. Ich werde darauf verweisen und ein Beispiel einfügen?
OK.
Wir sollten ein kurzes Beispiel auswählen, welches nicht nur die Funktionalität aufzeigt, sondern den Mehrwert für dieses Modul in der Praxis darstellt.
Ich habe die Doku ergänzt mit einem kurzen, eindrucksvollen Beispiel.
Zitat von: Ellert am 08 November 2016, 20:37:34
Ich habe die Doku ergänzt mit einem kurzen, eindrucksvollen Beispiel.
Schön. Das Beispiel ist praxisrelevant. Es wäre allerdings besser statt ein/aus on/off zu nehmen, denn in der englischen Commandref verweise ich auf die vielen Beispiele mit englischen Bezeichnern. Mit dieser Funktionalität dürften einige dummys wegfallen und damit einige kontroverser Diskussionen zum Thema DOIF oder notify ;) Ich muss dann noch Anpassungen vornehmen, um die "user"-readings nicht zu löschen. Evtl. noch ein set deletereadings einbauen, für den Fall, dass jemand alle Readings in seinem DOIF bereinigen möchte.
Ihr seid echt total genial. :)
Ich überarbeite die Doku gerade nochmal.
Gilt "notexist" als deprecated ?
Wird folgende Zeitangabe möglich sein?
[[$SELF:mybegin,1]-[$SELF:myend,2]]
Wenn ja, dann ändere ich das Beispiel
Edit:
Ist der Defaultwert hier auch möglich?
[<devicename>,<default>]
und in dieser Form mit indirekter Angabe
[<devicename1>:<readingname1>,[<devicename2>:<readingname2>]]
Zitat von: Ellert am 09 November 2016, 08:29:37
Ich überarbeite die Doku gerade nochmal.
Gilt "notexist" als deprecated ?
Wird folgende Zeitangabe möglich sein?
[[$SELF:mybegin,1]-[$SELF:myend,2]]
Wenn ja, dann ändere ich das Beispiel
Edit:
Ist der Defaultwert hier auch möglich?
[<devicename>,<default>]
und in dieser Form mit indirekter Angabe
[<devicename1>:<readingname1>,[<devicename2>:<readingname2>]]
notexist bleibt natürlich als globaler Default-Wert und kann ohne weiteres benutzt werden.
Übersteuern kann man das dann mit den Angaben:
Folgendes soll zuerst möglich sein:
[<Device>,<Default-Wert>]
[<Device>:<Reading>,<Default-Wert>]
wobei <Default-Wert> Zahlen oder Zeichenketten sein können, mit oder ohne Anführungszeichen.
Sie vollständige Syntax lautet ja mit Filter und Output-Formatierung dann (nur bei readings):
[<Device>:<Reading>:<Filter>:<Output>,<Default-Wert>]
Stufe 2
Weitere Auswertung von <Defalut-Wert>(falls sinnvoll) könnte wie bei wait sein.
[<Device>:<Reading>:<Filter>:<Output>,<Perlberechnung mit allem was in Perl geht und allen Angaben in eckigen Klammern>
Aber erst muss ich es einbauen und dann dokumentieren.
Es soll natürlich alles abwärtskompatibel sein d. h. Filter, Output und Default-Wert sind optional und müssen nicht angegeben werden.
Ich habe die Kurzreferenz noch ergänzt und das Beispiel eingeenlischt ;)
Da bei den Attributen nicht nur "DOIF spezifische Attribute" aufgeführt sind lautet die Überschrift jetzt "Attribute".
Das Bild, wie DOIF im Frontend aussehen kann, habe ich mal angehängt.
Zitat von: Ellert am 09 November 2016, 12:38:03
Ich habe die Kurzreferenz noch ergänzt und das Beispiel eingeenlischt ;)
Da bei den Attributen nicht nur "DOIF spezifische Attribute" aufgeführt sind lautet die Überschrift jetzt "Attribute".
Das Bild, wie DOIF im Frontend aussehen kann, habe ich mal angehängt.
OK. Ich werde, sobald ich etwas mehr Zeit habe, darauf aufbauend die genannten Features (auch $week) noch einbauen.
Hallo Damian,
ich musste das Beispiel überarbeiten, es hätte nicht funktioniert. Falls diese Überarbeitung ungelegen kommt, kann ich die Änderungen der Doku auch später in den Releasekandidaten einpflegen.
Zitat von: Ellert am 11 November 2016, 11:04:10
Hallo Damian,
ich musste das Beispiel überarbeiten, es hätte nicht funktioniert. Falls diese Überarbeitung ungelegen kommt, kann ich die Änderungen der Doku auch später in den Releasekandidaten einpflegen.
Kein Problem, ich habe noch nichts gemacht.
Version 0.4 im ersten Post
Neues Feature:
Defaultwert für Readings und Stati mit Perlberechnung!
was jetzt geht:
[lamp,"off"]
[room:temperatur,20]
[brightness,3*[myvalue]+2]
[heating,AttrVal("mydevice","myattr","")]
[[mytime,"10:00"]]
weitere Features:
readingList,...
Ereignisfilter
Attribut checkall
$week für Wochennummer
Interne Funktionsaufrufe in der Bedingung wurden optimiert
Doku angepasst.
Die Version ist wie immer abwärtskompatibel, allerdings haben sich intern die Funktionsaufrufe geändert, daher kein reload machen, sondern System nach dem Einspielen durchstarten.
Ich habe das Beispiel ausprobiert, wenn ich die Zeiten im Frontend ändere, dann tritt der Fehler auf: time_switch: error in default: 00:00
Zitat
Internals:
DEF (["$SELF:mybutton: on"] or [[$SELF:mybegin,"00:00"]])
(set lamp on)
DOELSEIF (["$SELF:mybutton: off"] or [[$SELF:myend,"00:01"]])
(set lamp off)
NAME time_switch
NR 43
NTFY_ORDER 50-Schaltuhr
STATE on
TYPE DOIF
Readings:
2016-11-12 19:39:05 Device time_switch
2016-11-12 19:39:05 cmd 1
2016-11-12 19:39:05 cmd_event time_switch
2016-11-12 19:39:05 cmd_nr 1
2016-11-12 19:39:18 error time_switch: error in default: 00:01
2016-11-12 19:39:05 matched_event_c1_1 mybutton: on
2016-11-12 19:36:16 matched_event_c2_1 mybutton: off
2016-11-12 19:39:18 mybegin 12:00
2016-11-12 19:39:05 mybutton on
2016-11-12 19:36:04 myend 12:10
2016-11-12 19:39:05 state on
2016-11-12 19:39:18 timer_01_c01 13.11.2016 12:00:00
2016-11-12 19:39:18 timer_02_c02 13.11.2016 12:10:00
Condition:
0 EventDoIf('time_switch',$hash,'mybutton: on',0) or DOIF_time_once($hash,$hash->{timer}{0},$wday,"")
1 EventDoIf('time_switch',$hash,'mybutton: off',0) or DOIF_time_once($hash,$hash->{timer}{1},$wday,"")
Days:
Devices:
Do:
0:
0 set lamp on
1:
0 set lamp off
Helper:
event mybutton: on
globalinit 1
last_timer 2
sleeptimer -1
timerdev time_switch
timerevent mybutton: on
triggerDev time_switch
timerevents:
mybutton: on
error: time_switch: error in default: 00:00
timer_01_c01: 13.11.2016 12:00:00
error: time_switch: error in default: 00:01
timer_02_c02: 13.11.2016 12:10:00
Device: time_switch
matched_event_c1_1: mybutton: on
cmd_nr: 1
cmd: 1
cmd_event: time_switch
on
timereventsState:
mybutton: on
error: time_switch: error in default: 00:00
timer_01_c01: 13.11.2016 12:00:00
error: time_switch: error in default: 00:01
timer_02_c02: 13.11.2016 12:10:00
Device: time_switch
matched_event_c1_1: mybutton: on
cmd_nr: 1
cmd: 1
cmd_event: time_switch
on
triggerEvents:
mybutton: on
error: time_switch: error in default: 00:00
timer_01_c01: 13.11.2016 12:00:00
error: time_switch: error in default: 00:01
timer_02_c02: 13.11.2016 12:10:00
Device: time_switch
matched_event_c1_1: mybutton: on
cmd_nr: 1
cmd: 1
cmd_event: time_switch
on
triggerEventsState:
mybutton: on
error: time_switch: error in default: 00:00
timer_01_c01: 13.11.2016 12:00:00
error: time_switch: error in default: 00:01
timer_02_c02: 13.11.2016 12:10:00
Device: time_switch
matched_event_c1_1: mybutton: on
cmd_nr: 1
cmd: 1
cmd_event: time_switch
on
Internals:
Itimer:
all time_switch
Localtime:
0 1479034800
1 1479035400
Readings:
Realtime:
0 12:00:00
1 12:10:00
Regexp:
0:
0 time_switch:mybutton: on
1:
0 time_switch:mybutton: off
All:
0 time_switch:mybutton: on
1 time_switch:mybutton: off
State:
Time:
0 [time_switch:mybegin,"00:00"]
1 [time_switch:myend,"00:01"]
Timecond:
0 0
1 1
Timer:
0 0
1 0
Timers:
0 0
1 1
Trigger:
Triggertime:
1479034800:
localtime 1479034800
Hash:
1479035400:
localtime 1479035400
Hash:
Attributes:
alias Schaltuhr
cmdState on|off
group Schaltuhr
readingList mybutton mybegin myend
room DOIF_Labor
setList mybutton:on,off mybegin:time myend:time
webCmd mybutton:mybegin:myend
Problem behoben. Version 0.5 im ersten Post.
Zeichenketten in Anführungszeichen implizieren keine Berechnung. Alle genannten Beispiele funktionieren jetzt korrekt.
Übrigens funktionieren ohne Anführungszeichen Perlberechnungen auch im Attribut notexist.
Doku weiter angepasst.
Hi Damian,
kannst Du kurz ein Anwendungsbeispiel für das neue Attribut checkall geben - mir ist das noch nicht ganz klar, welches Problem das löst.
VG Yil
Zitat von: Yil am 14 November 2016, 18:23:40
Hi Damian,
kannst Du kurz ein Anwendungsbeispiel für das neue Attribut checkall geben - mir ist das noch nicht ganz klar, welches Problem das löst.
VG Yil
DOIF ([A] eq "on")
(set bla1 on)
DOELSEIF ([B] eq "on")
(set bla2 on)
es kommt Event: A: off
Ohne checkall passiert nichts. Es wird die erste Abfrage überprüft - sie ist nicht wahr, die zweite Bedingung wird nicht überprüft, weil A dort nicht vorkommt.
Mit checkall wird dagegen auch DOELSEIF überprüft, obwohl dort A nicht vorkommt, ist B gleich on wird set bla2 on ausgeführt.
Gruß
Damian
Ich habe eine Version 0.6 (erste Post) gebastelt, bei der Readings, die mit _ beginnen nicht gelöscht werden. Wenn man eigene Readings im Modul beginnend mit dem Unterstrich definiert, so bleiben sie erhalten bis man sie löscht.
Damit bleiben eigene Readings zusammenhängend am Anfang aller Readings sichtbar und man hat noch beliebig Spielraum eigene Reading-Namen zu erfinden.
Wenn einem noch etwas besseres einfällt, dann bitte melden, bevor die Version eingecheckt wird.
Gruß
Damian
Vielleicht als Anlehnung an die Register von Home Matic U- davor Scheiben für user.
Zitat von: Damian am 14 November 2016, 23:03:37
Ich habe eine Version 0.6 (erste Post) gebastelt, bei der Readings, die mit _ beginnen nicht gelöscht werden. Wenn man eigene Readings im Modul beginnend mit dem Unterstrich definiert, so bleiben sie erhalten bis man sie löscht.
Damit bleiben eigene Readings zusammenhängend am Anfang aller Readings sichtbar und man hat noch beliebig Spielraum eigene Reading-Namen zu erfinden.
Wenn einem noch etwas besseres einfällt, dann bitte melden, bevor die Version eingecheckt wird.
Gruß
Damian
Ein Präfix ist das einfachste, hatte ich auch gedacht.
Die Readings kann man dann mit
deletereading <Device> _.* löschen das Bedarf dann keiner Löschfunktion.
Edit: Falsches Zitat ersetzt
Zitat von: igami am 15 November 2016, 05:50:56
Vielleicht als Anlehnung an die Register von Home Matic U- davor Scheiben für user.
Das könnte man auch machen, dann liegen allerdings die Readings mittendrin und es ist ein Zeichen mehr. Die Frage ist, ob "Kompatibilität" zu Home Matic als wichtig angesehen wird oder nicht.
Zitat von: Damian am 15 November 2016, 08:46:05
Das könnte man auch machen, dann liegen allerdings die Readings mittendrin und es ist ein Zeichen mehr. Die Frage ist, ob "Kompatibilität" zu Home Matic als wichtig angesehen wird oder nicht.
Wo die readings stehen sollte doch egal sein. Bei HM steht halt das R- für Register, daher die Idee U- für user.
Hallo Damian,
ich habe die Kurzreferenz ergänzt mit checkall und das Beispiel für setList, readingList mit Defaultwerten ausgestattet und notexist entfernt.
Basis ist Version 0.6, ohne Fehler mit commandref_join.pl
Zitat von: Ellert am 15 November 2016, 19:14:03
Hallo Damian,
ich habe die Kurzreferenz ergänzt mit checkall und das Beispiel für setList, readingList mit Defaultwerten ausgestattet und notexist entfernt.
Basis ist Version 0.6, ohne Fehler mit commandref_join.pl
ok.
Mir fehlt noch ein sinnvolles Beispiel für checkall.
Ich sollte noch erwähnen, dass nicht vorhandene Readings (ohne Ersatzwert) keine Fehlermeldung mehr bringen und intern statt undef ein Leerstring "" zurückgegeben wird. Das war aufgrund des neuen Features: Dafaultvalue erforderlich und sollte weniger zu Problemen führen.
timer-Readings werden jetzt zweistellig dargestellt, damit bleibt die Reihenfolge über 9 erhalten.
Ehrlich gesagt, ich habe für mich noch nichts gefunden, um checkall einzusetzen.
Zitat von: Ellert am 15 November 2016, 22:54:29
Ehrlich gesagt, ich habe für mich noch nichts gefunden, um checkall einzusetzen.
Ich auch nicht, aber einige User erwarten dieses Verhalten, weil sie es so in einer sequenziellen Programmierung kennen.
Nach dem heutigen FHEM Update wird FHEM beendet, wenn ich ein DOIF (version 0.6) definieren möchte, z.B. mit
define Testgeraet DOIF ([18:00])Fehlermeldung im Logfile beim Start:
Zitat2016.11.16 14:41:10 0: Featurelevel: 5.7
2016.11.16 14:41:10 0: Server started with 46 defined entities (fhem.pl:12564/2016-11-13 perl:5.020002 os:linux user:fhem pid:784)
Type of argument to keys on reference must be unblessed hashref or arrayref at ./FHEM/98_DOIF.pm line 61.
2016.11.16 14:50:21 1: Including fhem.cfg
2016.11.16 14:50:21 3: telnetPort: port 7072 opened
2016.11.16 14:50:22 3: WEB: port 8083 opened
2016.11.16 14:50:23 3: WEBphone: port 8084 opened
2016.11.16 14:50:23 3: WEBtablet: port 8085 opened
2016.11.16 14:50:23 2: eventTypes: loaded 381 events from ./log/eventTypes.txt
2016.11.16 14:50:24 1: PERL WARNING: keys on reference is experimental at ./FHEM/98_DOIF.pm line 61, <$fh> line 139.
2016.11.16 14:50:24 1: stacktrace:
2016.11.16 14:50:24 1: main::__ANON__ called by ./FHEM/98_DOIF.pm (61)
2016.11.16 14:50:24 1: (eval) called by fhem.pl (2302)
2016.11.16 14:50:24 1: (eval) called by fhem.pl (2301)
2016.11.16 14:50:24 1: main::CommandReload called by fhem.pl (1725)
2016.11.16 14:50:24 1: main::LoadModule called by fhem.pl (1787)
2016.11.16 14:50:24 1: main::CommandDefine called by fhem.pl (1085)
2016.11.16 14:50:24 1: main::AnalyzeCommand called by fhem.pl (955)
2016.11.16 14:50:24 1: main::AnalyzeCommandChain called by fhem.pl (1219)
2016.11.16 14:50:24 1: main::CommandInclude called by fhem.pl (519)
Edit:
Zeile 61 geändert auf:
foreach my $key (keys %{$defs{$hash->{NAME}}{READINGS}}) {
Ja, es fehlte die Referenz. Ich habe es angepasst.
Durch die Änderung der timer-Readings auf zweistellige Nummern (da wollen wir mal hoffen, dass keiner mehr als 99-Timer pro Modul definiert) verblieben die alten timer-Readings als Leichen nach einem Neustart. Erst nach einem manuellen def modify wären sie gelöscht.
In Version 0.8 werden jetzt beim Neustart immer alle timer-Readings gelöscht, weil Timer ohnehin immer neugesetzt werden müssen. Damit verschwinden auch alle Altlasten nach dem Neustart.
Wenn man setList, readinglist zusammen mit dauerhaften Benutzer-Readings verwendet und diese Reading mit einer Vorgabe angegeben sind und Sie noch keinen Wert besitzen (""), wäre es dann nicht sinnvoll alle Benutzer-Readings auf den Vorgabewert zu setzen (ohne Event), bei Definition oder Modify?
Das könnte funktionieren, sofern der Readingname in der Bedingung vollständig angegeben ist und nicht als Regex, also wenn
[$SELF:_<readingname>,<default value>] oder [<eigener Name>:_<readingsname>,<default value>] benutzt wird.
Der Vorteil wäre, dass die Anzeige im Frontend dann den Vorgabewert enthält.
Zitat von: Ellert am 17 November 2016, 08:11:38
Wenn man setList, readinglist zusammen mit dauerhaften Benutzer-Readings verwendet und diese Reading mit einer Vorgabe angegeben sind und Sie noch keinen Wert besitzen (""), wäre es dann nicht sinnvoll alle Benutzer-Readings auf den Vorgabewert zu setzen (ohne Event), bei Definition oder Modify?
Das könnte funktionieren, sofern der Readingname in der Bedingung vollständig angegeben ist und nicht als Regex, also wenn
[$SELF:_<readingname>,<default value>] oder [<eigener Name>:_<readingsname>,<default value>] benutzt wird.
Der Vorteil wäre, dass die Anzeige im Frontend dann den Vorgabewert enthält.
ja, muss ich mir mal anschauen. Wird aber nicht einfach sein eine passende Stelle im Modul zu finden, wo die nötigen Informationen vorliegen. Andererseits muss der User ohnehin selbst das Reading anlegen und dann kann er es auch gleich vorbelegen.
Hi Damian,
ich habe folgende Definition für das Gartenlicht aufgebaut:
([([{sunrise("HORIZON=-1.5",0,"05:20","08:14")}]) -
([09:00]+2700+int(rand(900)))|7] and [Garten.Bewegung:1.BRIGHTNESS] < 130 and [Sommerzeit] ne 'on')
(({if (Value('Garten.Beleuchtung') eq 'off') {PushInfo('Gartenbeleuchtung','Gartenbeleuchtung Wochenende morgens: angeschaltet','Steph')}}),
({if (Value('Garten.Beleuchtung') eq 'off') {Log 3,"Gartenbeleuchtung Wochenende morgens: An"}}),
(set Garten.Beleuchtung:FILTER=STATE!=on on))
DOELSEIF (
[([{sunrise("HORIZON=-1.5",0,"05:20","06:30")}]+int(rand(900))) -
([{sunrise("HORIZON=-1.5",0,"05:20","08:14")}]+2700+int(rand(900)))|8] and [Garten.Bewegung:1.BRIGHTNESS] < 130 and [Sommerzeit] ne 'on')
(({if (Value('Garten.Beleuchtung') eq 'off') {PushInfo('Gartenbeleuchtung','Gartenbeleuchtung Werktags morgens: angeschaltet','Steph')}}),
({if (Value('Garten.Beleuchtung') eq 'off') {Log 3,"Gartenbeleuchtung Werktags morgens: An"}}),
(set Garten.Beleuchtung:FILTER=STATE!=on on))
DOELSEIF (
[{sunset("HORIZON=-2.0",0,"16:28","21:29")} -
([21:45]+int(rand(900)))] and [Garten.Bewegung:1.BRIGHTNESS] < 130)
(({if (Value('Garten.Beleuchtung') eq 'off') {PushInfo('Gartenbeleuchtung','Gartenbeleuchtung abends: angeschaltet','Steph')}}),
({if (Value('Garten.Beleuchtung') eq 'off') {Log 3,"Gartenbeleuchtung abends: An"}}),
(set Garten.Beleuchtung:FILTER=STATE!=on on),
(set Osram05:FILTER=STATE=off dim1%),(set Osram05 dim75% 900))
DOELSE (
({if (Value('Garten.Beleuchtung') eq 'on') {PushInfo('Gartenbeleuchtung','Gartenbeleuchtung: ausgeschaltet','Steph')}}),
({if (Value('Garten.Beleuchtung') eq 'on') {Log 3,"Gartenbeleuchtung: Aus"}}),
(set Garten.Beleuchtung:FILTER=STATE!=off off),(set Osram05:FILTER=STATE!=off off))
Daraus werden folgende Zeiten errechnet:
Readings:
2016-11-17 10:29:40 Device Garten.Bewegung
2016-11-17 10:29:40 cmd 4
2016-11-17 10:29:40 cmd_event Garten.Bewegung
2016-11-17 10:29:40 cmd_nr 4
2016-11-17 10:29:40 e_Garten.Bewegung_1.BRIGHTNESS 181
2016-11-17 05:06:00 e_Sommerzeit_STATE off
2016-11-17 10:29:40 state cmd_4
2016-11-17 09:55:33 timer_1_c1 18.11.2016 07:32:24|7
2016-11-17 09:55:33 timer_2_c1 18.11.2016 09:49:27|7
2016-11-17 08:23:51 timer_3_c2 18.11.2016 06:35:09|8
2016-11-17 08:23:51 timer_4_c2 18.11.2016 08:30:13|8
2016-11-17 05:30:32 timer_5_c3 17.11.2016 16:48:58
2016-11-17 05:30:32 timer_6_c3 17.11.2016 21:46:40
Folgende Log-Einträge werden geschrieben:
2016.11.17 06:39:57 3: Gartenbeleuchtung Werktags morgens: An
2016.11.17 07:30:55 3: Gartenbeleuchtung: Aus
2016.11.17 07:39:13 3: Gartenbeleuchtung Werktags morgens: An
2016.11.17 08:23:51 3: Gartenbeleuchtung: Aus
2016.11.17 08:27:41 3: Gartenbeleuchtung Werktags morgens: An
2016.11.17 08:32:29 3: Gartenbeleuchtung: Aus
Kannst Du nachvollziehen, warum sich das Gartenlicht während des Zeitraumes aus CMD_2 mehrfach in CMD_4 wechselt? Würde das neue Attribut checkall hier etwas helfen?
VG Yil
Zufällige Intervalle sind immer kritisch zu sehen:
Beispiel:
[10:00-(sunset+rand(3600)]
gestern wurde z. B. die errechnete Zeit auf sunset+1000 errechnet, heute wird um diese Zeit getriggert - zu diesem Zeitpunkt ist das Intervall nicht mehr wahr und DOELSE schlägt zu. Gleichzeitig wird die neue Endzeit berechnet z. b. sunset+3000. Damit verlängert sich das Intervall um ca. 2000 Sekunden und ist wieder wahr. In dieser Zeit kann wieder ein Trigger kommen, der zur erneuten Ausführung dieses Zweiges führt, da ein Zustandswechsel erfolgte. Ein checkall würde die Sache eher noch verschlimmern.
Verstehe. Was würdest Du empfehlen, um einerseits keine planbaren Aktionen zu haben und andererseits aus dieser "Falle" herauszukommen?
Zitat von: Yil am 17 November 2016, 12:13:49
Verstehe. Was würdest Du empfehlen, um einerseits keine planbaren Aktionen zu haben und andererseits aus dieser "Falle" herauszukommen?
Statt eine Zufallszahl bei der Zeitangabe zu verwenden könntest Du ein zufälliges wait verwenden.
attr <name> wait rand(900):rand(900):rand(900)
Zitat von: Yil am 17 November 2016, 12:13:49
Verstehe. Was würdest Du empfehlen, um einerseits keine planbaren Aktionen zu haben und andererseits aus dieser "Falle" herauszukommen?
Das hängt immer vom Anwendungsfall ab. Das Beispiel aus der Commandref :
define di_light DOIF ([([Fixtime]-[01:00]-int(rand(300))) - ([Fixtime]+[01:00]+int(rand(300)))]|7])
(set lampe on)
DOELSE
(set lampe off)
ist unkritisch trotz einer zufälligen Verlängerung des Intervalls, weil es keinen weiteren Trigger hier gibt, der in der Zwischenzeit zuschlagen könnte. Hier kann der Zustand also nicht toggeln.
Zufällige Schaltzeitpunkte würde ich, wie von Ellert vorgeschlagen, mit wait realisieren. Zumal man in wait inzwischen jede beliebige Berechnung vornehmen kann.
Auch diese Anwesenheitssimulation aus der Commandref ist unkritisch. Sie realisiert den zufälligen Ausschaltzeitpunkt mit Hilfe des on-for-timers.
define di_presence_simulation DOIF ([19:00-00:00])(set lamp on-for-timer {(int(rand(1800)+300))}) DOELSE (set lamp off)
attr di_presence_simulation repeatcmd rand(3600)+2200
Das kann ich alles sehr gut nachvollziehen und habe einen Teil meiner Umsetzung auch von dort ennommen.
Problematisch wird es durch den Zusatz "|7" bzw. "|8" - prinzipiell (soweit ich die Commandref) verstanden habe, ist es doch möglich, für unterschiedliche Tage unterschiedliche Steuerungen zu haben. Genau das habe ich gemacht. Ich erweitere damit mal Dein Beispiel aus der Commandref:
define di_light DOIF ([([Fixtime]-[01:00]-int(rand(300))) - ([Fixtime]+[01:00]+int(rand(300)))]|7])
(set lampe on)
DOELSIF ([([Fixtime]-[00:30]-int(rand(200))) - ([Fixtime]+[00:30]+int(rand(200)))]|8])
(set lampe on)
DOELSE
(set lampe off)
Im Ergebnis würden dann zwei neue Trigger hinzukommen, die genau zwischen den Triggern der ersten Bedingung liegen und - so mein Verdacht und meine bisherige Beobachtung - für ein Abschaltender Lampe sorgen. Ist das dann nicht eigentlich ein Bug? Denn das gewünschte und erwartete Verhalten wäre ja, dass sich die Trigger werktags mit den Triggern für das Wochenende nicht ins Gehege kommen.
Ansonsten probiere ich mal den wait-Timer mit Zufallszahl aus.
Bei wochentagabhängigen Zeitintervallen gibt es noch ein Problem. Z. T. wird das Modul immer (also an allen Tagen, nicht nur an den angegebenen Wochentagen) an jeweiligen Zeiten getriggert und das Intervall wird geprüft und wenn es nicht wahr ist, wird der DOELSE-Fall ausgeführt. Das dürfte hier das Problem sein.
Auf meiner todo-Liste steht bereits:
1. Intervalle werden nur noch an den angegebenen Wochentagen getriggert, damit kann nicht unverhofft der DOELSE-Fall kommen.
ein zweiter Punkt, der hier zumindest unproblematisch ist, ist
2. Intervalle, wo die Anfangszeit mit der Endzeit identisch ist, werden nicht getriggert, das Intervall ist nicht wahr.
Vielleicht schaffe ich diese Punkte noch in die aktuelle Beta-Version einzubauen.
Edit:
Diese Angabe sollte zunächst dein Problem lösen:
define di_light DOIF ([([Fixtime]-[01:00]-int(rand(300))) - ([Fixtime]+[01:00]+int(rand(300)))]|7] or
[([Fixtime]-[00:30]-int(rand(200))) - ([Fixtime]+[00:30]+int(rand(200)))]|8])
(set lampe on)
DOELSE
(set lampe off)
so gibt es nur zwei Zustände. Bei zusätzlichen Triggern wird nicht in DOELSE geschaltet, wenn eines der beiden Intervalle noch wahr ist.
Hi Damian,
danke für die Aufklärung. DA haben wir sie wieder - die berühmte DOELSE-Falle ;)
Die Oder-Verknüpfung macht natürlich Sinn, das leuchtet mir sofort ein. Kann ich innerhalb eines Commands abfragen, welche Bedingung die Schaltung ausgelöst hat - bei einer Oder-Verknüpfung also der erste oder der zweite Teil? Das wäre an einer anderen Stelle zur Steuerung von Dummys ganz hilfreich.
VG Yil
Guten Morgen,
ich habe da ein ähnliches Problem, siehe -> https://forum.fhem.de/index.php/topic,61228.0.html (https://forum.fhem.de/index.php/topic,61228.0.html)<- und wollte mal fragen wann denn immer getriggert wird. Wenn ich den Zufall ins wait lege, kann ich im Reading nicht mehr sehen, wann es nun genau an und aus geht.
Kurios finde ich auch, das bei einer festen Zeit, der Zufallswert sich nicht ändert (Spalte 1 und 4) aber bei den Werten die vom Twilight abhängen schon. Obwohl sich der Twilightwert an sich ja auch nicht geändert. Es mag sein, das sich der Twilightwert beim erreichen des Zeitpunktes einmal am Abend ändert, aber doch nicht vier mal wie in meinem Beispiel. Die Bilder sind alle innerhalb einer halben Stunde aufgenommen.
Marc
Zitat von: yogiflop am 23 November 2016, 09:02:18
Guten Morgen,
ich habe da ein ähnliches Problem, siehe -> https://forum.fhem.de/index.php/topic,61228.0.html (https://forum.fhem.de/index.php/topic,61228.0.html)<- und wollte mal fragen wann denn immer getriggert wird. Wenn ich den Zufall ins wait lege, kann ich im Reading nicht mehr sehen, wann es nun genau an und aus geht.
Kurios finde ich auch, das bei einer festen Zeit, der Zufallswert sich nicht ändert (Spalte 1 und 4) aber bei den Werten die vom Twilight abhängen schon. Obwohl sich der Twilightwert an sich ja auch nicht geändert. Es mag sein, das sich der Twilightwert beim erreichen des Zeitpunktes einmal am Abend ändert, aber doch nicht vier mal wie in meinem Beispiel. Die Bilder sind alle innerhalb einer halben Stunde aufgenommen.
Marc
Der "Zufall" ändert die Zeit, wenn der Timer getriggert wird und die neue Zeit berechnet wird. Für Twilight gilt das, was ich schon in der Commandref dazu geschrieben habe:
http://fhem.de/commandref_DE.html#DOIF_checkReadingEvent Stichwort checkReadingEvent
Wäre es möglich, dass DOIF neben Readings und Internals auch Attribute verwenden kann?
Im Zusammenhang mit der Generalisierbarkeit wäre das nützlich. Wenn man seine Geräte wie oft empfohlen systematisch benennt, sind die Namen oftmals suboptimal für einfache Messages (WAF!) oder Sprachausgabe. Dann wäre es prima, wenn man etwa bei einer Battery- oder Fenster offen-Warnung auf den Alias oder auch die Room-Angabe zurückgreifen könnte. Oder auch ein extra für diesen Zweck angelegtes userattr.
Wenn man das ganze auch in Konditionen verwenden könnte, hätte man außerdem die Möglichkeit, schon in den Bedingungen zu prüfen, ob ein Gerät beispielweise zu einer bestimmten Gruppe oder in einen bestimmten Raum gehört. So ließen sich Generalisierungen auch wieder gezielt auf eine bestimmte Gruppe von Geräten einschränken.
Zitat von: Brockmann am 25 November 2016, 09:23:19
Wäre es möglich, dass DOIF neben Readings und Internals auch Attribute verwenden kann?
Genau das hätte ich gestern gebraucht :D
Die Frage ist nur welches Zeichen man dafür verwenden sollte.
Zitat von: Brockmann am 25 November 2016, 09:23:19Oder auch ein extra für diesen Zweck angelegtes userattr.
Du kannst ja ein Userreading erstellen. Das geht ja jetzt schon auszuwerten.
Ich glaube das Thema hatten wir schon mal. Man müsste ein Zeichen nehmen, was im Device nicht vorkommen kann. § haben wir noch nicht !$@ haben oft schon andere Bedeutung.
Man kann in der Bedingung aber auch die AttrVal-Funktion nutzen ohne Triggerfunktionalität.
Ich habe allerdings auf der todo-Liste noch andere Sachen stehen und gerade etwas wenig Zeit.
Gruß
Damian
Version 0.9
Änderung:
A-Z_<persistent user defined readingname>
benutzerdefinierte Readings beginnend mit einem Großbuchstaben mit Unterstrich als Präfix überdauern ein Modify
Interne Funktionsaufrufe weiter optimiert (interne Perl-Bedingungen in der list-Übersicht sind kürzer und damit besser bei Analysen lesbar)
Zitat von: Damian am 25 November 2016, 23:07:21
Version 0.9
Änderung:
A-Z_<persistent user defined readingname>
benutzerdefinierte Readings beginnend mit einem Großbuchstaben mit Unterstrich als Präfix überdauern ein Modify
Interne Funktionsaufrufe weiter optimiert (interne Perl-Bedingungen in der list-Übersicht sind kürzer und damit besser bei Analysen lesbar)
Auch die Version 0.9 läuft seit heute mittag problemlos im Wirkbetrieb.
Die persistenten Readings [A-Z]_ sind dauerhaft und die mit _ verschwinden nach einem Modify, die Timer-Readings werden korrekt zweistellig angezeigt und die alten Timer-Readings wurden gelöscht. Das Wiki ist angepasst, ich warte nur noch darauf, den Hinweis auf die Beta-Version entfernen zu können :)
Zitat von: Ellert am 26 November 2016, 19:36:25
Auch die Version 0.9 läuft seit heute mittag problemlos im Wirkbetrieb.
Die persistenten Readings [A-Z]_ sind dauerhaft und die mit _ verschwinden nach einem Modify, die Timer-Readings werden korrekt zweistellig angezeigt und die alten Timer-Readings wurden gelöscht. Das Wiki ist angepasst, ich warte nur noch darauf, den Hinweis auf die Beta-Version entfernen zu können :)
Gut, mein Haus steht auch noch ;)
Dann werde ich es einchecken und dann schauen wir mal, was morgen passiert.
Mehr will ich erst mal nicht rein packen.
Gruß
Damian
Zitat von: Ellert am 15 November 2016, 22:54:29
Ehrlich gesagt, ich habe für mich noch nichts gefunden, um checkall einzusetzen.
Ich hätte vielleicht einen Fall für "Checkall". Ich habe ein DOIF das mich alarmiert wenn gewisse werte älter als x sind. Dann gehe ich davon aus das irgendetwas nicht stimmt und schicke mir einen Alarm. Also ein läuft mein System noch richtig Check...
Mir ist aufgefallen das
[HeizThermo.Wohnzimmer:temperature:sec] > 28800 nicht zwingend funktioniert, wenn ich dazu ein
[+:11] nehme dann klappt es, denn dann erzeuge ich mir ja das nötige Event. Ich habe einige DOELSEIFs...
Jetzt zum Checkall. Ich würde mir vorstellen das ich bei Checkall = 1 nur ein mal
[+:11] beim DOIF benötige und dieses nicht für jedes DOELSEIF benötige...
Hier ein Codeausschnitt...:
DOIF
( [+:11] and
[HeizThermo.Wohnzimmer:temperature:sec] > 28800 ## MAX Check
)( set pushandy msg 'Alarm' 'Curren Value Check - MAX' )
DOELSEIF
( [+:11] and
[Arbeitszimmer.Temp:temperature:sec] > 14400 ## AZ Check
)( set pushandy msg 'Alarm' 'Curren Value Check - AZ' )
Zitat von: iamandy am 26 November 2016, 20:59:09
Ich hätte vielleicht einen Fall für "Checkall". Ich habe ein DOIF das mich alarmiert wenn gewisse werte älter als x sind. Dann gehe ich davon aus das irgendetwas nicht stimmt und schicke mir einen Alarm. Also ein läuft mein System noch richtig Check...
Mir ist aufgefallen das [HeizThermo.Wohnzimmer:temperature:sec] > 28800 nicht zwingend funktioniert, wenn ich dazu ein [+:11] nehme dann klappt es, denn dann erzeuge ich mir ja das nötige Event. Ich habe einige DOELSEIFs...
Jetzt zum Checkall. Ich würde mir vorstellen das ich bei Checkall = 1 nur ein mal [+:11] beim DOIF benötige und dieses nicht für jedes DOELSEIF benötige...
Hier ein Codeausschnitt...:
DOIF
( [+:11] and
[HeizThermo.Wohnzimmer:temperature:sec] > 28800 ## MAX Check
)( set pushandy msg 'Alarm' 'Curren Value Check - MAX' )
DOELSEIF
( [+:11] and
[Arbeitszimmer.Temp:temperature:sec] > 14400 ## AZ Check
)( set pushandy msg 'Alarm' 'Curren Value Check - AZ' )
checkall funktioniert nur bei Ereignissen. Zeittrigger sind nur zum Triggerzeitpunkt wahr und sonst nicht, deswegen macht es auch keinen Sinn die Bedingungen zu prüfen, wo der Zeittrigger nicht ausgelöst hat.
Edit: Ich sehe gerade, dass du natürlich die anderen Zeittrigger weglassen willst. Es wird wohl dennoch nicht funktionieren, da checkall z. Zt. nur bei Events funtioniert.
Zitat von: Ellert am 09 November 2016, 12:38:03
Das Bild, wie DOIF im Frontend aussehen kann, habe ich mal angehängt.
Genau das finde ich Klasse! Nicht ein Frontend-Modul und ein aktives Modul, die nicht kompatibel sind, sondern einfach ein Modul. Danke für Eure Mühe, die Ihr da rein steckt.
Ich habe mir gerade mal das Beispiel aus dem Wiki importiert, um es in Ruhe zu genießen. Übrigens auch eine klasse Idee, mit den Labor-Beispielen!
Zusatzfrage: Ist es auch möglich die eingestellten Zeiten zu verändern. Konkret möchte ich gerade täglich/nächtlich die Startzeit 5 Minuten vor- und die Endzeit 5 Minuten zurückverlegen um täglich 10 Minuten mehr Laufzeit zu erreichen.
nachfragende Grüße
Niels
ZitatIst es auch möglich die eingestellten Zeiten zu verändern. Konkret möchte ich gerade täglich/nächtlich die Startzeit 5 Minuten vor- und die Endzeit 5 Minuten zurückverlegen um täglich 10 Minuten mehr Laufzeit zu erreichen.
Du kannst auf + klicken und mit den Schiebereglern die Zeit einstellen. Mit klick auf - werden die Zeiten übernommen.
Ja klar, aber ich will das automatisieren, da wir den täglichen manuellen Eingriff nicht konsequent hin bekommen. Ein setstate wie beim RAW-Import geht ja leider nicht.
automatisierte Grüße
Niels
Warum möchtest Du setstate nutzen? Es geht aber.
Hallo,
tolle neue Features. Ich würde damit gerne meine DOIFs etwas standardisieren und auf der Tablet UI bearbeiten können. Dazu müsste ich aber die Werte der Readings auswerten können.
Bsp:
([$SELF:P_condition:0])
(set Esszimmer on)
DOELSE
(set Esszimmer off)
Im Reading P_condition würde ich gerne eine beliebige Condition angeben können, bspw. $we. Ich habe schon geschweifte und spitze Klammern eingesetzt, jedoch bisher ohne Erfolg. Übersehe ich irgendetwas, oder kann man die Readings in DOIF derzeit nicht "evaluieren"?
Dankbar für einen kleinen Tipp.
Vielen Dank!
Markus
Zitat von: _Markus_ am 27 November 2016, 16:47:47
Hallo,
tolle neue Features. Ich würde damit gerne meine DOIFs etwas standardisieren und auf der Tablet UI bearbeiten können. Dazu müsste ich aber die Werte der Readings auswerten können.
Bsp:
([$SELF:P_condition:0])
(set Esszimmer on)
DOELSE
(set Esszimmer off)
Im Reading P_condition würde ich gerne eine beliebige Condition angeben können, bspw. $we. Ich habe schon geschweifte und spitze Klammern eingesetzt, jedoch bisher ohne Erfolg. Übersehe ich irgendetwas, oder kann man die Readings in DOIF derzeit nicht "evaluieren"?
Dankbar für einen kleinen Tipp.
Vielen Dank!
Markus
Hast Du schon mal (eval("[$SELF:P_condition,0]")) versucht?
Zitat von: Ellert am 27 November 2016, 17:49:46
Hast Du schon mal (eval("[$SELF:P_condition,0]")) versucht?
ohne Anführungszeichen wird es funktionieren, wenn in P_condition reines Perl drin steckt.
Das werde ich nachher mal versuchen. Allerdings ziele ich auf mehr als nur reines Perl ab. Ich würde gerne eine beliebige DOIF condition in ein Reading schreiben und dann mit dem DOIF auswerten.
Zitat von: _Markus_ am 27 November 2016, 19:15:30
Das werde ich nachher mal versuchen. Allerdings ziele ich auf mehr als nur reines Perl ab. Ich würde gerne eine beliebige DOIF condition in ein Reading schreiben und dann mit dem DOIF auswerten.
die DOIF-condition ist bis auf Angaben in eckigen Klammern: Perl, dh. im Reading darf man dann keine Angaben in eckigen Klammern angeben.
Zitat von: Ellert am 27 November 2016, 12:50:31
Warum möchtest Du setstate nutzen? Es geht aber.
Problem saß vor der Tastatur. Ich hatte viel zu viel gespielt. Aber ich habe da noch was Anderes, was mir nicht ganz ok erscheint. Ich habe mein DOIF etwas angepasst damit es alle aktivieren und deaktivieren können:
defmod di_Test_enable DOIF ([08:00])
attr di_Test_enable devStateIcon disabled:general_aus_fuer_zeit:enable .*:general_an_fuer_zeit:disable
attr di_Test_enable room DOIF_LaborDas funktioniert auch nach wie vor prima, bis ich setList benutze:
defmod time_switch_Labor2 DOIF ([[$SELF:P_mybegin,"00:00"]])\
attr time_switch_Labor2 alias Schaltuhr2
attr time_switch_Labor2 devStateIcon disabled:general_aus_fuer_zeit:enable .*:general_an_fuer_zeit:disable
attr time_switch_Labor2 group Labor: Zeitsteuerung abschaltbar
attr time_switch_Labor2 readingList P_mybegin P_myend
attr time_switch_Labor2 room DOIF_Labor
attr time_switch_Labor2 setList P_mybegin:time P_myend:time
attr time_switch_Labor2 webCmd P_mybegin:P_myendJetzt kann ich mein DOIF prima deaktivieren, nur nicht wieder aktivieren. Selbst mit
set time_switch_Labor2 enable geht nix mehr. Soll das so und ich verstehe nur den tieferen Sinn dahinter nicht?
deaktiviert Grüße
Niels
Zitat von: Muschelpuster am 27 November 2016, 20:59:07
Problem saß vor der Tastatur. Ich hatte viel zu viel gespielt. Aber ich habe da noch was Anderes, was mir nicht ganz ok erscheint. Ich habe mein DOIF etwas angepasst damit es alle aktivieren und deaktivieren können:defmod di_Test_enable DOIF ([08:00])
attr di_Test_enable devStateIcon disabled:general_aus_fuer_zeit:enable .*:general_an_fuer_zeit:disable
attr di_Test_enable room DOIF_LaborDas funktioniert auch nach wie vor prima, bis ich setList benutze:defmod time_switch_Labor2 DOIF ([[$SELF:P_mybegin,"00:00"]])\
attr time_switch_Labor2 alias Schaltuhr2
attr time_switch_Labor2 devStateIcon disabled:general_aus_fuer_zeit:enable .*:general_an_fuer_zeit:disable
attr time_switch_Labor2 group Labor: Zeitsteuerung abschaltbar
attr time_switch_Labor2 readingList P_mybegin P_myend
attr time_switch_Labor2 room DOIF_Labor
attr time_switch_Labor2 setList P_mybegin:time P_myend:time
attr time_switch_Labor2 webCmd P_mybegin:P_myendJetzt kann ich mein DOIF prima deaktivieren, nur nicht wieder aktivieren. Selbst mit set time_switch_Labor2 enable geht nix mehr. Soll das so und ich verstehe nur den tieferen Sinn dahinter nicht?
deaktiviert Grüße
Niels
Du hast die 2. Regex fürs Icon zu weit gefasst, disabled matched auch.
Zitat von: Ellert am 27 November 2016, 22:40:56Du hast die 2. Regex fürs Icon zu weit gefasst, disabled matched auch.
Ja, aber das matched doch von links nach rechts und durchsucht den Rest hinter einem Match nicht mehr, oder?
Es funktioniert ja auch einwandfrei, solange ich kein setList im Spiel habe/hatte. Aber jetzt funktioniert es auch mit der Liste ???
Nun ja, ich passe das mal Deinen Hinweisen entspr. an:
attr time_switch_Labor2 devStateIcon attr time_switch_Labor2 devStateIcon disabl.*:general_aus_fuer_zeit:enable .*:general_an_fuer_zeit:disable .*rro.*:icoToolgeordnete Grüße
Niels
Hi,
wow, setList ist ein tolles Feature, vielen Dank! Das spart mir viele dummy-devices!!
Ein Wunsch jedoch:
A-Z_<persistent user defined readingname>
ist für mich höchst unschön, wenn meine Heizungs-Anschaltzeit plötzlich einen Prefix bekommt.
Wie wärs, mit einem Attribute: "userStaticReadings" oder nur "staticReadings"?
attr xx staticReadings on|off|Heizungsmodus
ich denke, das wäre nicht unlogischer und sowas wird ja an anderer Stelle auch schon verwendet.
Noch ein Punkt: Sollte nicht der State von "initialized" geändert werden, nachdem ein Reading per set aktualisiert wurde?
Ich nutze initialized, um bestimmte defaultwerte zu überprüfen, diese Überprüfung ist später nicht mehr notwendig, daher würde ich hier eine Änderung vorschlagen.
Edit 1: Rechtschreibfehler, format
Edit2: Nachtrag state
@Damian: Danke für die Antwort.
Könnte man im Modul dafür sorgen, dass ausgewertete Readings wiederum evaluiert werden, so dass man auch Eckige Klammern in Readings spezifizieren könnte?
Zum Beispiel indem man in der sub ReplaceReadingEvalDoIf
$block=$ret;
ersetzt durch:
$block=ReplaceReadingEvalDoIf($hash, $ret, 0)
Siehst du da ungewünschte Seiteneffekte? Kenne deinen Code nicht wirklich gut...
BG! Markus
Zitat von: _Markus_ am 28 November 2016, 11:30:33
@Damian: Danke für die Antwort.
Könnte man im Modul dafür sorgen, dass ausgewertete Readings wiederum evaluiert werden, so dass man auch Eckige Klammern in Readings spezifizieren könnte?
Zum Beispiel indem man in der sub ReplaceReadingEvalDoIf
$block=$ret;
ersetzt durch:
$block=ReplaceReadingEvalDoIf($hash, $ret, 0)
Siehst du da ungewünschte Seiteneffekte? Kenne deinen Code nicht wirklich gut...
BG! Markus
Die Funktion wird an verschiedenen Stellen benutzt, mal mit, mal ohne Auswertung, daher kann ich die Folgen z. Zt. gar nicht abschätzen.
Was steht den konkret in deinem Reading?
Zitat von: JoeALLb am 28 November 2016, 10:08:33
Hi,
wow, setList ist ein tolles Feature, vielen Dank! Das spart mir viele dummy-devices!!
Ein Wunsch jedoch:
A-Z_<persistent user defined readingname>
ist für mich höchst unschön, wenn meine Heizungs-Anschaltzeit plötzlich einen Prefix bekommt.
Wie wärs, mit einem Attribute: "userStaticReadings" oder nur "staticReadings"?
attr xx staticReadings on|off|Heizungsmodus
ich denke, das wäre nicht unlogischer und sowas wird ja an anderer Stelle auch schon verwendet.
Noch ein Punkt: Sollte nicht der State von "initialized" geändert werden, nachdem ein Reading per set aktualisiert wurde?
Ich nutze initialized, um bestimmte defaultwerte zu überprüfen, diese Überprüfung ist später nicht mehr notwendig, daher würde ich hier eine Änderung vorschlagen.
Edit 1: Rechtschreibfehler, format
Edit2: Nachtrag state
Tja, ist natürlich alles Ansichtssache. Dafür müsste der User für jedes Reading das Attribut pflegen. Warum kann deine Heizungsausschaltzeit nicht mit H_ (wie Heizung) oder A_ (wie Ausschaltzeit) beginnen?
Der Status Initialized ist gekoppelt an das cmd-Reading und das ist entscheidend für die Zustandsverwaltung des Moduls - daher schlecht realisierbar.
Zitat von: Damian am 28 November 2016, 19:32:22
Tja, ist natürlich alles Ansichtssache. Dafür müsste der User für jedes Reading das Attribut pflegen. Warum kann deine Heizungsausschaltzeit nicht mit H_ (wie Heizung) oder A_ (wie Ausschaltzeit) beginnen?
Kann.. schon, ist aber unlogisch und muss man ihn einem Jahr noch verstehen. Außerdem arbeite ich viel am Handy und "_" ist da ungünstig.
Sorry, aber das wirkt für mich zu sehr nach krücke, das andere wäre für mich die logischere Methode, die mich mehr an andere Module erinnert.
Ich würde viel lieber die Liste pflegen.... die ich für dblogexclude, event-on-.*, etc. auch schon pflegen muss....
Aber wie gesagt: Gesamt ist das ein tolles Feature, und wollte ich mir auch schon mehrmals wünschen!!
Zitat von: JoeALLb am 28 November 2016, 10:08:33
Hi,
wow, setList ist ein tolles Feature, vielen Dank! Das spart mir viele dummy-devices!!
Ein Wunsch jedoch:
A-Z_<persistent user defined readingname>
ist für mich höchst unschön, wenn meine Heizungs-Anschaltzeit plötzlich einen Prefix bekommt.
Wie wärs, mit einem Attribute: "userStaticReadings" oder nur "staticReadings"?
attr xx staticReadings on|off|Heizungsmodus
ich denke, das wäre nicht unlogischer und sowas wird ja an anderer Stelle auch schon verwendet.
Noch ein Punkt: Sollte nicht der State von "initialized" geändert werden, nachdem ein Reading per set aktualisiert wurde?
Ich nutze initialized, um bestimmte defaultwerte zu überprüfen, diese Überprüfung ist später nicht mehr notwendig, daher würde ich hier eine Änderung vorschlagen.
Edit 1: Rechtschreibfehler, format
Edit2: Nachtrag state
Selbst erzeugte Readings werden bei einem Modfiy gelöscht, das kannst Du umgehen, in dem Du über "Raw definition" editierst, dabei werden die Readings wieder gesetzt, sind also quasi persistent.
Zitat von: JoeALLb am 28 November 2016, 19:56:26
Kann.. schon, ist aber unlogisch und muss man ihn einem Jahr noch verstehen. Außerdem arbeite ich viel am Handy und "_" ist da ungünstig.
Sorry, aber das wirkt für mich zu sehr nach krücke, das andere wäre für mich die logischere Methode, die mich mehr an andere Module erinnert.
Ich würde viel lieber die Liste pflegen.... die ich für dblogexclude, event-on-.*, etc. auch schon pflegen muss....
Aber wie gesagt: Gesamt ist das ein tolles Feature, und wollte ich mir auch schon mehrmals wünschen!!
Das könnte man als zusätzliches Feature einbauen - wenn ich wieder Zeit habe. Ansonsten kann sich das Ellert anschauen. Die Stelle zum Löschen der Readings ist eindeutig im Modul zu finden.
Gruß
Damian
Hallo Damian,
a) Ich stelle gerade Dummys auf DOIF um. Dabei habe ich festgestellt, dass $SELF bei Berechnungen in den Attributen "wait" und "state" nicht funktioniert.
Das funktioniert in "state"
{([TestStatus:cmd]*5)}und dies nicht
{([$SELF:cmd]*5)}Für
wait 0,300,[$SELF:P_bmofrdur]*60wird eine Fehlermeldung erzeugt
ZitatPERL WARNING: Argument "*main::60" isn't numeric in addition (+) at ./FHEM/98_DOIF.pm line 1733
Das ist nicht tragisch, da ich den Namen direkt angeben kann.
b) Wenn man Gerätenamen in der Definition des DOIF angibt, dann werden sie unter "Probably associated with" aufgelistet.
Das klappt für Gerätenamen, die im Attribut "state" verwendet werden nicht.
Es werden auch Gerätenamen aufgelistet, die als Kommentar angegeben sind.
Leider kann man keine Definition erstellen, die nur einen Kommentar enthält, weil eine Fehlermeldung erzeugt wird.
define Test DOIF ## Geraet1 liefert
ZitatTest DOIF: no left bracket of condition:
Es gibt nur einen Fall, wo ich das nutzen würde, ist also auch nicht tragisch.
c)Garantiert persistente Reading beginnen mit
[A-Z]_.
Spricht etwas dagegen alle Readings nicht zu löschen, ausser die vom DOIF selbst erzeugten?
Also nur
ZitatDevice
state
error
cmd.*
e_.*
timer_.*
wait_.*
matched_.*
und alle, die zukünftig dazu kommen oder die ich vergessen habe.
Wer dann die nicht garantiert persistenten Readings nutzt, muss das Risiko einer zukünftigen Verwendung durch DOIF in Kauf nehmen.
Dann könnte man sich ein weiteres Attribute sparen. Das Risiko bestünde dort auch.
Dein Lösungsvorschlag für c) würde mir natürlich aus reichen!
Einen Wunsch den ich noch hätte, wäre folgender.
Ich kann aber verstehen, wenn du den nur auf sehr niedrige Priorität setzt::
Ich habe oft sehr lange DOIFs, mit über 20 DOELSE:
Dabei verschiebt sich immer mal wieder die Reihenfolge von "cmdState"-Einträgen,
was nicht sonderlich leicht ist, diese wieder korrekt herauszulesen.
Mein Wunsch wäre, diese Namen direkt in den Prüfungen selbst mit anzugeben
([[Urlaubs:on:"(\d\d:\d\d)"]] #DIname=Urlaubsprüfung)
((set telegram message xxxx))
DOELSEIF ([[Urlaubs:off:"(\d\d:\d\d)"]] #DIname=UrlaubEnde)
Natürlich wäre für mich auch die Regex-Schreibweise denkbar:
(?<Urlaubsprüfung>)
Zitat von: JoeALLb am 28 November 2016, 19:56:26Sorry, aber das wirkt für mich zu sehr nach krücke
Also da sehe ich im FHEM aber andere Baustellen, welche die Assoziation eher verdient haben. Aber hey, das steht ja jedem frei es besser zu programmieren ;)
Ich stimme Ellert zu: Man könnte ja auch sagen, dass nur die User-Readings nicht gelöscht werden, also nur die Standard-Readings. Aber vielleicht ist es auch cool, wenn man auch sagen kann, dass User-Readings gelöscht werden - auch wenn mir gerade die Idee dazu fehlt. OK, wenn ich ein Reading nicht mehr brauche, kann ich es in anderen Devices nicht löschen...
Aber wenn schon ein Attribut zum User Reading, dann würde ich dafür plädieren, dass man dieses nur für User-Readings setzt, welche gelöscht werden sollen und nicht umgekehrt.
entspannte Grüße
Niels
Zitat von: Muschelpuster am 29 November 2016, 10:59:42
[...] kann ich es in anderen Devices nicht löschen[...]
klar geht das!
deletereading <DEVICE> <reading>
Zitat von: Ellert am 29 November 2016, 10:37:57
Hallo Damian,
a) Ich stelle gerade Dummys auf DOIF um. Dabei habe ich festgestellt, dass $SELF bei Berechnungen in den Attributen "wait" und "state" nicht funktioniert.
Das funktioniert in "state"
{([TestStatus:cmd]*5)}
und dies nicht
{([$SELF:cmd]*5)}
Für
wait 0,300,[$SELF:P_bmofrdur]*60
wird eine Fehlermeldung erzeugt
Das ist nicht tragisch, da ich den Namen direkt angeben kann.
b) Wenn man Gerätenamen in der Definition des DOIF angibt, dann werden sie unter "Probably associated with" aufgelistet.
Das klappt für Gerätenamen, die im Attribut "state" verwendet werden nicht.
Es werden auch Gerätenamen aufgelistet, die als Kommentar angegeben sind.
Leider kann man keine Definition erstellen, die nur einen Kommentar enthält, weil eine Fehlermeldung erzeugt wird.
define Test DOIF ## Geraet1 liefert Es gibt nur einen Fall, wo ich das nutzen würde, ist also auch nicht tragisch.
c)
Garantiert persistente Reading beginnen mit [A-Z]_.
Spricht etwas dagegen alle Readings nicht zu löschen, ausser die vom DOIF selbst erzeugten?
Also nurund alle, die zukünftig dazu kommen oder die ich vergessen habe.
Wer dann die nicht garantiert persistenten Readings nutzt, muss das Risiko einer zukünftigen Verwendung durch DOIF in Kauf nehmen.
Dann könnte man sich ein weiteres Attribute sparen. Das Risiko bestünde dort auch.
Ich denke alle drei Punkte ließen sich durchaus ohne großen Aufwand realisieren.
Zitat von: JoeALLb am 29 November 2016, 11:02:14
klar geht das!
deletereading <DEVICE> <reading>
Und wieder was gelernt ;)
Dann gehen mir auch die Ideen ;)
lernfähige Grüße
Niels
Zitat von: JoeALLb am 29 November 2016, 10:55:13Mein Wunsch wäre, diese Namen direkt in den Prüfungen selbst mit anzugeben
Wie trennst du das bei Sub-States (cmd1_1)(cmd1_2) ab, wenn du z.B.
wait einsetzt? Da hast du keine extra Bedingungen in Klammern.
Zitat von: Per am 29 November 2016, 13:15:00
Wie trennst du das bei Sub-States (cmd1_1)(cmd1_2) ab, wenn du z.B. wait einsetzt?
Gleich wie bisher, also mit Trenner. Da es dann trotzdem nahe am Punkt mit dabei steht, wäre es meiner Meinung nach dennoch viel übersichtlicher.
wait wäre hier für mich übrigens auch viel übersichtlicher und vom Zusammenhang her besser platziert... Habe nur ich so große DOIFs?
Aber vermutlich wäre die neue Syntax vom bisherigen zu unterschiedlich...
beispiel:
([[Urlaubs:on:"(\d\d:\d\d)"]] #DIname=Urlaubsprüfung|Sub-States #DIwait=1,0,2)
OK, so ergibt das Sinn. Gefällt mir, dabei fällt auch gleich der Mischmasch mit den Trennern (":" und "|") weg.
Aber: ich (!) möchte das nicht programmieren müssen :D Muss ich aber zum Glück auch nicht...
Zitat von: JoeALLb am 29 November 2016, 13:34:33
Gleich wie bisher, also mit Trenner. Da es dann trotzdem nahe am Punkt mit dabei steht, wäre es meiner Meinung nach dennoch viel übersichtlicher.
wait wäre hier für mich übrigens auch viel übersichtlicher und vom Zusammenhang her besser platziert... Habe nur ich so große DOIFs?
Aber vermutlich wäre die neue Syntax vom bisherigen zu unterschiedlich...
beispiel:
([[Urlaubs:on:"(\d\d:\d\d)"]] #DIname=Urlaubsprüfung|Sub-States #DIwait=1,0,2)
Man kann sicher Vieles anders und auch besser machen. Aber das Modul hat sich über zwei Jahre weiter entwickelt und hat inzwischen eine gewisse Komplexität erreicht, die jetzt schon einige erschlägt. Bei über 30.000 offiziell genutzten Modulen steht die Kompatibilität und Stabilität an erster Stelle. Jede Änderung des Moduls kann diese zunichtemachen.
Das wären Änderungen, die stark das Modul verändern würden, aber keine echte neue Funktionalität mitbringen würden.
Es steht jedem offen ausgehend von der Idee des Moduls ein neues und besseres zu entwickeln.
Gruß
Damian
Zitat von: Damian am 29 November 2016, 16:06:07
Das wären Änderungen, die stark das Modul verändern würden, aber keine echte neue Funktionalität mitbringen würden.
Servus und danke fürs Feedback. Sorry, sollte ich dich damit "beleidigt" haben, das war natürlich keinesfalls mein Ansinnen.
Ich Gebe Dir völlig recht, dass es andere Prioritäten gibt, weshalb ich meinen Wunsch auch sehr vorsichtig fomuliert habe.
Gerade durch die häufige Nutzung und die universelle Einsetzbarkeit deines tollen Moduls bringt die Übersichtlichkeit eben manchmal an ihre Grenzen, weshalb
ich eben nur mitdenken wollte und einen sinnvollen Verbesserungsvorschlag zur weiteren Vereinfachung machen wollte. (Dein ganzes Modul bringt ja hauptsächlich kaum neue Funktionalität,
sondern eine massive Vereinfachung des bisher dagewesenem). Ich denke auch, dass dies die Supportanfragen reduzieren
würde, da mehr Anwender ihre Fehler selbst, bzw. früher erkennen könnten... (gerade mit waits, etc. lese ich des Öfteren von Fehlern)
... Ich hatte nur einen Traum, und wer weiß, vielleicht entwickelt sich in den nächsten Jahren doch etwas in diese Richtung... ;-)
Zitat von: JoeALLb am 29 November 2016, 16:18:53
... Ich hatte nur einen Traum, und wer weiß, vielleicht entwickelt sich in den nächsten Jahren doch etwas in diese Richtung... ;-)
Neue Ideen sind immer willkommen. Allerdings ist meine Zeit für die Weiterentwicklung recht begrenzt, da ich noch andere Verpflichtungen habe.
Zitat von: JoeALLb am 29 November 2016, 16:18:53
Servus und danke fürs Feedback. Sorry, sollte ich dich damit "beleidigt" haben, das war natürlich keinesfalls mein Ansinnen.
Ich Gebe Dir völlig recht, dass es andere Prioritäten gibt, weshalb ich meinen Wunsch auch sehr vorsichtig fomuliert habe.
Gerade durch die häufige Nutzung und die universelle Einsetzbarkeit deines tollen Moduls bringt die Übersichtlichkeit eben manchmal an ihre Grenzen, weshalb
ich eben nur mitdenken wollte und einen sinnvollen Verbesserungsvorschlag zur weiteren Vereinfachung machen wollte. (Dein ganzes Modul bringt ja hauptsächlich kaum neue Funktionalität,
sondern eine massive Vereinfachung des bisher dagewesenem). Ich denke auch, dass dies die Supportanfragen reduzieren
würde, da mehr Anwender ihre Fehler selbst, bzw. früher erkennen könnten... (gerade mit waits, etc. lese ich des Öfteren von Fehlern)
... Ich hatte nur einen Traum, und wer weiß, vielleicht entwickelt sich in den nächsten Jahren doch etwas in diese Richtung... ;-)
Wenn Du für cmdState das Widget textField-long spezifizierst, ist es leicht die Übersicht zu behalten, dann entsprechen die Zeilennummern dem Befehlszweig. Ich nutze das für wait - cmdState habe ich nicht probiert. Schreib mal ob es geht.
Zitatc)
Garantiert persistente Reading beginnen mit [A-Z]_.
Spricht etwas dagegen alle Readings nicht zu löschen, ausser die vom DOIF selbst erzeugten?
@JoeALLb: Es sollte mit der anliegenden Version klappen. Bitte mal testen.
@Damian: Siehst Du Dir es mal an, habe ich zu löschende Readings vergessen?
Zitat von: Ellert am 29 November 2016, 16:36:43
@JoeALLb: Es sollte mit der anliegenden Version klappen. Bitte mal testen.
@Damian: Siehst Du Dir es mal an, habe ich zu löschende Readings vergessen?
Ich denke, dass sollten sie sein, wenn nicht noch irgendetwas Seltenes irgendwo schlummert.
Ein Einzeiler für die Abfrage sollte doch ausreichen:
=~ "^(state|error|cmd|e_...
Zitat von: Ellert am 29 November 2016, 16:29:07
Wenn Du für cmdState das Widget textField-long spezifizierst[...]
Ja, klappt wundervbar, danke! Ich hatte CoreMirror bis jetzt gar nicht aktiviert, da ich den Mehrwert nicht wirklich erkannte.
So hat esnatürlich einen tollen Nutzen!
((Jetzt bräuchte ich nur noch eine Möglichkeit, die DOELSE's durchzunummerieren ;-) )
Zitat von: Ellert am 29 November 2016, 16:36:43
@JoeALLb: Es sollte mit der anliegenden Version klappen. Bitte mal testen.
Sehr cool... habe gleich alle "A_" wieder zurückgebaut und bin begeistert! Vielen Dank!!
Zitat((Jetzt bräuchte ich nur noch eine Möglichkeit, die DOELSE's durchzunummerieren ;-) )
Mach`s wie hier (http://www.fhemwiki.de/wiki/DOIF/Tools_und_Fehlersuche#Strukturierung_der_Definition) beschrieben.
Zitat von: JoeALLb am 29 November 2016, 17:02:18
Sehr cool... habe gleich alle "A_" wieder zurückgebaut und bin begeistert! Vielen Dank!!
Man sollte allerdings sich immer dessen bewusst sein, dass zukünftig neue modulspezifische Readings dazu kommen können, die man aufräumen muss und möglicherweise, wenn der Präfix übereinstimmt, irgendwelche selbst definierten mitlöscht.
Zitat von: Damian am 29 November 2016, 17:17:30
Man sollte allerdings sich immer dessen bewusst sein, dass zukünftig neue modulspezifische Readings dazu kommen können, die man aufräumen muss und möglicherweise, wenn der Präfix übereinstimmt, irgendwelche selbst definierten mitlöscht.
... In den Readings stehen ja keine fundamental-wichtigen Dinge, und wenn sie mal gelöscht werden, macht dies ja normalerweise nichts.
Ein DOIF ändert man halt manchmal mehrmals täglich, (ich nutze gerade einen Datepicker um eine heizungssteuerung zu entwickeln) und für mich war es immer Aufwand (und eine Fehlerquelle), aktuell gültige Readings (da sie zeitwerte enthielten) nach einem Ändern des DOIFS wieder zu erzeugen.
Zitat von: Damian am 29 November 2016, 16:53:36
Ich denke, dass sollten sie sein, wenn nicht noch irgendetwas Seltenes irgendwo schlummert.
Ein Einzeiler für die Abfrage sollte doch ausreichen:
=~ "^(state|error|cmd|e_...
Jetzt mit Einzeiler, könnte zum Update werden.
Zitat von: Ellert am 29 November 2016, 17:49:10
Jetzt mit Einzeiler, könnte zum Update werden.
Dann sollten wir noch Punkt a) und b) mitnehmen.
ZitatDann sollten wir noch Punkt a) und b) mitnehmen.
zu b) Du ersetzt alle Kommentare vor der Syntaxprüfung durch ein Leerzeichen, davor würde ich aussteigen, wenn $tail nur Kommentare enthält.
Aber ich habe noch keine erfolgreiche Idee, wie ich prüfe, ob nur Kommentare vorhanden sind und keine Bedingungen.
Zu a) habe ich noch nicht versucht zu lösen.
Zitat von: Ellert am 29 November 2016, 18:08:16
zu b) Du ersetzt alle Kommentare vor der Syntaxprüfung durch ein Leerzeichen, davor würde ich aussteigen, wenn $tail nur Kommentare enthält.
Aber ich habe noch keine erfolgreiche Idee, wie ich prüfe, ob nur Kommentare vorhanden sind und keine Bedingungen.
Zu a) habe ich noch nicht versucht zu lösen.
Ich schon ;)
Punkt a), b) eingebaut, Eintrag A_Z... zu UserReadings aus der Doku entfernt.
Bitte testen.
Zitat von: Damian am 29 November 2016, 18:27:20
Ich schon ;)
Punkt a), b) eingebaut, Eintrag A_Z... zu UserReadings aus der Doku entfernt.
Bitte testen.
Ja, das ist der Unterschied zwischen Meister und Lehrling ;)
Aber, es funktioniert nur b).
zu a) Mit dem DOIF und
LUM=2 und einer Änderung von
my bleibt state initialized.
Internals:
DEF ## LUM
NAME errorTest
NR 45
NTFY_ORDER 50-errorTest
STATE initialized
TYPE DOIF
Readings:
2016-11-29 19:21:52 cmd 0
2016-11-29 19:21:36 my 2
2016-11-29 19:21:52 state initialized
Devices:
Helper:
globalinit 1
last_timer 0
sleeptimer -1
Itimer:
Regexp:
State:
Attributes:
readingList my
room 0_Test
setList my:0,1,2
state {([$SELF:my] + [LUM] + 3)}
webCmd my Mit
state {([LUM] + 3)}und einer Änderung von
LUM funktioniert es.
Zitat von: Ellert am 29 November 2016, 19:46:11
Ja, das ist der Unterschied zwischen Meister und Lehrling ;)
Aber, es funktioniert nur b).
zu a) Mit dem DOIF und LUM=2 und einer Änderung von my bleibt state initialized.
Internals:
DEF ## LUM
NAME errorTest
NR 45
NTFY_ORDER 50-errorTest
STATE initialized
TYPE DOIF
Readings:
2016-11-29 19:21:52 cmd 0
2016-11-29 19:21:36 my 2
2016-11-29 19:21:52 state initialized
Devices:
Helper:
globalinit 1
last_timer 0
sleeptimer -1
Itimer:
Regexp:
State:
Attributes:
readingList my
room 0_Test
setList my:0,1,2
state {([$SELF:my] + [LUM] + 3)}
webCmd my
Mit
state {([LUM] + 3)}
und einer Änderung von LUM funktioniert es.
Da haben wir ein Problem. Die Eigentriggerung war immer schon beim state-Attribut ausgeschlossen. Ansonsten würde das Modul auf die Änderung des eigenen Status wieder reagieren (Loop).
selftrigger all hat auch nichts gebracht.
Wenn ich bei {([$SELF:my] + [LUM] + 3)} LUM ändere bleibt state initialized, da triggert doch LUM.
Ein anderes Beispiel für Raw definition
So funktioniert es
defmod errorTest DOIF ([$SELF:my])
attr errorTest do always
attr errorTest readingList my
attr errorTest room 0_Test
attr errorTest setList my:0,1,2
attr errorTest state {([errorTest:my] * 5)}
attr errorTest webCmd my
setstate errorTest 2016-11-29 20:43:58 my 1
so funktionert es nicht und ergibt den Fehler "state *main::5"
defmod errorTest DOIF ([$SELF:my])
attr errorTest do always
attr errorTest readingList my
attr errorTest room 0_Test
attr errorTest setList my:0,1,2
attr errorTest state {([$SELF:my] * 5)}
attr errorTest webCmd my
setstate errorTest 2016-11-29 20:47:38 my 0
War etwas tricky.
Jetzt noch gut testen.
Nett!!
Mit diesem Konstrukt löse ich damit übrigens auch im Moment mein cmdState-Problem
in meinem größten Doif (über 34 DOELSE)
define myDOIF (XX)
(setreading $SELF statDOIF CommandDescription)
(...)
und
attr myDOIF [$SELF:statDOIF]
Zitat von: Damian am 29 November 2016, 21:46:30
War etwas tricky.
Jetzt noch gut testen.
Folgendes DOIF und Dummy für Raw-definition:
defmod LUM dummy
attr LUM group 0SELF
attr LUM readingList humidity
attr LUM room 0_Test
attr LUM setList state:0,1,2,3
attr LUM webCmd state
setstate LUM 1
setstate LUM 2016-11-30 00:04:03 state 1
defmod errorTest DOIF (## [LUM] or [$SELF:my])
attr errorTest do always
attr errorTest group 0SELF
attr errorTest readingList my
attr errorTest room 0_Test
attr errorTest setList my:0,1,2
attr errorTest state {([$SELF:my] + [errorTest:my] + [LUM])}
attr errorTest webCmd my
setstate errorTest 2016-11-30 09:58:53 my 1
Das funktioniert.
DOIF mit wait
defmod errorTest DOIF ([LUM])
attr errorTest do always
attr errorTest group 0SELF
attr errorTest readingList my
attr errorTest room 0_Test
attr errorTest setList my:0,1,2
attr errorTest wait {([$SELF:my] + [errorTest:my] + [LUM])}
attr errorTest webCmd my
Wenn state initialized ist und my geändert wird, dann wird state auf "" gesetzt/aktualisiert.
Wenn state initialized ist und das Attribut wait übers Frontend geändert/aktualisiert wird, dann wird state auf ""/aktualisiert gesetzt.
In der Releaseversion wird state durch my nicht beeinflusst, das sollte auch so bleiben.
Nur nochmal zur Nachfrage:
"state" kann im DOIF nicht wie im dummy genutzt werden, es müssen andere Readings verwendet werden, oder?
Mit
attr errorTest readingList state
zum oberen Beispiel habe ich Schwierigkeiten....
Zitathabe ich Schwierigkeiten....
Und die wären?
Zitat von: Ellert am 30 November 2016, 10:56:25
Und die wären?
unknown argument 2 for errorTest, choose one of disable initialize enable state:0,1,2
Noch ein hoffentlich kleiner Wunsch:
Wäre es möglich, bei setList zusätzlich noch ein Linebreak als Trenner zu akzeptieren?
Meine setList wird immer recht lange und das Space als Trenner ist da sehr ungünstig. ;-)
Zitat von: JoeALLb am 30 November 2016, 11:25:38
unknown argument 2 for errorTest, choose one of disable initialize enable state:0,1,2
readingList state versuchen Hattest Du ja schon probiert.
Zitat von: JoeALLb am 30 November 2016, 11:49:06
Noch ein hoffentlich kleiner Wunsch:
Wäre es möglich, bei setList zusätzlich noch ein Linebreak als Trenner zu akzeptieren?
Meine setList wird immer recht lange und das Space als Trenner ist da sehr ungünstig. ;-)
Dies ist dafür der falsche Forumsbereich, setList ist vom Dummy adaptiert.
Aber wo ist das Problem?
Zitat von: Damian am 29 November 2016, 18:27:20
Ich schon ;)
Punkt a), b) eingebaut, Eintrag A_Z... zu UserReadings aus der Doku entfernt.
Bitte testen.
Wäre es nicht trotzdem sinnvol einen Namensraum für Benutzerreadings zu definieren?
Zitat von: Ellert am 30 November 2016, 13:41:18
Aber wo ist das Problem?
Der erste Eintrag funktioniert, die anderen haben solche Artefakte.
Ich dachte, setList sei hier eventuell "eigens" umgesetzt und hat mit dem Dummy-setList nichts gemeinsam ;-)
Zitat von: Ellert am 30 November 2016, 14:00:52
Wäre es nicht trotzdem sinnvol einen Namensraum für Benutzerreadings zu definieren?
Wozu? Ich kann mir keinen sinnvollen Grund dafür vorstellen...
Einzig wenn state (wie oben beschrieben) tatsächlich nicht funktioniert, sollte das in der Doku erwähnt werden...
Zitat von: JoeALLb am 30 November 2016, 14:06:08
Wozu? Ich kann mir keinen sinnvollen Grund dafür vorstellen...
Einzig wenn state (wie oben beschrieben) tatsächlich nicht funktioniert, sollte das in der Doku erwähnt werden...
Um hier vor geschützt zu sein: https://forum.fhem.de/index.php/topic,58556.msg530754.html#msg530754 .
Es könnte auch sein, dass DOIF plötzlich eigene Inhalte in Deine Readings schreibt.
Dieses "Problem" besteht heute mit userReadings auch schon... ich denke das kann hier vernachlässigt werden, aber gut... ist nur meine Meinung ;-)
Vielleicht reicht ein Hinweis dazu in der commandref, dass dies sein kann.
Zitat von: Ellert am 30 November 2016, 10:44:42
Wenn state initialized ist und my geändert wird, dann wird state auf "" gesetzt/aktualisiert.
Wenn state initialized ist und das Attribut wait übers Frontend geändert/aktualisiert wird, dann wird state auf ""/aktualisiert gesetzt.
In der Releaseversion wird state durch my nicht beeinflusst, das sollte auch so bleiben.
Das Problem war, das du zuerst mit state getestet hast und dann mit wait. Beim Löschen des state-Attributs wurde intern das Triggern auf $SELF nicht gelöscht.
Jetzt sollte es funktionieren.
Bei den Readings können wir evtl. in der Commandref schreiben, dass Readings mit <A_Z>_ zukunftsicher sind, weil sie für User reserviert sind und auch zukünftig nicht vom Modul selbst benutzt werden.
Zitat von: Damian am 30 November 2016, 17:35:32
Bei den Readings können wir evtl. in der Commandref schreiben, dass Readings mit <A_Z>_ zukunftsicher sind, weil sie für User reserviert sind und auch zukünftig nicht vom Modul selbst benutzt werden.
Gefällt mir, diese Lösung!
Kannst Du noch bitte kurz meinen Test mit "state" kommentieren? Sollte das gehen, oder ist das so nicht gedacht? Dann nute ich einfach ein anderes Reading. Da es bei dummys geht, denke ich jedoch, sollte dieser Fall dann auch in der Doku genannt werden.
Zitat von: JoeALLb am 30 November 2016, 17:54:40
Gefällt mir, diese Lösung!
Kannst Du noch bitte kurz meinen Test mit "state" kommentieren? Sollte das gehen, oder ist das so nicht gedacht? Dann nute ich einfach ein anderes Reading. Da es bei dummys geht, denke ich jedoch, sollte dieser Fall dann auch in der Doku genannt werden.
readingList hat Ellert vom dummy übernommen und im DOIF eingebaut. Da kann ich leider nichts zu sagen. Ich habe diesen Teil nicht programmiert.
Zitat von: JoeALLb am 30 November 2016, 17:54:40
Gefällt mir, diese Lösung!
Kannst Du noch bitte kurz meinen Test mit "state" kommentieren? Sollte das gehen, oder ist das so nicht gedacht? Dann nute ich einfach ein anderes Reading. Da es bei dummys geht, denke ich jedoch, sollte dieser Fall dann auch in der Doku genannt werden.
readingsList state und
setList state:,0,1,2 funktionieren im Dummy nur scheinbar. Das Reading state wird nicht mit an die
SetFn übergeben, damit wird
setList state:,0,1,2 zu
setList 0 1 2 reduziert. Selbst wenn ich state wieder hinzufüge, wird
state zwar gesetzt, aber an irgend einer anderen Stelle im DIOF sofort wieder mit dem wirklichen Status überschrieben.
Daher gibt es zum Setzen von
state im DOIF das Attribut
cmdState, den Befehl
setreading und
setstate.
Zitat von: Ellert am 30 November 2016, 18:43:27
Daher gibt es zum Setzen von state im DOIF das Attribut cmdState, den Befehl setreading und setstate.
Sorry, aber ich verstehe die Antwort nicht. Bedeutet das:
a) Ich soll state einfach nicht nutzen?
b) Ich soll statt state setstate nutzen? habe ich getestet, funktioniert nicht.
c) es muss zuerst noch genauer gesucht werden, wo "state" im doif nochmal geändert wird um es zu korrigieren?
Ich werde im Moment besser a) machen ;-)
Danke... Grüße
Zitat von: Damian am 30 November 2016, 17:35:32
Das Problem war, das du zuerst mit state getestet hast und dann mit wait. Beim Löschen des state-Attributs wurde intern das Triggern auf $SELF nicht gelöscht.
Jetzt sollte es funktionieren.
Bei den Readings können wir evtl. in der Commandref schreiben, dass Readings mit <A_Z>_ zukunftsicher sind, weil sie für User reserviert sind und auch zukünftig nicht vom Modul selbst benutzt werden.
Hallo Damian,
ich habe bis jetzt keine Probleme festgestellt.
Die Doku habe ich angepasst.
Zitat von: Ellert am 30 November 2016, 20:54:48
Hallo Damian,
ich habe bis jetzt keine Probleme festgestellt.
Die Doku habe ich angepasst.
Ich habe es eingecheckt. Es fehlten noch zwei Readings beim Löschen.
Hallo Damian, ich habe die Änderung für setList nachgezogen, siehe https://forum.fhem.de/index.php/topic,61742.msg532455.html#msg532455
Das Trennzeichen für setList wurde um "\n" egänzt.
Grundlage: 98_DOIF.pm 12691 2016-11-30 21:16:44Z damian-s
Danke, tolles service!
eingecheckt
getestet, funktioniert, danke!!
Hallo Damian,
ich setze die Diskussion hier mal fort.
Ich habe DOIF ergänzt, so dass per get-Befehl die Regexp für FileLog und die Definition zum Import mit "Raw definition" angezeigt wird.
Wenn es so ins DOIF darf, müsste ich die Doku ergänzen.
Grundlage: 98_DOIF.pm 12703 2016-12-03 08:07:02Z damian-s
Zitat von: Ellert am 10 Dezember 2016, 15:14:42
Hallo Damian,
ich setze die Diskussion hier mal fort.
Ich habe DOIF ergänzt, so dass per get-Befehl die Regexp für FileLog und die Definition zum Import mit "Raw definition" angezeigt wird.
Wenn es so ins DOIF darf, müsste ich die Doku ergänzen.
Grundlage: 98_DOIF.pm 12703 2016-12-03 08:07:02Z damian-s
Aus welchem DOIF hast du die Logfile-Definition erzeugt? Es fällt auf, dass bereits die erste Regex-Angabe button_...:.* schon alles abdeckt, die restlichen hier also überflüssig wären.
Ja, das ist ein schlechtes Beispiel, damit habe ich die Regexp getestet.
Mit diesem 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$","Long"] and $cmd==2)
(set lamp(1|2)_Labor000 on)
## 4
DOELSEIF ([button_Labor000:"short"] and $cmd==3)
(set lamp(1|2)_Labor000 off)
Zitat von: Ellert am 10 Dezember 2016, 16:42:34
Ja, das ist ein schlechtes Beispiel, damit habe ich die Regexp getestet.
Mit diesem 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$","Long"] and $cmd==2)
(set lamp(1|2)_Labor000 on)
## 4
DOELSEIF ([button_Labor000:"short"] and $cmd==3)
(set lamp(1|2)_Labor000 off)
Woher kommt denn Schrittschalter in der Regex?
Ü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:
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.
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.
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$" ?
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 ;D
Das hier
define testdi DOIF ([testdi:my] or [""] or [":1"] or ["di:2"] or ["^testdi$:^my: 3$"])
ergibt
testdi:my: 3|testdi:.*|.*:.*1.*|.*|.*di.*:.*2.*
Ich sehe gerade dass ": " noch durch ".." ersetzt werden muss.
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 ;D
Das hier
define testdi DOIF ([testdi:my] or [""] or [":1"] or ["di:2"] or ["^testdi$:^my: 3$"])
ergibt
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.
Wer verwalteet eigentlich das DOIF-Labor im Wiki?
ICh hätte da einen vereinfachungsvorschlag, will das aber nicht einfach abändern...
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?
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.
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.
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:
[[$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.))
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:
[[$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.
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...
([$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.
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.
Zitat von: JoeALLb am 12 Dezember 2016, 12:08:26
([$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?
Zitat von: Brockmann am 13 Dezember 2016, 08:14:46
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?
Es wird auch die Zeit wiederhergestellt, zu der das Reading geschrieben wurde. Und da diese mitgeprüft wird, funktioniert das.
Einzig, wenn die Weckzeit GENAU während dem Reboot ablaufen würde, würde diese auf den nächsten Tag verschoben werden... dies könnte man auch abfangen indem man
hier den letzten Part ergänzt.
DOELSEIF ([?$SELF:P_einaus,"off"] eq "on" and [[$SELF:P_weckzeit,"12:00"]] and [$SELF:P_weckzeit:sec]< 86400)
Habe es endlich mal geschafft, mit readingList rumzuspielen.
Mein Problem: wie bekomme ich devStateIcon mit ins Boot? ist_Befehl:icon:Userreading:soll_Befehl geht nicht, das ist ein Doppelpunkt zuviel.
Zitat von: Ellert am 08 November 2016, 10:49:15
Hier nochmal mein Testgerät
define Test DOIF (["$SELF:mybutton: ein"]) DOELSEIF (["$SELF:mybutton: aus"])
attr Test cmdState ein|aus
attr Test readingList mybutton
attr Test room 0_Test
attr Test setList mybutton:ein,aus
attr Test webCmd mybutton
Hey,
coole Sache! Danke euch beiden, dass ihr euch so viel Mühe macht!
Ich habe zu deinem "testgerät" nochmal eine Frage.
Mit deinem Original-Code bekomme ich ein Dropdown-Menü.
Mit
define DF_test DOIF ([1])()
attr DF_test readingList mybutton
attr DF_test room _doif,x_devel
attr DF_test setList mybutton:ein,aus
attr DF_test webCmd mybutton
attr DF_test widgetOverride mybutton:uzsuSelectRadio,ein,aus
bekomme ich zwei eckige Buttons. Bisher habe ich (z.B. bei dummies) mit
setList an aus
webCmd an:aus
überall diese Standard-Buttons. Falls das nur eine zu ändernde Option ist, die ich nicht kenne, würde ich gerne einheitlich bleiben und auch bei den DOIF's die Standard-Buttons verwenden. Geht das ?
Danke
Stephan
Das "normale" Eingabeelement wird mit "widgetOverride" geändert, wenn Du das nicht möchtest, lösche das Attribut widgetOverride.attr DF_test widgetOverride mybutton:uzsuSelectRadio,ein,aus "uzsuSelectRadio" schaltet die Radiobutton ein.
Hi Ellert, danke für deine Antwort!
Zitat von: Ellert am 17 Januar 2017, 18:10:42
Das "normale" Eingabeelement wird mit "widgetOverride" geändert
Ja, ist mir klar.
Zitat von: Ellert am 17 Januar 2017, 18:10:42
attr DF_test widgetOverride mybutton:uzsuSelectRadio,ein,aus "uzsuSelectRadio" schaltet die Radiobutton ein.
Ist auch klar.
Zitat von: Ellert am 17 Januar 2017, 18:10:42
wenn Du das nicht möchtest, lösche das Attribut widgetOverride.
Vermutlich habe ich mich nicht verständlich ausgedrückt:
Bitte schaue dir oben nochmal das Bild Standard-Buttons sowie das Bild Dropdown_Ellert an. ( in der Bearbeiten-Ansicht kann ich leider nicht mehr sehen, wie die Bilder wirklich heissen)
Wenn das Attribut
widgetOverride nicht gesetzt ist (= gelöscht), habe ich ein Dropdown, wie im Bild Dropdown_Ellert zu sehen.
Wenn das Attribut
widgetOverride mybutton:uzsuSelectRadio,ein,aus gesetzt (also vorhanden) ist, habe ich die großen, viereckigen Knöpfe ( wie im Bild widget-override zu sehen.
Ich möchte aber weder das Dropdown, noch die viereckigen Knöpfe, sondern die standard-fhem-Textlinks (wie im Bild Standard... ) zu sehen.
Das erreiche ich offensichtlich
weder durch setzen, noch durch weglassen von widgetOverride...
Hoffe, mein Anliegen ist jetzt etwas klarer geworden.
setList an aus
webCmd an:aus
Das funktioniert nicht, weil Du damit den Status setzt, das ist im DOIF nicht zugelassen.
Du kanst nur Readings setzen, die mit readingList definiert sind.
Um das zu präzisieren:
attr DF_test readingList mybutton
attr DF_test setList mybutton:ein,aus
Um mybutton zu ein zu setzen müsste das webCmd so aussehen:
webCmd mybutton ein
das funktioniert aber nicht, weil ein Leerzeichen im webCmd nicht erlaubt ist.
Deshalb musst Du mit eventMap mybutton ein auf einen Befehl mappen, der leerzeichenfrei ist, z.B. mybutton_ein.
Dann sieht es für einen Befehl so aus:
eventMap /mybutton ein:mybutton_ein/
webCmd mybutton_ein
Edit: es funktioniert doch.
Zitat von: Ellert am 18 Januar 2017, 10:25:21das funktioniert aber nicht, weil ein Leerzeichen im webCmd nicht erlaubt ist.
Deshalb musst Du mit eventMap mybutton ein auf einen Befehl mappen, der leerzeichenfrei ist, z.B. mybutton_ein.
Hier (https://forum.fhem.de/index.php/topic,64939.0.html) schön erklärt!
Zitat von: Ellert am 18 Januar 2017, 10:25:21
das funktioniert aber nicht, weil ein Leerzeichen im webCmd nicht erlaubt ist.
Zitat von: Per am 18 Januar 2017, 12:44:45
Hier (https://forum.fhem.de/index.php/topic,64939.0.html) schön erklärt!
Hi,
danke für eure Antworten. Mit fehlt aber der Bezug zu meiner Frage:
Dass das nicht funktioniert (wegen dem Leerzeichen) ist mir ja klar. Mir gings doch rein lediglich ausschließlich um die Darstellung ...
Zitat von: abc2006 am 18 Januar 2017, 13:34:52
Hi,
danke für eure Antworten. Mit fehlt aber der Bezug zu meiner Frage:
Dass das nicht funktioniert (wegen dem Leerzeichen) ist mir ja klar. Mir gings doch rein lediglich ausschließlich um die Darstellung ...
Wenn das nicht die Antwort war, dann versuche es so
zum Import mit Raw definition
defmod DOIF DOIF ##
attr DOIF readingList mybutton
attr DOIF webCmd mybutton an:mybutton aus
das ist ja fast so, wie ichs wollte, so nehm ichs aber auch. Danke!
Grüße
Stephan