Hi,
nach der Definition meiner at Geräte (z.B. Server Neustart) steht die Trigger-Zeit immer auf 00:00:00. Erst wenn ich in FHEMWEB im Timespec Wizard modify drücke bekomme ich ein richtiges Next angezeigt.
Jetzt frage ich mich ob intern das Datum richtig verarbeitet wird. Ist das Attribut nur zur Leserlichkeit da und alles schaltet trotzdem wie gewollt?
Wenn wir schon dabei sind - wann wird denn der nächste Trigger Zeitpunkt berechnet? Wenn ich den Zeitpunkt aus Dummies zusammensetze und die Dummies ändere, wann zieht denn dann das Verhalten?
Vielen Dank,
Matthias
Bei mir steht in TRIGGERTIME/TRIGGERTIME_FMT Datum und Zeitpunkt der naechsten Ausfuehrung.
Falls ich etwas untersuchen soll, dann brauche ich mehr Details.
Ok hier kommen mehr Details.
Die betroffenen at-Geräte greifen als TimeSpec auf eine FHEM Funktion zu:
define az_rollladen_down at *{rollladen_down_time("whg_rollladen_down_time_min","whg_rollladen_down_time_max")} {rollladen_zu("az_rollladen")}
rollladen_down_time ist eine 99_myUtils Funktion, die im Endeffekt auf Basis von ein paar Dummies twilight aufruft [1]. Nach der Definition des Timers bzw. einem Server Neustart bekommt man jetzt immer den Status next mit Mitternacht. Voller List Auszug siehe [2]. Wenn man jetzt im TimeSpec Wizard auf modify drückt, dann bekommt man Next: 18:00.
Reicht dir das so, oder kann ich dir sonst noch Infos liefern?
Vielen Dank fürs drauf gucken :-)
Matthias
[1]
sub rollladen_time($$$) {
my ($dummy_min, $dummy_max, $twilight_event) = @_;
my $dummy_min_time = Value($dummy_min);
my $dummy_max_time = Value($dummy_max);
return twilight("twilight",$twilight_event,$dummy_min_time,$dummy_max_time);
}
sub rollladen_down_time($$) {
my ($dummy_min, $dummy_max) = @_;
return rollladen_time($dummy_min, $dummy_max, "ss_indoor");
}
[2]
Internals:
CFGFN include/schlafzimmer.cfg
COMMAND {rollladen_zu("sz_tuer_rollladen");rollladen_zu("sz_fenster_rollladen")}
DEF *{rollladen_down_time("sz_rollladen_down_time_min","sz_rollladen_down_time_max")} {rollladen_zu("sz_tuer_rollladen");rollladen_zu("sz_fenster_rollladen")}
NAME sz_rollladen_down
NR 103
NTM 00:00:00
PERIODIC yes
RELATIVE no
REP -1
STATE Next: 00:00:00
TIMESPEC {rollladen_down_time("sz_rollladen_down_time_min","sz_rollladen_down_time_max")}
TRIGGERTIME 1468879200
TRIGGERTIME_FMT 2016-07-19 00:00:00
TYPE at
Readings:
2016-07-18 15:32:27 state Next: 00:00:00
Attributes:
disable 0
room schlafzimmer
Triggertime wird bei define gesetzt. Ich gehe davon aus, dass die Funktion rollladen_down_time beim ersten mal 00:00 zurueckliefert. Vermutlich weil die notwendigen Daten (Reading/Attribut/Value) noch nicht aus fhem.cfg eingelesen sind.
Hm ok. Kann man denn nachträglich das Berechnen der Triggerzeiten nochmal auslösen?
Durch ein at-modify, was per notify am global:INITIALIZED haengt.
Oder das at nach in fhem.cfg nach hinten schieben.
Du meinst die Initialisierung hinter die Dummies schieben? Oder wie weit muss man die Timer nach hinten schieben, damit das statefile schon gelesen ist? (Direkt hinter den Dummies reicht nicht)
Hast recht, an das statefile habe ich nicht gedacht, bleibt also das notify auf global:INITIALIZED. Alternative: Deine Funktion liefert statt 0 die aktuelle Uhrzeit + 1s zurueck, und setzt gleichzeitig das skip_next Attribut via $attr{az_rollladen_down}{skip_next} = 1;
Irgendwer hat hier im Forum mal verkündet, dass er keine direkten Zugriffe auf den hash %attr mehr haben möchte. Muss mal suchen, ob ich noch finde, wer das war ;)
Immer diese Kleingeister, die sich daran erinnern, was man gestern gesagt hat :)
Mit CommandAttr wird leider das rote Fragezeichen in FHEMWEB getriggert, was in diesem Fall nicht korrekt ist, da vom at sofort entfernt wird.
Ich probiere jetzt mal die Variante mit skipNext. Grundsätzlich hat das geklappt (auch wenn direkt im Anschluss alle Rollläden runter gefahren sind). Das skipNext zieht wohl noch nicht. Na ich such mal noch ein bisschen und berichte dann wieder.
Auf jeden Fall vielen Dank für die coole Idee :-)
Zitat von: rudolfkoenig am 18 Juli 2016, 22:56:44
Mit CommandAttr wird leider das rote Fragezeichen in FHEMWEB getriggert
Dagegen könnte man CommandAttr() bei Gelegenheit einen optionalen Parameter "silent" verpassen, wie z.B. bei fhem() schon länger vorhanden.
Zitat von: Matthias am 19 Juli 2016, 09:21:36
Na ich such mal noch ein bisschen und berichte dann wieder.
Packe die Definitionen in eine Funktion in der 99_myUtils und rufe die Funktion per notify auf global:INITIALIZED auf. Innerhalb dieser Funktion solltest Du die devices alle auf VOLATILE=1 setzen, damit sie bei einem save ignoriert werden.
ZitatDagegen könnte man CommandAttr() bei Gelegenheit einen optionalen Parameter "silent" verpassen, wie z.B. bei fhem() schon länger vorhanden.
Konsequenterweise muessten alle Command* Befehle, die ein structure change (und damit ein ?) ausloesen, diesen Argument bekommen. Da das etliche sind, bin ich erstmal zurueckgeschreckt: gibt es noch andere Stimmen, die so eine Aenderung befuerworten?
Noch ein letzter Update: Ich habe die Definition jetzt in die myUtils verfrachtet und löse die Funktion bei global:INITIALIZED aus - das funktioniert super. Nochmal vielen Dank für die Ideen und Vorschläge!
Matthias