Hallo,
ich hab einen RandomTimer mit einem dummy "SimStopTime" parametrisiert - soweit so gut.
define ZufallsTimerHWR RandomTimer *{sunset("REAL",1000,"16:00","23:00")} gaeste_wc {Value("SimStopTime")} 600
attr ZufallsTimerHWR switchmode 800/200
attr ZufallsTimerHWR userReadings state1 {(split(" ", ReadingsVal("ZufallsTimerHWR","state","")))[0]}, state2 {(split(" ", ReadingsVal("ZufallsTimerHWR","StartTime","")))[1]}
Damit der RandomTimer Änderungen des Parameters mitbekommt, hab ich ein notify geschrieben:
define n_ZufallsTimerHWR notify SimStopTime:.*:.*:.* defmod ZufallsTimerHWR RandomTimer *{sunset("REAL",1000,"16:00","23:00")} gaeste_wc {Value("SimStopTime")} 600
Ich möcht gern verstehen, warum der RandomTimer "ZufallsTimerHWR" bei einem Neustart verschwindet bzw. dafür sorgen, dass er samt seiner userReadings erhalten bleibt >:(
Hi,
wenn Du das define ausführst, danach save drückst und dann neu startest ist das Device ZufallsTimerHWR wirklich weg?
Da bleibt nur die Vermutung, Du hast noch so etwas ? ;) https://forum.fhem.de/index.php?topic=138509.msg1315132#msg1315132
Ansonsten verändert das defmod ... die config und bleibt so nur erhalten wenn danach ein save erfolgt.
Gruß Otto
Dieter macht aktuell wegen Netatmo sowieso vor jedem Restart ein save ;D Aber das Thema ist ja gerade in Arbeit.
Ich wollte daher auch was zu global:INITIALIZED schreiben, aber dass das als zusätzlicher Trigger ins Notify muss. Dann ist egal, dass das Speichern fehlt. Trotzdem nicht schon (wie aktuell noch bei Netatmo), dass man immer speichern muss. Aber eine schönere Lösung für so eine flexible Steuerung eines Random-Timers habe ich auch nicht.
Und warum der Timer verschwindet ... auch keine Ahnung.
Viele Grüße
Thomas
Zitat von: tomcat.x am 17 Juni 2024, 14:59:47Dieter macht aktuell wegen Netatmo sowieso vor jedem Restart ein save ;D Aber das Thema ist ja gerade in Arbeit.
Da ist er der gläserne Forums-Teilnehmer ;D
Zitat von: Otto123 am 17 Juni 2024, 14:41:09Hi,
wenn Du das define ausführst, danach save drückst und dann neu startest ist das Device ZufallsTimerHWR wirklich weg?
Da bleibt nur die Vermutung, Du hast noch so etwas ? ;) https://forum.fhem.de/index.php?topic=138509.msg1315132#msg1315132
Ansonsten verändert das defmod ... die config und bleibt so nur erhalten wenn danach ein save erfolgt.
Gruß Otto
Nach einem Neustart ist der RandomTimer Weg.
Dann ändere ich meinen Parameter "SimStopTime" und das notify sorgt mit seinem defmod dafür, dass der RandomTimer angelegt wird.
Im laufenden Betrieb wird dann schön jede Änderung des Parameters durch das notify auf den Timer übertragen.
Jetzt mach ich ein Save und restart, danach ist der RandomTimer weg.
Und ja Otto, ich hatte ein notify in global:INITIALIZED stehen, aber das ist mittlerweile Geschichte ;)
Ich liste mal den kompletten Code vom RandomTimer wo wie er nach dem Auslösen des defmod erzeugt wird:define ZufallsTimerHWR RandomTimer *{sunset("REAL",1000,"16:00","23:00")} gaeste_wc {ReadingsVal("SimStopTime","state","")} 600
attr ZufallsTimerHWR switchmode 800/200
# CFGFN
# COMMAND off
# DEF *{sunset("REAL",1000,"16:00","23:00")} gaeste_wc {ReadingsVal("SimStopTime","state","")} 600
# DEVICE gaeste_wc
# FUUID 66704225-f33f-b5ae-1503-5d29247cbc116ae1
# NAME ZufallsTimerHWR
# NR 852
# STATE off
# TYPE RandomTimer
# eventCount 4
# READINGS:
# 2024-06-17 16:03:18 StartTime 2024-06-17 21:48:38
# 2024-06-17 16:03:18 StopTime 2024-06-17 22:30:00
# 2024-06-17 16:03:17 TimeToSwitch 600
# 2024-06-17 16:03:18 active 0
# 2024-06-17 16:03:18 state off
# helper:
# REL
# REP *
# SIGMAWHENOFF 800
# SIGMAWHENON 200
# STARTTIME 17.06.2024 21:48:38
# STOPTIME 17.06.2024 22:30:00
# SWITCHMODE 800/200
# S_REL
# TIMESPEC_START *{sunset("REAL",1000,"16:00","23:00")}
# TIMESPEC_STOP {ReadingsVal("SimStopTime","state","")}
# TIMETOSWITCH 600
# VAR_DURATION 0
# VAR_START 0
# active 0
# offReading state
# offRegex off
# startTime 1718653718
# stopTime 1718656200
#
setstate ZufallsTimerHWR off
setstate ZufallsTimerHWR 2024-06-17 16:03:18 StartTime 2024-06-17 21:48:38
setstate ZufallsTimerHWR 2024-06-17 16:03:18 StopTime 2024-06-17 22:30:00
setstate ZufallsTimerHWR 2024-06-17 16:03:17 TimeToSwitch 600
setstate ZufallsTimerHWR 2024-06-17 16:03:18 active 0
setstate ZufallsTimerHWR 2024-06-17 16:03:18 state off
und zur Sicherheit mal das komplette "defmod":
define n_ZufallsTimerHWR notify SimStopTime:.*:.*:.* defmod ZufallsTimerHWR RandomTimer *{sunset("REAL",1000,"16:00","23:00")} gaeste_wc {ReadingsVal("SimStopTime","state","")} 600
attr n_ZufallsTimerHWR comment Triggert die Definition bei Änderung der SimStopTime
attr n_ZufallsTimerHWR room AnwSim,GlobaleVariablen,Makros
attr n_ZufallsTimerHWR verbose 0
# DEF SimStopTime:.*:.*:.* defmod ZufallsTimerHWR RandomTimer *{sunset("REAL",1000,"16:00","23:00")} gaeste_wc {ReadingsVal("SimStopTime","state","")} 600
# FUUID 646f1b5c-f33f-b5ae-f725-ceede34343b97536
# NAME n_ZufallsTimerHWR
# NOTIFYDEV SimStopTime
# NR 666
# NTFY_ORDER 50-n_ZufallsTimerHWR
# REGEXP SimStopTime:.*:.*:.*
# STATE 2024-06-17 16:03:16
# TRIGGERTIME 1718632997.3701
# TYPE notify
# READINGS:
# 2024-06-17 15:58:58 state active
# 2024-06-17 16:03:16 triggeredByDev SimStopTime
# 2024-06-17 16:03:16 triggeredByEvent 22:30:00
#
setstate n_ZufallsTimerHWR 2024-06-17 16:03:16
setstate n_ZufallsTimerHWR 2024-06-17 15:58:58 state active
setstate n_ZufallsTimerHWR 2024-06-17 16:03:16 triggeredByDev SimStopTime
setstate n_ZufallsTimerHWR 2024-06-17 16:03:16 triggeredByEvent 22:30:00
Also ich kann das Verhalten bestätigen. Auch die Frage, ob das Problem beim Sichern in die fhem.cfg oder beim Starten auftritt, kann ich mir jetzt selbst beantworten.
Was mir gerade beim Betrachten des Logs aufgefallen ist:
define ZufallsTimerHWR RandomTimer *{sunset("REAL",1000,"16:00","23:00")} gaeste_wc {ReadingsVal("SimStopTime","state","")} 600: the function "ReadingsVal("SimStopTime","state","")" must return a timespec and not <empty string>.
Das hatte ich bei der ersten Definition, weil ich den Dummy noch nicht angelegt hatte, aber auch beim Neustart. Der Dummy muss definiert sein, bevor der Timer definiert wird. Stimmt die Reihenfolge in der fhem.cfg?
in der fhem.cfg kommen erst der dummy und das notify - direkt hintereinander:
define SimStopTime dummy
setuuid SimStopTime 646ddc84-f33f-b5ae-950e-43416d88a352bc83
attr SimStopTime readingList state
attr SimStopTime room AnwSim,GlobaleVariablen
attr SimStopTime setList setList state:20:00:00,20:15:00,20:30:00,20:45:00,21:00:00,21:15:00,21:30:00,21:45:00,22:00:00,22:15:00,22:30:00
attr SimStopTime webCmd state
define n_ZufallsTimerHWR notify SimStopTime:.*:.*:.* defmod ZufallsTimerHWR RandomTimer *{sunset("REAL",1000,"16:00","23:00")} gaeste_wc {ReadingsVal("SimStopTime","state","")} 600
setuuid n_ZufallsTimerHWR 646f1b5c-f33f-b5ae-f725-ceede34343b97536
attr n_ZufallsTimerHWR comment Triggert die Definition bei Änderung der SimStopTime
attr n_ZufallsTimerHWR room AnwSim,GlobaleVariablen,Makros
attr n_ZufallsTimerHWR verbose 0
und gaaaaanz am Ende die vom defmod erzeugte Definition des RandomTimer:
define ZufallsTimerHWR RandomTimer *{sunset("REAL",1000,"16:00","23:00")} gaeste_wc {ReadingsVal("SimStopTime","state","")} 600
setuuid ZufallsTimerHWR 66704225-f33f-b5ae-1503-5d29247cbc116ae1
attr ZufallsTimerHWR switchmode 800/200
dann empfehle ich hier mal einen ordentlichen default Wert, anstatt nur "" ;)
ReadingsVal("SimStopTime","state","19:19:19"
So als generellen Tipp wollte ich das auch noch schreiben. Aber erklärt das den Fehler (dass das Gerät nach dem Neustart weg ist)? Sobald SimStopTime definiert ist, sollte der Default-Wert egal sein.
Zitat von: tomcat.x am 17 Juni 2024, 22:28:16Aber erklärt das den Fehler (dass das Gerät nach dem Neustart weg ist)?
Eventuell: der Wert für ReadingsVal() ist beim Start leer, damit wird er RandomTimer nicht angelegt sondern wegen Fehler gelöscht/verworfen?
Zitat von: Otto123 am 17 Juni 2024, 22:49:15Zitat von: tomcat.x am 17 Juni 2024, 22:28:16Aber erklärt das den Fehler (dass das Gerät nach dem Neustart weg ist)?
Eventuell: der Wert für ReadingsVal() ist beim Start leer, damit wird er RandomTimer nicht angelegt sondern wegen Fehler gelöscht/verworfen?
Otto, you saved my day ;D
Erst mit einem default-Wert im ReadingsVal() wird der RandomTimer tatsächlich angelegt; schade, dass das "Nicht-Anlegen" nicht mit einem Log-Eintrag dokumentiert wurde ...
Otto, dir zu Ehren bleibt jetzt der Wert 19:19:19 in meinem ReadingsVal 8)
SimStopTime:.*:.*:.* defmod ZufallsTimerHWR RandomTimer *{sunset("REAL",1000,"16:00","23:00")} gaeste_wc {ReadingsVal("SimStopTime","state","19:19:19")} 600
P.S. Ein ReadingsVal mit Default-Wert zu versorgen sollte man sich tatsächlich angewöhnen :)
P.P.S. Wenn ich {Value("SimStopTime")} nicht durch {ReadingsVal()} ersetzt hätte, wär das nicht lösbar gewesen :)
Dieser Punkt geht übrigens an @frank https://forum.fhem.de/index.php?topic=138497.msg1315027#msg1315027
Das ist dann aber mehr ein Workaround oder (also abgesehen von der genrellen SInnhaftigkeit von Daufault-Werten)? Denn Du hast dann nach einem Neustart immer den Default-Wert drin und nicht Deine letzte Einstellung? Oder verhält sich das anders? Wäre interessant.
Zitat von: grappa24 am 17 Juni 2024, 23:27:28schade, dass das "Nicht-Anlegen" nicht mit einem Log-Eintrag dokumentiert wurde ...
Ich dachte es wird genau quittiert?
Zitat von: tomcat.x am 17 Juni 2024, 17:05:56Was mir gerade beim Betrachten des Logs aufgefallen ist:
Code Auswählen Erweitern
define ZufallsTimerHWR RandomTimer *{sunset("REAL",1000,"16:00","23:00")} gaeste_wc {ReadingsVal("SimStopTime","state","")} 600: the function "ReadingsVal("SimStopTime","state","")" must return a timespec and not <empty string>.
Das hatte ich bei der ersten Definition, weil ich den Dummy noch nicht angelegt hatte, aber auch beim Neustart. Der Dummy muss definiert sein, bevor der Timer definiert wird.
Das ganze Konstrukt erscheint mir allerdings abenteuerlich, vielleicht findet man für diese Aufgabe auch eine andere Lösung?
Zitat von: Otto123 am 18 Juni 2024, 11:14:55Das ganze Konstrukt erscheint mir allerdings abenteuerlich
Da hast Du auf jeden Fall Recht. Ich habe mir so was aber auch mal irgendwoher kopiert (Forum? Codeschnipsel?), aber dann nie genutzt. Die Definition im fhem habe ich aber noch als Vorlage.
Zitat von: Otto123 am 18 Juni 2024, 11:14:55vielleicht findet man für diese Aufgabe auch eine andere Lösung?
Wenn der Wert bei jedem Neustart durch den Default überschreiben werden würde, wäre auch der Komfort dahin. Frage wäre, ob man den Wert im aktuellen Fall sinnvoll durch eine Funktion ermitteln und verstellen lassen könnte, ohne manuell einzugreifen. Allerdings generell wäre es schon praktisch, wenn man irgendwie auf der Web-Oberfläche eine Einstellmöglichkeit hätte.
vielleicht hätte maintainer beta-user einen fix, wenn der thread im passenden forumsbereich wäre. ;)
FHEM/98_RandomTimer.pm Beta-User Unterstützende Dienste/Kalendermodule
Na ja, hab's trotzdem gefunden...
Weiß im Moment nicht so recht, ob ich die beiden Themen wirklich angehen will.
- "wrong timespec" ist eigentlich selbsterklärend und steht auch im log, "blöd" ist nur, dass es in dem Fall eben zum Zeitpunkt des originalen define durchläuft (Reading-Wert ist bekannt), und erst beim Neustart angemeckert wird, dass der (dann herangezogene default) Mist ist... Könnte man fixen, indem man noch $init_done prüft, bevor man die Fehlermeldung zurückgibt. Das ist übrigens (schon immer...) gebaut nach dem Muster von at...
- das mit dem defmod gefällt mir auch nicht, eigentlich müßte es einen setter geben, mit dem man den RT zur Neukalkulation seiner Grenzwerte bringen kann. Wenn ich drandenke und mal Zeit habe, baue ich vermutlich was rein.
PS: Da der RT seit einiger Zeit per InternalTimer seine Werte nach dem Neustart neu kalkuliert, sollte es zumindest keine Probleme mit dem Rückgriff auf den default-Wert geben - den braucht es dann nämlich nicht, die statefile ist dann schon gelesen :) .
....da's grade kurz geregnet hat...
Bitte testen, dann checke ich das ein...
Zitat von: tomcat.x am 18 Juni 2024, 10:19:37Das ist dann aber mehr ein Workaround oder (also abgesehen von der genrellen SInnhaftigkeit von Daufault-Werten)? Denn Du hast dann nach einem Neustart immer den Default-Wert drin und nicht Deine letzte Einstellung? Oder verhält sich das anders? Wäre interessant.
Nach einem Neustart steht tatsächlich meine letzte Einstellung drin und nicht der Default Wert, also alles gut ;)
Zitat von: Beta-User am 18 Juni 2024, 15:20:24....da's grade kurz geregnet hat...
Bitte testen, dann checke ich das ein...
d.h. anstatt defmod nutze ich dann set ZufallsTimer recomputeTimes, cool - hat funktioniert!
P.S. geht das bei einem "at" auch?
Gruß,
Dieter
Zitat von: grappa24 am 18 Juni 2024, 17:31:09Zitat von: Beta-User am 18 Juni 2024, 15:20:24....da's grade kurz geregnet hat...
Bitte testen, dann checke ich das ein...
d.h. anstatt defmod nutze ich dann set ZufallsTimer recomputeTimes, cool - hat funktioniert!
thx, hab's eingecheckt und noch den Hinweis aufgenommen, das das nichts am Schaltzustand des Devices ändert - ggf. muss man da "manuell" nachregeln...
ZitatP.S. geht das bei einem "at" auch?
Gruß,
Dieter
Keine Ahnung zu "at". Soweit ich die damalige Diskussion mit Rudi zum Initialisierungsattribut noch im Kopf habe, wollte Rudi das nicht timer-basiert umbauen (sonst hätte man das nicht gebraucht). Da gibt es aber "modifyTimeSpec", kann sein, dass das ähnlich zu verwenden ginge (?!?)?