Hi,
ausgiebige Suche hat mir bestätigt, dass es grundsätzlich möglich ist, bei einem at die Einschaltzeit über dummy zu konfigurieren:
Dummy:
Internals:
CFGFN
NAME dum_Uhrzeit_Licht_morgens_an
NR 27416
STATE 06:50
TYPE dummy
Readings:
2015-02-20 22:41:36 state 06:50
Attributes:
room Cfg_HUE
setList state:time
at:
define at_Licht_morgens_an at *{Value("dum_Uhrzeit_Licht_morgens_an")} {
Log 1, ("Licht Küche morgens einschalten.");
fhem("set struc_HUEs_Kueche on");
fhem("set HUEDevice2 ct 380 : bri 254 : transitiontime 1 : noUpdate");
fhem("set HUEDevice3 ct 380 : bri 254 : transitiontime 1 : noUpdate");
}
}
Meine Frage ist: Wie oft wird die für at hinterlegte Uhrzeit dem Wert im dummy angepasst? Ich wollte das eben mal testen und habe im Dummy eine 2 oder 3 Minuten in der Zukunft befindliche Zeit eingestellt. Es passierte nichts und im Logfile war nichts zu sehen - was wohl bedeutet, dass zu dem relevanten Zeitpunkt der geänderte Wert im Dummy das at noch nicht erreicht hatte.
In welchem Rythmus wird da aktualisiert?
Danke, Christian
ZitatIn welchem Rythmus wird da aktualisiert?
Nach der Ausfuehrung wird die naechste Ausfuehrungszeit bestimmt. 1-mal.
Man koennte fuer dein Szenario per notify auf dem dummy ein modify auf dem at absetzen.
Einfacher ist die Detailansicht der at zu verwenden, und die Uhrzeit da zu aendern.
Ich habe das at Modul mit dem set Befehl modifyTimeSpec erweitert, damit kann man in der Raumuebersicht per webCmd eine Aenderung vornehmen. Das via webCmd aufrufbare time Widget funktioniert nur fuer "einfache" Zeitspezifikationen wie *22:00, nicht fuer komplexere wie *{sunset()}
Siehe Anhang, definiert mit
define atSetTest at *07:25 set ddd off
attr atSetTest webCmd modifyTimeSpec
Danke, praktisch. Was ich gerade festgestellt habe: Mein at oben verschwindet beim Neustart von fhem und hinterlässt als Spuren folgende Meldungen:
Error messages while initializing FHEM:
configfile: the at function "Value("dum_Uhrzeit_Licht_morgens_an")" must return a timespec and not .statefile: Please define at_Licht_morgens_an first
Es scheint, dass der dummy am Anfang nicht sinnvoll initialisiert ist und den alten Wert nicht schnell genug übernimmt, weswegen das at mit Fehlermeldung bei der Initialisierung rauspurzelt. Warum genau das so ist, kann ich nicht nachvollziehen, denn ein list auf den dummy nach dem Neustart von fhem ergibt:
Internals:
NAME dum_Uhrzeit_Licht_morgens_an
NR 399
STATE 06:50
TYPE dummy
Readings:
2015-02-20 22:41:36 state 06:50
Attributes:
room Cfg_HUE
setList state:time
Der dummy wird also beim Start mit dem alten state initialisiert. Aber wohl erst, nachdem der Versuch gelaufen ist, das at zu definieren...?
Heißt das, es geht so gar nicht, und ich kann nur den Weg über modifyTimeSpec gehen? Oder mache ich einen anderen Denkfehler?
Lernend, Christian
Liegt vermutlich daran, dass dum_Uhrzeit_Licht_morgens_an nach dem at definiert ist.
Wenn man die Reihenfolge umdreht, sollte dieses Problem nicht mehr geben.
Das muss ich dann aber direkt in der cfg ändern, das geht nicht über das Webinterface, richtig?
Falsch :)
Methode 1 (fuer "Normalos")
copy at_Licht_morgens_an tempAt
delete at_Licht_morgens_an
rename tempAt at_Licht_morgens_an
Methode 2 (fuer Hacker, bzw. fuer die, die wissen, dass die Reihenfolge der fhem.cfg in $defs{<NAME>}{NR} hinterlegt ist.)
{ $defs{at_Licht_morgens_an}{NR} = 400 }
In beiden Faellen ist ein save gefolgt von einem shutdown restart erforderlich.
Danke für die Antwort - ich habe das mal getestet, mit der langen Methode, Rumhacken in fhem will ich nicht, dazu verstehe ich viel zu wenig. (Was passiert, wenn ich NR auf eine schon vergebene NR setze...? Nee. :) )
Test:
dum_Licht_morgens_an hat NR 399.
at_Licht_morgens_an hat nach dem Kopieren, Löschen, Umbenennen NR 497.
save config, restart.
Meldung:
Error messages while initializing FHEM:
configfile: the at function "Value("dum_Uhrzeit_Licht_morgens_an")" must return a timespec and not ???.statefile: Please define at_Licht_morgens_an first
Log:
2015.02.24 12:26:30 1: Including fhem.cfg
2015.02.24 12:26:30 3: telnetPort: port 7072 opened
2015.02.24 12:26:30 3: WEB: port 8083 opened
2015.02.24 12:26:30 3: WEBphone: port 8084 opened
2015.02.24 12:26:30 3: WEBtablet: port 8085 opened
2015.02.24 12:26:30 2: eventTypes: loaded 10539 events from ./log/eventTypes.txt
2015.02.24 12:26:30 1: HMLAN_Parse: HMUSB new condition disconnected
2015.02.24 12:26:30 3: Opening HMUSB device 192.168.1.24:1000
2015.02.24 12:26:30 3: Can't connect to 192.168.1.24:1000: Verbindungsaufbau abgelehnt
2015.02.24 12:26:31 3: WEBuser: port 8082 opened
2015.02.24 12:26:31 3: WEBhook: port 8081 opened
2015.02.24 12:26:31 3: Registering GEOFANCY geofancy for URL /geo...
2015.02.24 12:26:31 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.02.24 12:26:31 3: Opening HMLAN1 device 192.168.1.25:1000
2015.02.24 12:26:31 3: HMLAN1 device opened
2015.02.24 12:26:31 1: HMLAN_Parse: HMLAN1 new condition init
2015.02.24 12:26:31 3: Opening Marantz device 192.168.1.22:23
2015.02.24 12:26:31 3: Marantz device opened
2015.02.24 12:26:32 1: HMLAN_Parse: HMLAN2 new condition disconnected
2015.02.24 12:26:32 3: Opening HMLAN2 device 192.168.1.26:1000
2015.02.24 12:26:32 3: HMLAN2 device opened
2015.02.24 12:26:32 1: HMLAN_Parse: HMLAN2 new condition init
2015.02.24 12:26:32 3: Opening CUL1 device /dev/ttyACM0
2015.02.24 12:26:33 3: Setting CUL1 baudrate to 9600
2015.02.24 12:26:33 3: CUL1 device opened
2015.02.24 12:26:33 3: CUL1: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.02.24 12:26:33 3: HUEDevice3: I/O device is HUEBridge1
2015.02.24 12:26:33 3: HUEDevice2: I/O device is HUEBridge1
2015.02.24 12:26:33 3: HUEDevice1: I/O device is HUEBridge1
2015.02.24 12:26:33 3: HUEGroup0: I/O device is HUEBridge1
2015.02.24 12:26:35 1: define at_Licht_morgens_an at_Licht_morgens_an at *{Value("dum_Uhrzeit_Licht_morgens_an")} {
Log 1, ("Licht Küche morgens einschalten.");
fhem("set struc_HUEs_Kueche on");
fhem("set HUEDevice2 ct 380 : bri 254 : transitiontime 1 : noUpdate");
fhem("set HUEDevice3 ct 380 : bri 254 : transitiontime 1 : noUpdate");
}
}: the at function "Value("dum_Uhrzeit_Licht_morgens_an")" must return a timespec and not ???.
2015.02.24 12:26:35 1: Including ./log/fhem.save
2015.02.24 12:26:35 1: configfile: the at function "Value("dum_Uhrzeit_Licht_morgens_an")" must return a timespec and not ???.statefile: Please define at_Licht_morgens_an first
2015.02.24 12:26:36 3: Harmony: connected
2015.02.24 12:26:36 1: usb create starting
2015.02.24 12:26:36 1: usb create end
2015.02.24 12:26:36 2: Error messages while initializing FHEM: configfile: the at function "Value("dum_Uhrzeit_Licht_morgens_an")" must return a timespec and not ???.statefile: Please define at_Licht_morgens_an first
2015.02.24 12:26:36 0: Server started with 423 defined entities (version $Id: fhem.pl 8066 2015-02-22 13:33:26Z rudolfkoenig $, os linux, user hammi, pid 17396)
2015.02.24 12:26:36 1: HMLAN_Parse: HMLAN1 new condition ok
User:
ratlos, um weitere Hilfe bittend
Da habe ich wohl zu kurz gedacht. Das Problem:
- at will die Uhrzeit-Diefinition beim Ausfuehren des define Befehls wissen, das passiert beim Einlesen der fhem.cfg
- der dummy hat aber zur dieser Zeit den Initialwert ??? , das "richtige" Wert wird erst spaeter, beim Einlesen von fhem.state gesetzt.
Ein "define name at *{Value(dummy)} ... " wird nie eine restart ueberleben.
Alternative:
define dum_Uhrzeit_Licht_morgens_an dummy
attr dum_Uhrzeit_Licht_morgens_an setList state:time
attr dum_Uhrzeit_Licht_morgens_an webCmd state
define at_Licht_morgens_an at *00:00 {..}
define ntfy_Licht_morgens_an notify dum_Uhrzeit_Licht_morgens_an { fhem("modify at_Licht_morgens_an *$EVENT") }
Danach dummy einstellen.
Oder modifyTimeSpec verwenden.
Ganz vergessen: Ich wollte mich hier noch bedanken, denn so klappt es. Danke!