OpenKNX Logikmodul Probleme mit Sonnenaufgang

[dhb2002]

Wollte mein altes SAMD21 basiertes Logikmodul auf einen etwas neueren Stand bringen und habe dabei Probleme mit dem Sonnenaufgang festgestellt.

Momentan benutzte ich UP1-8xSensor und Firmware Release v1.0.0 . Timezone ist NZST-12NZDT,M10.1.0/2,M3.3.0/3 eingestellt.

2026-03-11 17:00:50: Sun:                     Used cordinates: -4X.XXXXXX 17X.XXXXXX
2026-03-11 17:00:50: Sun:                     Elevation: -15.077162, Azimuth: 110.150948
2026-03-11 17:00:50: Sun:                     Sun rise: 250::19 UTC
2026-03-11 17:00:50: Sun:                     Sun rise: 22::19 (ST)
2026-03-11 17:00:50: Sun:                     Sun set: 06::58 UTC
2026-03-11 17:00:50: Sun:                     Sun set: 19::58 (DST)
2026-03-11 17:06:23: logic sun
2026-03-11 17:06:23: Logic:                   Sunrise: 22:21 Sunset: 19:56
2026-03-11 17:06:44: tm
2026-03-11 17:06:44: Time:                    2026-03-11 17:06:44 (UTC)
2026-03-11 17:06:44: Time:                    2026-03-12 06:06:44 (DST)
2026-03-11 17:06:44: Time:                    Thursday
2026-03-11 17:06:44: Time:                    Today is a working day
2026-03-11 17:06:44: Time:                    Tomorrow is a working day
2026-03-11 17:06:44: Time:                    Timezone: NZST-12NZDT,M10.1.0/2,M3.3.0/3
2026-03-11 17:06:44: Time:                    Mode: calculate daylight saving time
2026-03-11 17:06:44: Time:                    Offset for daylight saving time: -3600s
2026-03-11 17:06:44: Time:                    Easter: 2026-03-05
2026-03-11 17:06:44: Time:                    4th advent: 2026-12-20
2026-03-11 17:06:44: Time:                    Timeprovider: KNX​

*(Coordinates redacted)

Sunset stimmt ja, aber Sunrise liegt mit 250:10 UTC / 22:19 ST daneben. Sollte 7:21 ST sein. Hat sich da ein Bug bezüglich Koordinaten in der Südhalbkugel, d.h. Breitengraden <0, eingeschlichen? mumpf, als wir damals am Astrocode gearbeitet hatten, lief es bei mir auf SAMD21 korrekt.

[mumpf]

Die Zeitberechnung mach ich nicht mehr selber, jemand im Team fühlte sich berufen, das alles auf beliebige Zeitzonen umzustellen - weil es dann ja für alle klappt .
Ich schau mir das mal an, was beim Logikmodul ankommt und ob ich was problematisches sehe, aber im Zweifelsfall muss ich das an den Kollegen mit den Zeitzonen weitergeben.
Kannst Du hier noch den Konfigurationsstring für Common posten? Dann haben wir garantiert die gleichen Einstellungen. Oder schick mir die per PN, wenn Dich die Geokoordinaten stören (wären dann ja public).

Gruß, Waldemar

[dhb2002]

Kannst Du hier noch den Konfigurationsstring für Common posten? Dann haben wir garantiert die gleichen Einstellungen.

Vielen Dank, PM wurde geschickt.

Naja, Zeitzonen, stimmt ja in UTC auch nicht. Sieht so aus, als ob sich da irgendwo ein +/- Fehler bei der Berechnung in Bezug auf negative Latitude eingestellt hat.

[dhb2002]

Hi mumpf, gibt es bezüglich des Bugs neue Infos? Würde gerne meine restlichen Sachen auf die neue Hardware bringen und die brauchen einen korrekten Sonnenauf- und Untergang.

[mumpf]

Sorry, ich kam noch nicht dazu.
Habe es mir heute Morgen angesehen und erstmal an die Entwickler der neuen Zeitbehandlung weitergegeben, ich komme da nicht weiter.
Schauen wir mal, was die sagen.

Gruß, Waldemar

[mgeramb]

Also die Zeitzone hat mal nichts mit dem Sonnenaufgang/Untergang zu tun. Die Zeitzone ist nur die Umrechung zwischen Local Time und UTC. Wenn also seine Local Zeit und UTC stimmt, dann geht die mal richtig.
Die Sonnenauf- und Untergangsberechnung erfolgt noch immer nach der originalen Berechnung vom Logikmodul mumpf .
Neu von mir dazu gekommen ist nur der Sonnenstand, also wo am Himmel sich die Sonne befindet, dieser wird derzeit soweit ich weiß nur in meiner Jalousien Beschattungssteuerung berechnet und ist komplett getrennt.
Insofern kann ich hier aktuell leider wenig helfen.

[coko]

Ich habe da nach erster Analyse inzwischen einen konkreteren Verdacht: Südhalbkugel ist wohl nicht das Problem, aber ein möglicher UTC-Tageswechsel zwischen Sonnenaufgang und Sonnenuntergang, damit eine negative Uhrzeit (Vortag) für den Sonnenaufgang, die bei Ablage in Struktueren mit uint8_t zu einem Überlauf führt (was sich im relativen "großen" Wert 250 zeigt). Das ist in der alten Implementierung in einem Zwischenschritt auch schon aufgetreten, wurde jedoch durch einen zweiten Überlauf mit der Offset-Berechnung kompensiert ohne sichtbar zu werden. Jetzt wird zwischendurch noch eine Zeit erzeugt, der Überlauf sorgt allerdings nicht für einen Fehler Modulo 24...

Fazit: Das wäre lösbar, sehe da aber noch Bedarf noch ein bisschen weiter drum herum zu schauen.
Ist nun auf jeden Fall auch schon mal dokumentiert: https://github.com/OpenKNX/OGM-Common/issues/136

[coko]

dhb2002 FYI: Ein Fix für die Problematik liegt inzwischen auf dem Tisch. Muss nun aber noch mal getestet werden; evtl. wird mumpf Dir in diesem Rahmen auch noch mal einen Test-Build zur Verfügung stelle.

[dhb2002]

dhb2002 FYI: Ein Fix für die Problematik liegt inzwischen auf dem Tisch. Muss nun aber noch mal getestet werden; evtl. wird mumpf Dir in diesem Rahmen auch noch mal einen Test-Build zur Verfügung stelle.

Vielen Dank erst mal. Kann gerne in den nächsten 2 Wochen mal testen. Danach bin ich erst mal für ein paar Monate nicht vor Ort.