"at" wird nicht ausgeführt

[JWRu]

Ich habe zwei at definiert, um meine Gartenbeleuchtung zeitgesteuert an und aus zu schalten. "Gartenbeleuchtung" ist eine structure. "set Gartenbeleuchtung on" bzw. "off" in der Kommandozeile funktioniert einwandfrei.

Code Auswählen Erweitern

Internals:
   COMMAND    set Gartenbeleuchtung on
   DEF        *{sunset(-1200,"16:00","22:30")} set Gartenbeleuchtung on
   NAME       Gartenbeleuchtung_an
   NR         34
   NTM        18:14:49
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 18:14:49
   TIMESPEC   {sunset(-1200,"16:00","22:30")}
   TRIGGERTIME 1488129289
   TRIGGERTIME_FMT 2017-02-26 18:14:49
   TYPE       at
   Readings:
     2017-02-25 18:13:27   state           Next: 18:14:49
Attributes:
   room       Garten

Code Auswählen Erweitern

Internals:
   COMMAND    set Gartenbeleuchtung off
   DEF        *23:00 set Gartenbeleuchtung off
   NAME       Gartenbeleuchtung_aus
   NR         35
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 23:00:00
   TIMESPEC   23:00
   TRIGGERTIME 1488146400
   TRIGGERTIME_FMT 2017-02-26 23:00:00
   TYPE       at
   Readings:
     2017-02-26 00:08:35   state           Next: 23:00:00
Attributes:
   room       Garten

Nach der Definition und wenn ich irgendwas an der Konfiguration ändere, werden sie zur richtigen Zeit ausgeführt. Am folgenden Tag passiert aber nichts mehr, es gibt auch keinen Eintrag im log.
Auch mit execNow werden die ats einwandfrei ausgeführt. 

[Thorsten Pferdekaemper]

Hi,
so ganz sicher bin ich mir nicht, aber ich habe da so eine Vermutung:
Wenn Du das Gartenbeleuchtung_an definierst oder änderst, dann wird als nächste Schaltzeit "Nächster Sonnenuntergang minus 20 Minuten" eingestellt. Wenn jetzt das at triggert, dann wird wieder "Nächster Sonnenuntergang minus 20 Minuten" eingestellt. Dummerweise ist der nächste Sonnenuntergang zu dem Zeitpunkt noch derselbe... Möglicherweise triggert das in derselben Sekunde noch ein paarmal, aber dann ist Schluss, da die Triggerzeit dann in der Vergangenheit liegt.
Wahrscheinlich würde das hier funktionieren:

Code Auswählen Erweitern


*{sunset_abs_dat(time()+3600, -1200,"16:00","22:30")} set Gartenbeleuchtung on

Gruß,
   Thorsten

[JWRu]

Danke für die schnelle Antwort. In TRIGGERTIME_FMT steht aber jeweils der nächste Tag. Das at mit "*23:00" funktioniert übrigens auch nur einmal.

[throbin]

Nur eine Idee... Mit sunset("0",,,) funktioniert das? Hast Du die "attr global longitude" und "attr global latitude" gesetzt? Wenn dein System auf dem Pi bspw. läuft, muss NTP korrekt initialisiert sein.

[JWRu]

RasPi Systemzeit stimmt, Länge und Breite stimmen (die Schaltzeit wird ja auch richtig angezeigt). Mich irritiert am meisten, dass das at mit "*23:00" auch nicht regelmäßig ausgeführt wird.

[throbin]

Hast Du nach der Definition der Timer den Pi neu gestartet? Evtl. könntest Du den verbose unter global auf 5 setzen und dann ins Log schauen...

[JWRu]

Das erste habe ich jetzt mal gemacht - mal schauen, was heute Abend passiert.

[throbin]

Kannst den Timer auch früher konfigurieren, zum Testen

[JWRu]

Das hilft mit nicht weiter. Wenn ich was ändere, funktioniert es ja einmal - nur am nächsten Tag dann nicht mehr.

[Thorsten Pferdekaemper]

Hi,
ich bin mir nicht sicher, ob das in dem Fall einen Unterschied macht, aber schreibst Du das define direkt in die fhem.cfg oder machst Du das "ordentlich" im Kommandofeld in FHEMWEB?
Gruß,
   Thorsten

[betateilchen]

Das Problem scheint ein ganz anderes zu sein.

Ich habe seit kurzem ein ähnliches Problem, nämlich dass ein regelmäßiges at irgendwann einfach "hängenbleibt" und nicht weiter ausgeführt wird. Bei mir ziemlich fatal, da ich damit eine heartbeat Datei aktualisiere, die von watchdog überwacht wird. Irgendwann fällt dann mein FHEM in eine reboot-Schleife alle 10 Minuten.

Wenn ich das DEF anklicke und wieder abspeichere, ist alles gut und das at läuft wieder.

[Thorsten Pferdekaemper]

...sollte das hier dann nicht mal in den richtigen Forenbereich verschoben werden?
Gruß,
   Thorsten

[CoolTux]

Ich denke mal das hat was mit der Syntax Prüfung zu tun. Die wurde laut SVN vor kurzen hinzugefügt und wird wohl bei jeder Definition gestartet. Auch beim Neuanlegen der neuen Startzeit wenn die aktuelle abgelaufen ist.

[betateilchen]

Ich habe im richtigen Forumbereich bereits einen Thread eröffnet und Rudi hat auch schon geantwortet.

https://forum.fhem.de/index.php/topic,67995.0.html

Auch beim Neuanlegen der neuen Startzeit wenn die aktuelle abgelaufen ist.

Das Verhalten wurde gestern oder vorgestern bereits wieder geändert.

[CoolTux]

Wow das ging ja fix. Und das zur Karnevalszeit.