Moin,
ich habe ein Problem mit DOIF_Readings.
Ich möchte in ein internes Reading eine Zeit setzen (im HH:MM:SS Format) und das in einem weiteren Reading die gleiche Zeit in Sekunden setzen.
Ich habe im Forum die Funktion hms2secs gefunden und implementiert. Die Funktion ist auch gegeben. Allerdings werden die Sekunden nur beim einrichten des DOIF_Readings berechnet. Danach nicht mehr.
Im readingList steht Waittime, im DOIF_Readings WaitSec:{hms2secs(ReadingsVal("$SELF","Waittime",0))}
Beim set DOIF... Waittime 01:00:00 bleibt der Wert bei WaitSec der alte Wert.
Das DOIF reagiert selbst nicht auf eine Änderung von Waittime.
Hier der Hintergrund:
Ich möchte über FTUI meine Klingel deaktivieren und mit einen Datetimepicker in FTUI eine Wartezeit zum Reaktivieren der Klingel mittels at setzen.
Das DOIF ist erstmal zum Testen:
DEF ([$SELF:Klingel] eq "on")
(set $SELF KameraURL http://192.168.0.5/camera/httppreview , IF ([Kodi:playStatus] eq "playing") (set Kodi pause all , set Kodi msg 'fhem' 'Es hat geklingelt!' 10000 info) , IF ([$SELF:Status] eq "off") (set FritzBox call [$SELF:TelNr])) (set $SELF KameraURL 0)
DOELSEIF
([$SELF:Status] eq "off")
({ Log 1, "Klingel aus" } , defmod a2 at +[$SELF:Waittime] set DOIF_Klingel Status on)
DOELSEIF
([$SELF:Status] eq "on")
({ Log 1, "Klingel an" } , set $SELF Waittime 02:00:00)
DOELSE
FUUID 5da5585f-f33f-2b06-5167-a6416d7bd94bbac6
MODEL FHEM
NAME DOIF_Klingel
NOTIFYDEV global,DOIF_Klingel
NR 143
NTFY_ORDER 50-DOIF_Klingel
STATE initialized
TYPE DOIF
VERSION 20268 2019-09-28 21:00:39
CHANGED:
WaitSec: 7200
CHANGEDWITHSTATE:
WaitSec: 7200
DOIF_Readings:
WaitSec {hms2secs(ReadingsVal("DOIF_Klingel","Waittime",0))}
READINGS:
2019-10-15 21:22:18 KameraURL 0
2019-10-15 21:21:48 Klingel on
2019-10-16 21:51:51 Status on
2019-10-15 08:51:56 TelNr 01xxxxxxxxxx
2019-10-17 06:38:32 WaitSec 7200
2019-10-16 21:51:51 Waittime 02:00:00
2019-10-17 06:38:32 cmd 0
2019-10-17 06:38:32 mode enabled
2019-10-17 06:38:32 state initialized
Regex:
accu:
cond:
DOIF_Klingel:
0:
Klingel ^DOIF_Klingel$:^Klingel:
1:
Status ^DOIF_Klingel$:^Status:
2:
Status ^DOIF_Klingel$:^Status:
attr:
cmdState:
wait:
0:
0
30
1:
0
2:
0
waitdel:
condition:
0 ::ReadingValDoIf($hash,'DOIF_Klingel','Klingel') eq "on"
1 ::ReadingValDoIf($hash,'DOIF_Klingel','Status') eq "off"
2 ::ReadingValDoIf($hash,'DOIF_Klingel','Status') eq "on"
do:
0:
0 set DOIF_Klingel KameraURL http://192.168.0.5/camera/httppreview , IF ([Kodi:playStatus] eq "playing") (set Kodi pause all , set Kodi msg 'fhem' 'Es hat geklingelt!' 10000 info) , IF ([DOIF_Klingel:Status] eq "off") (set FritzBox call [DOIF_Klingel:TelNr])
1 set DOIF_Klingel KameraURL 0
1:
0 { Log 1, "Klingel aus" } , defmod a2 at +[DOIF_Klingel:Waittime] set DOIF_Klingel Status on
2:
0 { Log 1, "Klingel an" } , set DOIF_Klingel Waittime 02:00:00
3:
0
helper:
DEVFILTER ^global$|^DOIF_Klingel$
NOTIFYDEV global|DOIF_Klingel
globalinit 1
last_timer 0
sleeptimer -1
triggerDev
triggerEvents
triggerEventsState
readings:
all DOIF_Klingel:Klingel DOIF_Klingel:Status
uiState:
uiTable:
Attributes:
DOIF_Readings WaitSec:{hms2secs(ReadingsVal("$SELF","Waittime",0))}
do always
genericDeviceType MotionSensor
homebridgeMapping MotionDetected=Klingel,values=on:1;off:0
readingList Klingel KameraURL Status TelNr Waittime
room Homebridge
siriName Klingel
wait 0,30:0:0
Meine Vermutung ist, dass DOIF nicht auf die Änderung von Waittime reagiert, weil das ein internes Reading ist.
Habt ihr einen Tipp für mich?
Danke und Gruß
Ben
ZitatIch möchte über FTUI meine Klingel deaktivieren und mit einen Datetimepicker in FTUI eine Wartezeit zum Reaktivieren der Klingel mittels at setzen.
Fangen wir mal hier an.
Ist die Klingel ein Device? wie wäreein List davon?
"deaktivieren über FTUI" - wie willst Du das tun?
"mittels at" - wo ist das?
Wofür ist dann das DOIF?
Reading Klingel <-> Status Wert, wann warum?
Vielleicht kann ich es dann durchschauen.
Die Klingel ist noch kein Device. Das wird aber ein ESPEasy mit angeschlossenem Relais.
Relais angezogen, Klingel deaktiviert. Am Eingang vom ESP kommt der Klingeltaster, damit der an FHEM weitergeleitet wird. Momentan simuliere ich das über das Klingel Reading im DOIF, welches ich manuell setze.
Über FTUI mache ich das Deaktivieren mittels Switch und der integrierten countdown Anzeige.
Schaltet man den switch im FTUI, wird im DOIF das Reading Status auf off gesetzt.
Darauf reagiert das DOIF und setzt entsprechend die Klingel auf off (in meinem Test erstmal nur den Logeintrag) und halt das at: defmod a2 at +[$SELF:Waittime] set DOIF_Klingel Status on)
Damit der Countdown im Switch widget angezeigt werden kann (data-countdown="DOIF_Klingel:WaitSec"), muss die Wartezeit in Sekunden vorliegen.
Daher die Umrechnung von HH:MM:SS in Sekunden.
Außerdem kann man über FTUI die Wartezeit verändern, mittels datetimepicker widget. Das widget sendet die Zeit an das DOIF Reading Waittime, das Reading WaitSec wird allerdings nicht geändert. Auch nicht, wenn ich das Reading Waittime direkt ändere.
Bei FTUI bin ich raus. Hier ist noch jemand der dort einen Counter will https://forum.fhem.de/index.php/topic,104551.msg984278.html#msg984278 (https://forum.fhem.de/index.php/topic,104551.msg984278.html#msg984278)
Was habe ich verstanden?
Es wird ein Device Klingel geben (state on = jemand Klingelt) und Reading Status (on aktiviert; off deaktiviert).
Wenn jemand klingelt, dann wird etwas getan, egal ob aktiv oder nicht.
Wenn die Klingel deaktivert ist, dann soll nach einer Zeit der Status wieder auf aktiviert gesetzt werden. Das sollte ohne at im DOIF mit wait gehen.
Wenn die Klingel aktiviert wird, dann soll waittime auf einen Standardwert gesetzt werden.
Ich würde estmal das Klingeldevice anlegen, z.B. als Dummy. Dort sehe ich auch das Reading Status.
Dann käme das DOIF mit den Reaktionen auf die Klingel und ohne Änderung der Zeit.
Wenn das klappt würde ich versuchen waittime variabel zu gestalten. Was soll bei einer Anpassung während der Deaktivierung passieren?
Wenn das alles klappt, dann käme bei mir die Darstellung in FTUI.
ZitatWas habe ich verstanden?
Es wird ein Device Klingel geben (state on = jemand Klingelt) und Reading Status (on aktiviert; off deaktiviert).
Wenn jemand klingelt, dann wird etwas getan, egal ob aktiv oder nicht.
Wenn die Klingel deaktivert ist, dann soll nach einer Zeit der Status wieder auf aktiviert gesetzt werden.
Genau so soll es sein.
ZitatDas sollte ohne at im DOIF mit wait gehen.
Wenn ich das richtig verstanden habe, dann wartet DOIF bei wait so lange mit der Ausführung, bis entweder die Zeit abgelaufen ist, oder eine andere Bedingung wahr wird.
Was bedeutet, betätigt jemand den Klingeltaster während der Wartezeit zum Reaktivieren, wird wait abgebrochen und somit die Klingel nicht reaktiviert.
ZitatWenn die Klingel aktiviert wird, dann soll waittime auf einen Standardwert gesetzt werden.
Auch richtig.
ZitatIch würde estmal das Klingeldevice anlegen, z.B. als Dummy. Dort sehe ich auch das Reading Status.
Das hatte ich bisher nicht gemacht, weil ich der Meinung bin, dass DOIF so komplex geworden ist, dass man dafür kein Dummy mehr braucht. Dafür gibt es ja die readingList usw...
Außerdem ist der ESP später ein eigenes Device, auf dessen Event man reagieren muss. Ich könnte das ins DOIF mit einbinden, dass bei einem Klingeltaster Event der on-off Wert in einen Dummy geschrieben wird. Aber auch hierfür gibt es eigentlich readingList etc.
ZitatWas soll bei einer Anpassung während der Deaktivierung passieren?
Wenn man während der Deaktivierung die Waittime ändert? Nichts weiter, außer natürlich, dass WaitSec den Sekundenwert von Waittime annimmt.
In FTUI ist das leider nicht so leicht mit einem Countdown. Die countdown Funktion vom Switch widget benötigt leider einen Sekundenwert, der einmalig eingelesen wird und dann einfach runter läuft.
Andernfalls müsste man ein Reading haben, welches sich ständig aktualisiert um einen Countdown zu visualisieren.
Nur um das noch mal zu sagen, die Funktion vom DOIF und das Zusammenspiel vom Switch widget und dem DOIF funktionieren genau so wie gewünscht. Nur die Änderung des Waittime Readings resultiert nicht in einer Änderung des WaitSec Readings.
Zitataußer natürlich, dass WaitSec den Sekundenwert von Waittime annimmt.
Darauf zielte die Frage. Also doch nicht nichts. :)
ZitatAußerdem ist der ESP später ein eigenes Device,
Solange Du das nicht hast brauchst Du einen Ersatz zur Simulation. Das wäre z.B. ein Dummy.
Jetzt versuchst Du die Klingel als DOIF zu betrachten, das geht eher nicht.
Zitatbetätigt jemand den Klingeltaster während der Wartezeit zum Reaktivieren, wird wait abgebrochen
stimmt, das muss man berücksichtigen.
Wenn du die gesamte Logik in einem DOIF unterbringen willst, dann würde ich dir den Perl-Modus empfehlen, dort kannst du unabhängige Zweige definieren und ebenfalls mit "wait"-Timern arbeiten.
Wenn du die gesamte Logik in einem DOIF unterbringen willst, dann würde ich dir den Perl-Modus empfehlen, dort kannst du unabhängige Zweige definieren und ebenfalls mit "wait"-Timern arbeiten.
Wie würde das denn konkret aussehen, in dem Fall, dass bei einer Änderung von Waittime das DOIF_Reading WaitSec aktualisiert?
Das at muss nicht unbedingt in mein DOIF integriert werden.
ZitatSolange Du das nicht hast brauchst Du einen Ersatz zur Simulation. Das wäre z.B. ein Dummy.
Jetzt versuchst Du die Klingel als DOIF zu betrachten, das geht eher nicht.
Naja, ich betrachte als Dummy momentan "DOIF_Klingel:Klingel". Das DOIF reagiert auf sich selbst mit ([$SELF:Klingel] eq "on"). Attr do always ist auch gesetzt.
Das einzige was vielleicht in einen Dummy muss wäre Waittime. Also define DUMMY dummy mit readingList Waittime. Damit das
DOIF_Reading WaitSec:{hms2secs(ReadingsVal("DUMMY","Waittime",0))} auf das externe Event vom DUMMY reagieren kann.
Meine Variante, das DUMMY zu umgehen mit readingList Waittime und:
DOIF_Reading WaitSec:{hms2secs(ReadingsVal("$SELF","Waittime",0))}scheint nicht zu funktionieren. :-\
EDIT:
Habe es gerade mal probiert mit dem DUMMY.
Das DOIF_Reading WaitSec ändert sich trotzdem nicht. ???
Die Funktion in der 99_myutils lautet:
sub hms2secs($){
my ($t) = @_;
return substr($t,0,2) * 3600 + substr($t,3,2) * 60 + substr($t,6,2);
}
Ich lasse mich gern belehren, aber bis dahin bleibe ich dabei: Ein ESP kann in FHEM kein Device vom Typ DOIF sein.
ZitatIch lasse mich gern belehren, aber bis dahin bleibe ich dabei: Ein ESP kann in FHEM kein Device vom Typ DOIF sein.
Das stimmt natürlich, ich werde später, wenn der ESP existiert, das DOIF ändern von:
([$SELF:Klingel] eq "on")in
([ESPEasy:Klingel] eq "on")Momentan reagiert das DOIF ja auf
([$SELF:Klingel] eq "on")wenn ich in die FHEM Befehlszeile
set DOIF_Klingel Klingel oneingebe.
Ausprobiert habe ich auch
DOELSEIF
([$SELF:Waittime])
(set $SELF WaitSec {hms2secs(ReadingsVal("DOIF_Klingel","Waittime",0))})
Funktioniert auch nicht. Auch nicht, wenn WaitSec kein DOIF_Reading sondern ein readingList ist. Denn dann steht im Reading WaitSec nur {hms2secs(ReadingsVal("DOIF_Klingel","Waittime",0))}
aber halt nicht der Wert.
Zitat von: SirBen am 17 Oktober 2019, 11:17:53ich werde später, wenn der ESP existiert, das DOIF ändern von:
([$SELF:Klingel] eq "on")
in
([ESPEasy:Klingel] eq "on")
Dann ist das auch ein anderes Gerät. Zur Zeit ist es ein Gerät und DOIF braucht dafür die Erlaubnis, sich selbst triggern zu dürfen.
Der Dummy als Ersatz für den ESP hat den Vorteil, dass man das DOIF nicht verändern muss, wenn der ESP als Device angelegt wird.
Einfach den Dummy umbenennen und deaktivieren oder gleich löschen. Der ESP bekommt den Namen und ggf. die Userreadings und es geht weiter.
Schon vom Standpunkt des Testens/Rollout sinnvoll. 8)
Ich fasse nochmal kurz zusammen:
In meinem DOIF wird ein Reading "Waittime" gesetzt (von außen) mit einer Zeit im Format HH:MM:SS.
Ich habe eine Sub Routine in 99_myUtils:
sub hms2secs($){
my ($t) = @_;
return substr($t,0,2) * 3600 + substr($t,3,2) * 60 + substr($t,6,2);
}
Diese funktioniert, wenn man z.B. in die FHEM Kommandozeile eingibt: {hms2secs(ReadingsVal("DOIF_Klingel","Waittime",0))}, als Ergebnis erhält man die Zeit in Sekunden.
Jetzt möchte ich diese Sub benutzen, um die Umrechnung von HH:MM:SS in Sekunden durchzuführen und das Ergebnis soll in einem weiteren Reading gespeichert werden.
Dazu gibt es laut commandref das Attribut "DOIF_Readings".
Mit
attr DOIF_Klingel DOIF_Readings WaitSec:{hms2secs(ReadingsVal("DOIF_Klingel","Waittime",0))}
wird das Reading in meinem DOIF erstellt (WaitSec) und die Zeit in Sekunden in diesem Reading gespeichert.
Ändert sich das Reading Waittime, ändert sich das Reading WaitSec NICHT.
Selbst wenn ich das Reading Waittime in ein Dummy packe und das DOIF_Reading entsprechend anpasse, ändert sich im Reading WaitSec weiterhin nichts.
Es scheint also der Aufruf der Sub Routine "hms2secs" nicht zu funktionieren.
Die DEF vom DOIF selbst sieht so aus:
DEF ([$SELF:Klingel] eq "on")
(set $SELF KameraURL http://192.168.0.5/camera/httppreview , IF ([Kodi:playStatus] eq "playing") (set Kodi pause all , set Kodi msg 'fhem' 'Es hat geklingelt!' 10000 info) , IF ([$SELF:Status] eq "off") (set FritzBox call [$SELF:TelNr])) (set $SELF KameraURL 0)
DOELSEIF
([$SELF:Status] eq "off")
({ Log 1, "Klingel aus" } , defmod a2 at +[$SELF:Waittime] set DOIF_Klingel Status on)
DOELSEIF
([$SELF:Status] eq "on")
({ Log 1, "Klingel an" } , set $SELF Waittime 02:00:00)
DOELSE
Es wird also mit dem DOIF nicht auf die Änderung des Readings Waittime reagiert. Das funktioniert mit dem DOIF_Reading normalerweise automatisch.
Das mit dem Dummy Ersatz für den ESP ist richtig und bestimmt auch besser als meine Variante. Ich denke, das hat mit meiner Problematik nur nichts zu tun. :-\
ZitatErzeugen berechneter Readings
Mit Hilfe des Attributes DOIF_Readings können eigene Readings innerhalb des DOIF definiert werden, auf die man im selben DOIF-Moduls zugreifen kann. Die Nutzung ist insbesondere dann sinnvoll, wenn zyklisch sendende Sensoren, im Perl-Modus oder mit dem Attribut do always, abgefragt werden. DOIF_Readings-Berechnungen funktionieren ressourcenschonend ohne Erzeugung FHEM-Events nach außen. Änderungen dieser Readings triggern allerdings das eigene DOIF-Modul, allerdings nur, wenn sich deren Inhalt ändert.
Syntax
Code: [Auswählen]
attr <DOIF-Modul> DOIF_Readings <readingname1>:<definiton>, <readingname2>:<definition>,...
<definition>: Beliebiger Perlausdruck ergänzt um DOIF-Syntax in eckigen Klammern. Angaben in eckigen Klammern wirken triggernd und aktualisieren das definierte Reading.
Kann es sein, dass mein Reading sich nicht aktualisiert weil ich keine eckigen Klammern bei DOIF_Readings habe? ???
Gibt es dafür einen Workaround?
Du kannst eckige Klammern drum machen wie du willst, das ist eine (bzw. zwei) Funktion(en).
Versuch es mal mit:
{hms2secs([DOIF_Klingel:Waittime])}
und
WaitSec:{hms2secs([$SELF:Waittime])}
Zitat von: SirBen am 17 Oktober 2019, 12:52:31Ich denke, das hat mit meiner Problematik nur nichts zu tun. :-\
Doch, das angesprochene Attribut Selftrigger!
So würde ich es machen, hier als Zweizeiler mit List-Attributen zum Setzen des aktiv-Readings:
defmod klingel_di DOIF {if ([Klingel] eq "on" and [?$SELF:aktiv] eq "on") {fhem_set"Gong on"}}\
{if ([$SELF:aktiv] eq "on") {set_Exec("timer",3600,'set_Reading("aktiv","off")')}}
attr klingel_di readingList aktiv
attr klingel_di setList aktiv:on,off
Das Reading aktiv kann per set on/off Kommando im DOIF gesetzt werden. Es wird dann nach 3600 Sekunden automatisch wieder auf off gesetzt. Wenn aktiv auf on gesetzt ist und die Klingel gedrückt wird, dann geht der Gong an.
Zitat von: Damian am 17 Oktober 2019, 14:45:37
So würde ich es machen, hier als Zweizeiler mit List-Attributen zum Setzen des aktiv-Readings:
defmod klingel_di DOIF {if ([Klingel] eq "on" and [?$SELF:aktiv] eq "on") {fhem_set"Gong on"}}\
{if ([$SELF:aktiv] eq "on") {set_Exec("timer",3600,'set_Reading("aktiv","off")')}}
attr klingel_di readingList aktiv
attr klingel_di setList aktiv:on,off
Das Reading aktiv kann per set on/off Kommando im DOIF gesetzt werden. Es wird dann nach 3600 Sekunden automatisch wieder auf off gesetzt. Wenn aktiv auf on gesetzt ist und die Klingel gedrückt wird, dann geht der Gong an.
Puh, wie kann ich hier den laufenden Timer in ein Reading schreiben?
Zitat von: Per am 17 Oktober 2019, 14:09:58
Du kannst eckige Klammern drum machen wie du willst, das ist eine (bzw. zwei) Funktion(en).
Versuch es mal mit:
{hms2secs([DOIF_Klingel:Waittime])}
und
WaitSec:{hms2secs([$SELF:Waittime])}
Doch, das angesprochene Attribut Selftrigger!
Mit den eckigen Klammern funktioniert es jetzt.
Wenn ich
WaitSec:{hms2secs([DUMMY:Waittime])}eintrage und den DUMMY ändere, dann ändert sich auch das Reading WaitSec!
Sehr schön. :)
Lasse ich den DUMMY weg und ändere im DOIF das Reading Waittime, dann ändert sich das Reading WaitSec mit:
WaitSec:{hms2secs([$SELF:Waittime])}nur, wenn das Attribut selftrigger all gesetzt ist.
Vielen Dank für die ganzen Hinweise und Ratschläge!
Der Laufende Timer wird automatisch im entsprechenden Reading geschrieben. Warum willst du den auslesen? Mit set_Exec kannst du einen laufenden Timer verlängern oder vorzeitig mit del_Exec beenden, mit get_Exec kannst du die Restlaufzeit jederzeit abfragen, siehe https://fhem.de/commandref_DE.html#DOIF_Ausf%C3%BChrungstimer. Es gibt also im Perl-Modus genügend Möglichkeiten Timer zu verändern ohne irgendwelche Umrechnungsklimmzüge anzustellen.
Edit: Wenn du nur die Zeitvorgabe auswerten willst, dann kannst du das genauso machen:
defmod klingel_di DOIF {if ([Klingel] eq "on" and [?$SELF:aktiv] eq "on") {fhem_set"Gong on"}}\
{if ([$SELF:aktiv] eq "off") {set_Exec("timer",::hms2secs(ReadingsVal("klingel_di","Waittime",0)),'set_Reading("aktiv","on")')}}
attr klingel_di readingList aktiv
attr klingel_di setList aktiv:on,off
Zitat von: Damian am 17 Oktober 2019, 15:18:02
Der Laufende Timer wird automatisch im entsprechenden Reading geschrieben. Warum willst du den auslesen? Mit set_Exec kannst du einen laufenden Timer verlängern oder vorzeitig mit del_Exec beenden, mit get_Exec kannst du die Restlaufzeit jederzeit abfragen, siehe https://fhem.de/commandref_DE.html#DOIF_Ausf%C3%BChrungstimer. Es gibt also im Perl-Modus genügend Möglichkeiten Timer zu verändern ohne irgendwelche Umrechnungsklimmzüge anzustellen.
Edit: Wenn du nur die Zeitvorgabe auswerten willst, dann kannst du das genauso machen:
defmod klingel_di DOIF {if ([Klingel] eq "on" and [?$SELF:aktiv] eq "on") {fhem_set"Gong on"}}\
{if ([$SELF:aktiv] eq "off") {set_Exec("timer",::hms2secs(ReadingsVal("klingel_di","Waittime",0)),'set_Reading("aktiv","on")')}}
attr klingel_di readingList aktiv
attr klingel_di setList aktiv:on,off
Habe das mal so umgesetzt.
Mein Timer Reading sieht allerdings nur so aus:
timer_timer: 17.10.2019 15:56:01Leider ist das Reading nicht in Sekunden.
ZitatLasse ich den DUMMY weg und ändere im DOIF das Reading Waittime, dann ändert sich das Reading WaitSec mit:
WaitSec:{hms2secs([$SELF:Waittime])}
nur, wenn das Attribut selftrigger all gesetzt ist.
Ich muss mich selbst verbessern. Die oben angegebene Variante funktioniert auch OHNE selftrigger all.
Komischerweise wird WaitSec beim ersten aktualisieren von Waittime nicht mit aktualisiert. Danach funktioniert das Aktualisieren aber jedes Mal.
Zitat von: SirBen am 17 Oktober 2019, 15:52:01
Habe das mal so umgesetzt.
Mein Timer Reading sieht allerdings nur so aus:
timer_timer: 17.10.2019 15:56:01
Leider ist das Reading nicht in Sekunden.
Und wozu brauchst du das Reading in Sekunden?
Weil das Switch Widget in FTUI für Data-Countdown einen Wert in Sekunden benötigt.
Zitat von: SirBen am 17 Oktober 2019, 19:36:56
Weil das Switch Widget in FTUI für Data-Countdown einen Wert in Sekunden benötigt.
Na, dann
defmod klingel_di DOIF {if ([Klingel] eq "on" and [?$SELF:aktiv] eq "on") {fhem_set"Gong on"}}\
{if ([$SELF:aktiv] eq "off") {set_Reading("waitsecs",::hms2secs(get_Reading("Waittime",0)));;set_Exec("timer",get_Reading("waitsecs"),'set_Reading("aktiv","on")')}}
attr klingel_di readingList aktiv
attr klingel_di setList aktiv:on,offPS: DOIF_Reading auf DOIF_Readings kann nicht gut funktionieren, da DOIF_Readings keine Events nach außen produzieren.
Zitat von: Damian am 17 Oktober 2019, 19:56:51
Na, dann
defmod klingel_di DOIF {if ([Klingel] eq "on" and [?$SELF:aktiv] eq "on") {fhem_set"Gong on"}}\
{if ([$SELF:aktiv] eq "off") {set_Reading("waitsecs",::hms2secs(get_Reading("Waittime",0)));;set_Exec("timer",get_Reading("waitsecs"),'set_Reading("aktiv","on")')}}
attr klingel_di readingList aktiv
attr klingel_di setList aktiv:on,off
PS: DOIF_Reading auf DOIF_Readings kann nicht gut funktionieren, da DOIF_Readings keine Events nach außen produzieren.
DOIF_Readings habe ich verwendet, weil ich nach außen keine Events haben wollte. Sonst hätte ich event_readings genommen. Das Switch Widget zieht sich den Wert beim Schalten, benötigt kein Event.
Das DOIF von dir habe ich zu Testzwecken mal eingerichtet. Funktioniert super!
Dann ist die Perl Variante von dir sicherlich Ressourcen schonender, als meine FHEM Variante, oder?
Vielen Dank für die Mühe!
@Damian
Eine Frage habe ich noch. Bei DOIF_Readings scheint ein Bug zu sein. Wenn ich irgendein Attribut vom DOIF verändere, dann reagiert das DOIF_Reading beim ersten Event nicht. Erst beim zweiten. Beim 3. und 4. usw. reagiert es auch sofort.
Kannst du das nachvollziehen?
Edit:
Habe noch ein paar Tests gemacht. Das Problem tritt nur auf, wenn im DOIF_Reading ein Reading vom DOIF selbst steht. Also z.B:
readingList Wert1
DOIF_Reading Wert2:{[$SELF:Wert1]+3}
Zitat von: SirBen am 18 Oktober 2019, 08:29:51
@Damian
Eine Frage habe ich noch. Bei DOIF_Readings scheint ein Bug zu sein. Wenn ich irgendein Attribut vom DOIF verändere, dann reagiert das DOIF_Reading beim ersten Event nicht. Erst beim zweiten. Beim 3. und 4. usw. reagiert es auch sofort.
Kannst du das nachvollziehen?
DOIF_Readings kann nur in einfacher Tiefe auf eigene Readings reagieren:
Beispiel:
defmod doif_Reading DOIF ##
attr doif_Reading DOIF_Readings test1:[FS],\
test2:[$SELF:test1],\
test3:[$SELF:test2]FS kommt von außen, test1 und test2 werden sofort gesetzt (bei mir auch beim ersten mal), test3 funktioniert dann nicht mehr korrekt.
Perl-Modus ist halt nativ-Perl, daher ressourcenschonender und schneller. Wichtiger ist aber, dass man beliebig viele logisch unabhängige DOIFs in einem DOIF unterbringen kann.
Danke für die Antwort und die Unterstützung! Dann weiß ich erstmal Bescheid.