Logik mit crontab sunset+35m wird nach einmaliger Ausführung erst Wochen später wieder eingeplant

[wi26]

Hallo,

ich habe seit ca 2 Wochen ein Problem mit einer Logik, die vorher ewig unauffällig lief.

• SmartHomeNG Version: 1.9.5
• Python: v3.12.10
• Betriebssystem: archlinux
• Standort/Koordinaten in smarthome.yaml korrekt gesetzt: ja

vi etc/logic.yaml

shutter_down_sunset:
    filename: rollladensteuerung.py
    crontab: sunset+35m = sunset
    nw: yes
    # ich denke 'nw' kann ich rausnehmen, es hat keine Funktion mehr

Nach einem restart des smarthomeNG Service wird die Logik aufgerufen. An den Folgetagen nicht mehr.

Es gibt weitere Logiken die bei sunset-59m und sunset-60m gestartet werden. Diese starten an jedem Abend problemlos.

das Problem hat ohne Konfigurationsänderung von smarthomeNG angefangen. Auch ein Neustart des Prozesses wurde nicht durchgeführt.

Der Debug aus lib.scheduler zeigt das Problem:

nach dem neustart:
2026-06-18 21:21:29 DEBUG lib.scheduler logics.shutter_down_sunset next time: 2026-06-18 22:07:52.114261+02:00

die logik beim ersten mal:
2026-06-18 22:07:52 DEBUG logics.shutter_down_sunset Getriggert durch: {'by': 'Scheduler', 'source': 'cron', 'source_details': 'sunset+35m', 'dest': None, 'value': 'sunset'}
2026-06-18 22:07:52 DEBUG lib.scheduler logics.shutter_down_sunset next time: 2026-07-14 21:58:51.139826+02:00

ich erwarte die Logik jeden Abend und nicht erst in 26 Tagen. Mir ist völlig unklar, warum es plötzlich nicht mehr funktioniert.

die KI hatte zum 14.7. einen Meinungsbeitrag:

[B]Warum ausgerechnet der 14. Juli?[/B]

Das ist der verräterische Punkt: Um den [B]21. Juni[/B] herum liegt die [B]Sommersonnenwende[/B], also der späteste/„höchste" Sonnenuntergang des Jahres. Der berechnete Wert von 21:58:51 am 14. Juli entspricht ziemlich genau dem Sonnenuntergangs-Zeitpunkt, der dem aktuellen wieder gleicht, nachdem die Tage über die Sonnenwende hinweg erst länger und dann wieder kürzer werden.

Das deutet stark darauf hin, dass der Scheduler bei der Neuberechnung nach dem Feuern [B]nicht einfach „nächster Tag"[/B] rechnet, sondern den [B]nächsten Zeitpunkt sucht, der echt in der Zukunft liegt und die Bedingung erfüllt[/B] – und dabei durch den +35m-Offset in einen Randfall läuft. Weil sich der Sonnenuntergang um die Sonnenwende kaum noch verändert (teils sogar minimal nach hinten), wird der für den Folgetag berechnete sunset+35m-Zeitpunkt fälschlich als „bereits vergangen/ungültig" verworfen, und der Algorithmus läuft so lange weiter, bis er einen passenden Tag findet – das ist erst der 14. Juli.

Ich habe im gitlab keine relevante Änderung zu lib.scheduler gefunden. Deshalb wollte ich erstmal nicht updaten. Der Fehler ist gerade gut reproduzierbar.

Kann jemand mit mehr lib.scheduler Wissen damit etwas anfangen?

[bmx]

Was genau soll denn die Zeile

crontab: sunset+35m = sunset

bewirken?

Im Normalfall würde der Scheduler der Logik zum Triggerzeitpunkt sunset+35m das sunset evaluieren oder als string "sunset" weiterreichen. Ich weiß nicht ob der Code darüber stolpert.

Aber um das nachzuvollziehen müsste man vermutlich auch Deinen genauen Standort haben.

[wi26]

ich habe eine Logik die die Rollladen steuert. Sie "weiss" was bei "sunset" zu tun ist. wichtig ist, dass die logik 35min nach sonnenuntergang gestartet wird.

cat etc/smarthome.yaml
%YAML 1.1
---

lat: 52.5206
lon: 13.4098
elev: 52

tz: 'Europe/Berlin' # timezone, the example will be fine for most parts of central Europe

default_language: de # default_language is used, where multiple languages are supported (de, if not specified)
​[..]

[wi26]

habe smarthomeNG um 20:54 neu gestartet. der scheduler scheint auf den 14.7. fixiert zu sein.

2026-06-19 20:54:35 DEBUG lib.scheduler logics.shutter_down_sunset next time: 2026-06-19 22:08:11.789676+02:00
2026-06-19 22:08:12 DEBUG logics.shutter_down_sunset Getriggert durch: {'by': 'Scheduler', 'source': 'cron', 'source_details': 'sunset+35m', 'dest': None, 'value': 'sunset'}
2026-06-19 22:08:12 DEBUG lib.scheduler logics.shutter_down_sunset next time: 2026-07-14 21:58:51.139826+02:00
​

[Msinn]

Vielleicht geht bei Dir die Sonne bis zum 14. Juli nicht mehr unter?

[bmx]

Also ich hatte mal versucht mit einer alten SHNG Umgebung das nachzustellen aber ich habe keine Zeit das alles wieder zum Laufen zu bekommen. Da wäre dann ein Docker sich die eleganteste Sache.
Ich habe nun mit Deiner Location (Funkturm Berlin?) das in SHNG v1.12.1 nachzustellen. Laut Wetter.com ist Sonnenuntergang um 21:32.
Der Scheduler gibt mir an:

​bar 2026-06-20 21:33:28+0200 3 sunset - {'sunset': 'sunset'}
foo 2026-06-20 22:08:28+0200 3 sunset - {'sunset+35m': 'sunset'}

Das sieht für mich plausibel aus.

[wvhn]

wi26,
ich habe einen vagen Verdacht und deshalb 2 Fragen:
was passiert denn, wenn Du aus den „35m“ mal „15m“ machst? Verändert sich der Fehler?
Hast Du in letzter Zeit irgend etwas an den Zeitzonen im System oder in shNG geändert, oder verarbeitet Deine Logik die Zeitzone?

Gruß
Wolfram

[tryandsucceed]

Moin,
ich hab seit ca 2 Wochen ein ähnliches Problem bei mir, allerdings mit den UZSU Funktionen - wenn per Expertenfunktionen "Sundown + 30" eingestellt ist, wird bei mir entsprechend der 12.7. eingestellt. Auch erkennbar in sämtlichen UZSU-bezogenen Schedulern.

Seltsam finde ich, dass es Jahrelang gut funktioniert hat. Müsste ja dann wirklich auf eine Änderung in diesem Jahr hinweisen.

Bin definitiv auch gespannt auch Neuigkeiten/Antworten. Muss derzeit alle Jalousien manuell runter fahren :/

[Sisamiwe]

Hey,

wird nicht die ephem lib als Grundlage der astonomischen Berechnungen genutzt?
Nutzt ihr alle die gleiche Version von ephem?

[wvhn]

In v4.4.1 wurde das Zeitzonenhandling in ephem geändert. Nach meinem Verständnis sollte die shNG-Versionen vor v1.9.5 eine frühere Version von ephem verwenden.
Ab shNG v1.11 wurde ephem >= 4.2, <5.0 vorgegeben und für
shNG v1.12 wurden die Berechnungen in lib.orb umgestellt, siehe hier.

Gruß
Wolfram

[Morg]

Ich habe mir das nochmal detailliert angesehen und es gibt sowohl klare Fehler als auch Stellen, an denen uneinheitliche Annahmen getroffen werden. Die Kernberechnungen von Sonnen- und Mondzeiten sind korrekt, aber das Übergeben von Zeiten leidet entweder daran, dass vorhandene Zeitzoneninfos ignoriert oder überschrieben werden, oder dass die Zeitzone des OS statt der in shng konfigurierten Zeitzone genutzt werden.

geprüft: lib.orb, lib.shtime, lib.triggertimes und plugins.uzsu.

Ich kann das durchgängig vereinheitlichen, und ich denke, das sollten wir auch tun - aber es muss klar sein, dass das eine oder andere Setup vom jeweiligen Nutzer erneut geprüft werden muss, und dass es in der Übergangszeit zu Inkonsistenzen kommen kann. Ich mach mal einen PR...

[bmx]

Wenn Du das Faß aufmachst würde ich vorschlagen das wir lib.orb in Rente schicken und statt dessen Skyfield verwenden. Da hat schon mal jemand was vorbereitet gehabt was prinzipiell gut funktioniert aber noch nicht integriert ist.

[tryandsucceed]

Nur FYI, ich hab gerade in meinem Setup nochmal verifiziert. Sobald ein +X Wert eingetragen wird, springt der Scheduler einige Tage voraus. Ohne Wert wird er korrekt auf sundown gesetzt.
Ephem ist bei mir in Version 4.2.2, shNG und Plugins jeweils v1.11.0-master, läuft im Docker unter python:3.10-trixie.
Pullrequest gern hier verlinken, würde/könnte ich dann Testen (denke ich).

Danke fürs auf den Zahn fühlen!

[Morg]

In 1.12 bekomme ich das nicht nachgestellt, es gab aber Änderungen an lib.shtime. Ich melde mich, sobald ich das fertig zusammengestellt habe.

[Morg]

Ich habe jetzt zwei PRs gemacht.

Der erste (801) fixed einige Probleme mit der Konvertierung von Zeitangaben zwischen lokaler und UTC-Zeit.

Der zweite PR (https://github.com/smarthomeNG/smarthome/pull/802) beinhaltet die Fixes von PR 801 und ermöglicht alternativ die Nutzung von skyfield statt ephem, was zum einen genauer und zum anderen ggf. einfacher zu installieren ist.

Da auch UZSU betroffen ist, gibt es dort auch einen PR - dieser benötigt zwingend PR 801 oder 802 im Core!

Testet gerne, ich nehme auch gern Feedback auf.