RandomTimer "überlebt" Neustart von FHEM nicht

Begonnen von grappa24, 17 Juni 2024, 14:07:27

Vorheriges Thema - Nächstes Thema

grappa24

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  >:(
FHEM 6.3, 2 x RasPi 3B+, Debian Buster; KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200
Rollo-/Lichtsteuerung/-szenarien, T-Sensoren, Fensterkontakte, Heizungssteuerung, HEOS, Sprachsteuerung mit Alexa-FHEM, Netatmo, Nuki, ...

Otto123

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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

tomcat.x

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
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

grappa24

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
FHEM 6.3, 2 x RasPi 3B+, Debian Buster; KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200
Rollo-/Lichtsteuerung/-szenarien, T-Sensoren, Fensterkontakte, Heizungssteuerung, HEOS, Sprachsteuerung mit Alexa-FHEM, Netatmo, Nuki, ...

grappa24

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  ;)
FHEM 6.3, 2 x RasPi 3B+, Debian Buster; KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200
Rollo-/Lichtsteuerung/-szenarien, T-Sensoren, Fensterkontakte, Heizungssteuerung, HEOS, Sprachsteuerung mit Alexa-FHEM, Netatmo, Nuki, ...

grappa24

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

FHEM 6.3, 2 x RasPi 3B+, Debian Buster; KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200
Rollo-/Lichtsteuerung/-szenarien, T-Sensoren, Fensterkontakte, Heizungssteuerung, HEOS, Sprachsteuerung mit Alexa-FHEM, Netatmo, Nuki, ...

tomcat.x

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?
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

grappa24

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
FHEM 6.3, 2 x RasPi 3B+, Debian Buster; KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200
Rollo-/Lichtsteuerung/-szenarien, T-Sensoren, Fensterkontakte, Heizungssteuerung, HEOS, Sprachsteuerung mit Alexa-FHEM, Netatmo, Nuki, ...

Otto123

dann empfehle ich hier mal einen ordentlichen default Wert, anstatt nur ""  ;)
ReadingsVal("SimStopTime","state","19:19:19"
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

tomcat.x

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.
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

Otto123

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?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

grappa24

#11
Zitat von: Otto123 am 17 Juni 2024, 22:49:15
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?
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
FHEM 6.3, 2 x RasPi 3B+, Debian Buster; KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200
Rollo-/Lichtsteuerung/-szenarien, T-Sensoren, Fensterkontakte, Heizungssteuerung, HEOS, Sprachsteuerung mit Alexa-FHEM, Netatmo, Nuki, ...

tomcat.x

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.
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

Otto123

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?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

tomcat.x

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.
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo