Supportthread für UZSU Plugin

[bmx]

Ich finde die Konvertierung von lokaler Zeit in UTC für ephem und anschliessend zurück sollte lieber innerhalb SHNG passieren und nicht einfach automatisch von ephem.
Hat denn das UZSU Plugin eine naive datetime ohne Zeitzoneninfo wenn es sunset oder sunrise abfragt?

[Onkelandy]

Ah, wenn da eh schon min. ephem 4.2 drin ist, ist ja prima. Dann müssen die -utcoffset() Sachen raus. Notfalls manuell, aber ich stell mal einen PR.

[bmx]

Also die Requirements im Master erfordern ephem >= 4.2 und ich würde auf keinen Fall auf eine ältere Version zurückgehen wollen, also anpassen des Codes würde ich bevorzugen.

[Morg]

Also entweder im Code ein Abfrage der pyephem-Version einbauen oder die Requirements anpassen...?

[Onkelandy]

Problem gefunden, siehe Changelog von pyephem: Version 4.1.1 (2021 November 27)

• When you provide PyEphem with a Python datetime that has a time zone attached, PyEphem now detects the time zone and converts the date and time to UTC automatically.

Demzufolge ist bei alten Versionen -utcoffset() korrekt, bei neuen nicht mehr. Da verschiebt es alles um 2 Stunden, daraus resultiert wohl auch der neu auftretende Fehler in der UZSU.

[wvhn]

Das klingt sehr plausibel. Allerdings ist an dieser Stelle seit v1.9.2 nichts mehr geändert worden. Weshalb tritt der Fehler dann mit shNG v1.9.5 und ephem v.3.7.7.1 nicht auf?

[Onkelandy]

Das sind sehr sonderbare Phänomene..
Ich hab mal versucht, die Berechnung vom Sonnenuntergang zu verfolgen, letztlich hängt es an dieser Zeile in orb.py in der "set" Methode:
observer.date = dt - dt.utcoffset() - dateutil.relativedelta.relativedelta(minutes=moff)

Aus meiner Sicht muss es so heißen
observer.date = dt - dateutil.relativedelta.relativedelta(minutes=moff)
Was das sonst alles für Folgen nach sich zieht, ist mir noch unklar, insofern wäre dieser Quickfix mit Vorsicht zu genießen.

Tatsache ist jedenfalls, dass durch diese Zeile der Sonnenuntergang des Vortags eruiert wird, weil observer.date nicht mehr Mitternacht, sondern 20:00 Uhr wird (Mitternacht UTC+2:00 wird zuerst auf 22:00 Uhr UTC gewandelt, dann werden noch 2 Stunden abgezogen). Und dann ist das Ergebnis immer jünger als der erste Threshold. Also 9.5. 22:30 Uhr ist früher als 10.5. 17:30 -> calculated Uhrzeit wird 17:30.

[wvhn]

Ein Downgrade von ephem auf Version 3.7.7.1 (gleich wie in meiner shNG v1.9.5 Installation) beseitigt das Problem. Ob auch neuere Versionen gehen, habe ich nicht getestet.

Sicher kann das nicht die Lösung sein, weil man sich andere Probleme mit dem Downgrade einhandeln kann. Aber jetzt wissen wir, wo wir suchen müssen.

Gruß
Wolfram

[wvhn]

Ja, ich denke auch. Siehe mein EDIT oben. Das hat sich mit Deiner Antwort überschnitten, weil ich die Sonnenstände noch mit einem Online-Tool nachgerechnet habe.

Gruß
Wolfram

[Sisamiwe]

Bei einem negativen Winkel-Wert wird die entsprechende Zeitspanne auf den sunset-Wert addiert. Nach meinem Verständnis müsste sie subtrahiert werden. Dieser Fehler ist möglicherweise schon alt.

Das ist aus meiner Sicht korrekt, denn es wird immer der Winkel in Relation zum Horizont angegeben. Sprich bei negativen Winkeln steht die Sonne unter dem Horizont und das ist später als sunset.
Oder?

Gruß
Michael

[wvhn]

ich habe das auf einem System mit shNG v1.9.5 getestet. Es scheinen 2 Fehler zu sein:

• Bei einem negativen Winkel-Wert wird die entsprechende Zeitspanne auf den sunset-Wert addiert. Nach meinem Verständnis müsste sie subtrahiert werden. Dieser Fehler ist möglicherweise schon alt.
• Wenn der obere Grenzwert bei der Umrechnung überschritten wird, begrenzt v1.9.5 den errechneten Wert korrekt (im Beispiel auf 22:00 Uhr). Hier muss sich in einer späteren Version ein zusätzlicher Fehler eingeschlichen haben, nämlich dass der falsche Grenzwert - im Beispiel der untere - herangezogen wird.

Gruß
Wolfram

EDIT:
Über das Vorzeichen kann man sich streiten. Wenn man dies rein nach dem Sonnenwinkel sieht, muss sunset-10" später als sunset sein. Also lassen wir das mal so, um keine breaking changes für die Anwender zu verursachen.

Der zweite Fehler hat nach weiteren Tests mit dem oberen Grenzwert nichts zu tun. Wenn ich den auf 23:00 Uhr erhöhe oder sogar ganz weglasse, zieht das das Plugin in v1.11 trotzdem den unteren Grenzwert. Lasse ich diesen auch weg, passiert folgendes:

• bei -9° und -10" rechnet das Plugin ziemlich lange und es kommt dann jeweils ein falscher Wert heraus (heute 21:58, wobei 22:05 und 22:13 Uhr richtig wären.
• -8° rechnet das Plugin deutlich kürzer und es kommt der Wert 21:56 Uhr heraus

Im Log finde ich noch nicht, ob das Plugin auf einen Fehler läuft. Das Verhalten legt das aber nahe.

[Sisamiwe]

Müsste eigentlich seit ewig bestehen.

Ich glaube nicht, da meine Einträge seit Jahren unverändert sind, das Problem aber erst in dieser Saison aufgetreten ist.

welche Lösung wir dazu finden

Lass mich wissen, wenn ich was tun kann.

Danke dir!

[Onkelandy]

Kann das Problem nachvollziehen. Müsste eigentlich seit ewig bestehen. Mal sehen, welche Lösung wir dazu finden. Melde mich demnächst wieder..

[Sisamiwe]

Ich bin mir nicht sicher ob Du meinst sunset-10° oder sunset-10m?

-10° ist eingestellt

Bei welchen Zahlen spinnt es? nur bei -10?

Das ist dynamisch bzw. verändert sich. Letzte Woche hatte ich -11° dann war die Berechnung falsch, dann habe ich auf -10° geändert, dann ging es seit gestern nicht mehr. Das Obergeschoß wird etwas früher gestartet mit -9°. Das funktioniert noch.
Ich denke, dass es mit dem jeweiligen Sonnenstand bzw. Sonnenuntergangszeitpunkt zu tun hat.

Gerade jetzt geht es mit -9°. Dann wäre 21.57 die berechnete Zeit. Ich kann also gut sein, dass 22.00 Uhr eine Grenze ist, dann alle Werte > -9° führen aktuell zur Berechnung von 17.30Uhr

seit wann existiert das Problem?

Das ist schwer zu sagen. Ich vermute aber mal das es mit dem letzten Update zu tun hat. Bislang war es unauffällig, lag vielleicht aber auch am Ergebnis der Berechnung.

[Onkelandy]

Ui, seit wann existiert das Problem? Bei welchen Zahlen spinnt es? nur bei -10? wie sieht es bei -20 aus?