Ankündigung

Einklappen
Keine Ankündigung bisher.

env.location.sunrise.*.degrees & env.location.sunset.*.degrees

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    env.location.sunrise.*.degrees & env.location.sunset.*.degrees

    Hallo zusammen,

    mit SmarthomeNG (konkret 1.9.2, Installation auf einem Raspberry Pi 3, Image von Onkelandy) bin ich auf ein Problem gestoßen:

    Längen- und Breitengrad sowie Höhe der Installation sind in smarthome.yaml korrekt gesetzt.
    Schaue ich mir die Zeiten des jeweils nächsten Sonnenaufgang und -untergang an (items env.location.sunrise[/CODE] und .sunset) oder auch die aktuelle Sonnenposition (env.location.sun_position.*.degrees) an, so stimmen die Werte hinreichend genau mit den Werten z.B. von https://www.sonnenverlauf.de/ überein.

    Lasse ich mir allerdings die Sonnenposition bei Sonnenaufgang und -untergang ausgeben, so weichen die Werte für Azimut und Elevation jeweils erheblich und völlig unrealistisch (aktuell: Azimut ca. +23° und Elevation ca. +17° bzw. -17°) ab.
    Aktuelles Beispiel:
    Ist-Position zum ungefähren Zeitpunkt des Sonnenaufgangs ist ca. H 74.1°, V 0°, die berechneten Position bei Sonnenaufgang ist aber H 97.8°, V 17.7°. Der Wert für Sonnenuntergang ist ebenfalls in Bewegungsrichtung deutlich falsch (V -17.3°).
    Screenshot_20220829-063702.pngScreenshot_20220828-083650.pngBildschirmfoto vom 2022-08-28 20-36-39.png

    Da die ausgegebenen Positionswerte für den Sonnenaufgang ziemlich genau mit den Werten 2h nach Sonnenaufgang übereinstimmen und meine Zeitzone aktuell (Sommerzeit in Deutschland) UTC+2h ist, würde ich drauf wetten, dass die Position nicht für den richtigen Zeitpunkt ausgewertet wird.

    In lib/env/location.py steht
    Code:
    …
    sunrise = sh.sun.rise().astimezone(shtime.tzinfo())
    sh.env.location.sunrise(sunrise, logic.lname)
    …
    azimuth_rise_degrees, elevation_rise_degrees = sh.sun.pos(dt=sunrise, degree=True)
    …
    wobei sunrise vom Typ datetime damit ja schon die Korrektur auf die lokale Zeitzone enthält!
    Muss der dt-Wert in sun.pos() denn an der Stelle vielleicht in UTC sein?

    Laut Doku unter https://smarthomeng.de/user/referenz/smarthomeng/methoden_sonne_mond.html?highlight=sunrise#sh-sun-pos ist der erste Parameter „offset“ und kein Zeitpunkt. Oder habe ich etwas überlesen?

    Wo ist denn sun bzw. sun.pos() genau definiert? Das habe ich nicht finden können.
    In pyephem (https://rhodesmill.org/pyephem/quick.html ) habe ich nur body.compute() gefunden, also müsste das ja irgendwo „übersetzt“ werden.

    Die Radian-Werte habe ich nicht geprüft. Ich gehe aber davon aus, dass die ebenfalls gehörig daneben liegen.

    Geht es anderen genauso oder ist das nur ein Problem bei meiner Installation?

    Danke für die Hilfe.


    PS:
    Warum das ganze überhaupt?
    Zur Vorbereitung einer Photovoltaik-Planung lese ich seit kurzem unseren Stromzähler mittels des SML-Plugin aus und würde gerne automatisiert auch noch die Zeiten und entsprechenden Winkel erfassen, wenn die betreffende Dachfläche theoretisch Sonne bekommt und so unsere Realverbrauchskurve mit einer theoretischen Erzeugungskurve vergleichen zu können. Dazu muss ich natürlich noch zwischen der Flächennormalen der Dachfläche und der jeweiligen Sonnenposition den Zentriwinkel (ephem.separation(m1,m2) ?) berechnen und prüfen, dass dieser kleiner 90° (eher 85°) ist und die Sonnenposition sich zwischen den Auf- und Untergangspositionen befindet. So der Plan.

    #2
    Ich denke Du hast da einen Bug gefunden. Unklar ist jetzt wie wir den fixen sollten.

    Die Berechnungen via pyephem findest Du in lib/orb.py

    sunrise = sh.sun.rise().astimezone(shtime.tzinfo())

    Das Umwandeln der von sun.rise() gelieferten UTC Zeit in die lokale Zeitzone bringt die Berechnung durch die Funktion durcheinander. Daher kommt da Murks raus.

    sunrise = sh.sun.rise()

    liefert plausiblere Ergebnisse.

    So könntest Du zunächst das in der evn.location.py ändern.

    Kommentar


      #3
      Besten Dank für die schnelle Hilfe.

      lib/orb.py schaue ich mir die Tage mal genauer an.

      Ich habe es jetzt gefixed, in dem ich die Umwandlung des jeweiligen UTC-datetime in die lokale Zeitzone einfach eine Zeile tiefer mit in die Zuweisung zum item verschoben habe:
      Code:
      ...
      #        sunrise = sh.sun.rise().astimezone(sh.tzinfo())
              sunrise = sh.sun.rise()
              #sh.env.location.sunrise(sunrise, logic.lname)
              sh.env.location.sunrise(sunrise.astimezone(shtime.tzinfo()), logic.lname)
      ...
      #        sunset = sh.sun.set().astimezone(sh.tzinfo())
              sunset = sh.sun.set()
              #sh.env.location.sunset(sunset, logic.lname)
              sh.env.location.sunset(sunset.astimezone(shtime.tzinfo()), logic.lname)
      ...
      Damit sind die Positionswerte auch wieder sinnvoll und die Zeiten in den items trotzdem richtig.
      Angehängte Dateien

      Kommentar

      Lädt...
      X