AT mit Next: 00:00:00

[Matthias]

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

[rudolfkoenig]

Bei mir steht in TRIGGERTIME/TRIGGERTIME_FMT Datum und Zeitpunkt der naechsten Ausfuehrung.
Falls ich etwas untersuchen soll, dann brauche ich mehr Details.

[Matthias]

Ok hier kommen mehr Details.

Die betroffenen at-Geräte greifen als TimeSpec auf eine FHEM Funktion zu:

Code Auswählen Erweitern

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]

Code Auswählen Erweitern

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]

Code Auswählen Erweitern

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

[rudolfkoenig]

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.

[Matthias]

Hm ok. Kann man denn nachträglich das Berechnen der Triggerzeiten nochmal auslösen?

[rudolfkoenig]

Durch ein at-modify, was per notify am global:INITIALIZED haengt.
Oder das at nach in fhem.cfg nach hinten schieben.

[Matthias]

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)

[rudolfkoenig]

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;

[betateilchen]

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 

[rudolfkoenig]

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.

[Matthias]

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

[betateilchen]

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.

[betateilchen]

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.

[rudolfkoenig]

Dagegen 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?

[Matthias]

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