ephem 3.7.6.0 in DEV vom 10.08.2016 bringt Fehler

[schloessl]

Vor 3 Tagen gings noch, jetzt neue DEV.
Habe ich etwas übersehen ?
ephem 3.7.6.0

2016-08-14 16:12:08 ERROR sonnenstand Logic: sonnenstand, File: /usr/local/lib/python3.4/dist-packages/ephem-3.7.6.0-py3.4-linux-armv7l.egg/ephem/__init__.py, Line: 418, Method: visit_antitransit, Exception: 'Sun' is still above the horizon at 2016/8/15 23:18:00
Traceback (most recent call last):
File "/usr/local/smarthome/lib/scheduler.py", line 354, in _task
exec(obj.bytecode)
File "/usr/local/smarthome/logics/sonnenstand.py", line 18, in <module>
sunrise = sh.sun.rise().hour * 60 + sh.sun.rise().minute
File "/usr/local/smarthome/lib/orb.py", line 67, in rise
next_rising = self._obs.next_rising(self._orb).datetime()
File "/usr/local/lib/python3.4/dist-packages/ephem-3.7.6.0-py3.4-linux-armv7l.egg/ephem/__init__.py", line 493, in next_rising
return self._riset_helper(body, start, use_center, True, False)
File "/usr/local/lib/python3.4/dist-packages/ephem-3.7.6.0-py3.4-linux-armv7l.egg/ephem/__init__.py", line 468, in _riset_helper
d0 = visit_antitransit()
File "/usr/local/lib/python3.4/dist-packages/ephem-3.7.6.0-py3.4-linux-armv7l.egg/ephem/__init__.py", line 418, in visit_antitransit
% (body.name, d))
ephem.AlwaysUpError: 'Sun' is still above the horizon at 2016/8/15 23:18:00
2016-08-14 16:12:08 INFO env_loc Item env.location.sunrise = 2016-08-15 06:07:04.159334+02:00 via Logic None None

[Msinn]

Der Fehler kommt bei mir auch ab und zu ... und das schon lange. Hat. erstmal nichts mit dem aktuellen dev zu tun. Du kannst es haben, dass Du mit ephem kurz hintereinander dieselbe Berechnung ausführst und einmal den Fehler bekommst umd einmal nicht.

Such mal im Forum nach ephem. Da solltest Du mehrere Threads dazu finden.

[bmx]

Immer oder nur dieses eine mal?

[schloessl]

Danke erst einmal!
Ich warte dann einmal den Sonnenaufgang ab.
LG
Wolfgang

[Onkelandy]

Also ich kann Msinns Aussage bestätigen. Bei mir tritt der Fehler seit 3 Jahren immer wieder mal sporadisch auf - egal mit welcher Version von ephem und Smarthome (ich habe eigtl. immer die aktuellsten Versionen am Laufen).

[bmx]

Es ist vermutlich das gleiche Symptom wie beim UZSU Plugin. Dort habe ich einen Fix eingebaut, der das Sonnenobjekt erneut auf der Basis der Position erstellt. Das Problem liegt anscheinend darin, das ein Sonnenobjekt gleichzeitig von mehreren Threads benutzt wird.
Könnte man also vermutlich dauerhaft fixen.

[schloessl]

Ja der Fehler trat nur einmal beim Neustart (nach Sonnenuntergang??) auf. Seitdem keine neuer Ephem Fehler.
Danke für die Hinweise
Wolfggang

[Onkelandy]

Hi zusammen! Gibt's hier schon eine dauerhafte Lösung? Bei einem meiner 2 Smarthome Instanzen bekomme ich den Fehler im 3-4 Stundentakt Und das, obwohl praktisch keine Logiken oder Items vorhanden sind und genau das gleiche System läuft wie bei einem anderen Raspi, wo der Fehler praktisch nie auftritt..

bmx könntest du den Fix-Code vielleicht mal kurz hier posten? Wo müsste der denn rein? Bzw. am besten gleich mit in die dev Version einbasteln Dankeschön!!

[awknx]

Ich habe da ja auch immer wieder Fehler und bin nun dabei, mir das Ganze mal wirklich genau anzuschauen. Das Erste, was mir heute schon aufgefallen ist, ist das Folgende:

/ sr/local/smarthome/lib/orb.py

[COLOR=#008000]#logger = logging.getLogger(__name__)[/COLOR]

    def __init__(self, orb, lon, lat, elev[COLOR=#FF0000]=False[/COLOR]):
[COLOR=#008000]       self.logger = logging.getLogger(__name__)[/COLOR]
        # Objekt Observer bezieht Berechnung auf die aktuelle Position des Beobachters
        # Positionsangabe als Grad in Dezimalschreibweise (N+, S-, E+, W-)
        # Attribute lon (0), lat (0), elevation (0), date (now()), temp (25°C), pressure (1010mBar)
        if ephem is None:
            logger.warning("Could not find/use ephem!")
            return
        self._obs = ephem.Observer()
        self._obs.[COLOR=#FF0000]long [/COLOR]= str(lon)
        self._obs.lat = str(lat)
        if elev:
            self._obs.elevation = int(elev)
        if orb == 'sun':
            self._orb = ephem.Sun()
        elif orb == 'moon':
            self._orb = ephem.Moon()
            self.phase = self._phase
            self.light = self._light
        # Debug
[COLOR=#008000]        self.logger.debug("     Beobachter Datum UTC" + str(self._obs.date))
        self.logger.debug("     Beobachter Breitengrad " + str(self._obs.lat))
        self.logger.debug("     Beobachter Längengrad " + str(self._obs.lon))
        self.logger.debug("     Beobachter Höhe " + str(self._obs.elevation))
        self.logger.debug("     Planet " + str(self._orb.name))
        self.logger.debug("     Planet " + str(self._orb.name) + " letzter Transit UTC " + str(self._obs.previous_transit(self._orb)))
        self.logger.debug("     Planet " + str(self._orb.name) + " nächster Transit UTC " + str(self._obs.next_transit(self._orb)))
        self.logger.debug("     Planet " + str(self._orb.name) + " letzter Aufgang UTC " + str(self._obs.previous_rising(self._orb)))
        self.logger.debug("     Planet " + str(self._orb.name) + " nächster Aufgang UTC " + str(self._obs.next_rising(self._orb)))
        self.logger.debug("     Planet " + str(self._orb.name) + " letzter Untergang UTC " + str(self._obs.previous_setting(self._orb)))
        self.logger.debug("     Planet " + str(self._orb.name) + " nächster Untergang UTC " + str(self._obs.next_setting(self._orb)))[/COLOR]


    def rise(self, doff=0, moff=0, center=True, dt=None):
        # workaround if rise is 0.001 seconds in the past
        if dt is not None:
            self._obs.date = dt - dt.utcoffset()
        else:
            self._obs.date = datetime.datetime.utcnow() - dateutil.relativedelta.relativedelta(minutes=moff) + dateutil.relativedelta.relativedelta(seconds=2)
        self._obs.horizon = str(doff)
        if doff != 0:
            next_rising = self._obs.next_rising(self._orb, use_center=center).datetime()
        else:
            next_rising = self._obs.next_rising(self._orb).datetime()
        next_rising = next_rising + dateutil.relativedelta.relativedelta(minutes=moff)
        # Debug
[COLOR=#008000]        self.logger.debug("     " + str(self._orb.name) + " Offset in Grad " + str(doff))
        self.logger.debug("     " + str(self._orb.name) + " Offset in Minuten " + str(moff))
        self.logger.debug("     " + str(self._orb.name) + " Planetenmitte/Oberkante " + str(center))
        self.logger.debug("     " + str(self._orb.name) + " Datetimeobjekt " + str(dt))
        self.logger.debug("     " + str(self._orb.name) + " Initdatum " + str(self._obs.date))
        self.logger.debug("     " + str(self._orb.name) + " Sonnenaufgang " + str(next_rising))[/COLOR]


        return next_rising.replace(tzinfo=tzutc())

Die drei Kommentare sind von mir. Laut Quick Reference heisst das Attribut eigentlich "lon" und nicht wie hier verwendet "long". Oder übersehe ich da was (bin php geübt aber neu in python)?

Ebenso bin ich mir nicht sicher, was der Funktionsparameter "elev=False" bewirkt. Der Defaultwert für die elevation ist 0, waäre es da nicht sauberer "elev=0" zu schreiben, auch wenn die Wirkung ähnlich ist. Eigentlich sollte wie bei lon und lat aber keine Vorbelegung notwendig sein, oder?

Grundsätzlich bin ich mittlerweile der Meinung, dass die berechneten Daten sich immer auf das gleiche Datum beziehen sollten und nicht wie in Smarthome.py umgesetzt immer die nächsten Daten berechnet werden (also z.B. der Sonnenaufgang vom folgenden Tag, wenn die Sonne am heutigen Tag schon aufgegangen ist). Ich kenne das auch aus der Seefahrt und anderen Veröffentlichungen und Darstellungen nicht anders und ich finde, dass in einer Übersicht immer die tagesaktuellen Daten angezeigt werden sollten. Dahingehend sollten die ganzen Berechnungen/Skripte umgestellt werden (im dümmsten Fall mache ich es selbst - auch wegen der Zustandsgenerierung Tag/Nacht usw. - kann aber dauern).

Viele Grüße
Andi

[psilo]

awknx
das mit der "vorberechnung" für den nächsten tag hat mich auch immer gewurmt, frage ist, ob das gründe hat. ansich würde ja um 24:00 der wechsel reichen.

das mit lon vs long hängt ggf von der ephem version ab. müsste ich mir auch tiefer ansehen.

PS: hier wird bei ephem.Observer von long gesprochen: http://zeus.asu.cas.cz/extra/pyephem-manual.html

Dem Github nach zu gehen, ist es in 3.7.6.0 (bei mir drauf) aber wirklich lon: https://github.com/brandon-rhodes/py...em/__init__.py

[awknx]

Habe jetzt den Code oben nochmal angepasst. Im Debug wird der Längengrad korrekt ausgegeben (und gleich in Grad, Minuten, Sekunden umgerechnet), aber der __init__ wohl gleich zweimal hintereinander ausgeführt:

2016-10-04 18:13:53 WARNING smarthome Main -------------------- Init smarthomeNG 1.2.451 -------------------- -- smarthome.py:__init__:195
2016-10-04 18:13:53 DEBUG smarthome Main Python 3.4.2 -- smarthome.py:__init__:196
2016-10-04 18:13:53 DEBUG orb Main 11:30:25.9 -- orb.py:__init__:60
2016-10-04 18:13:53 DEBUG orb Main 48:10:30.0 -- orb.py:__init__:61
2016-10-04 18:13:53 DEBUG orb Main 530.0 -- orb.py:__init__:62
2016-10-04 18:13:53 DEBUG orb Main 11:30:25.9 -- orb.py:__init__:60
2016-10-04 18:13:53 DEBUG orb Main 48:10:30.0 -- orb.py:__init__:61
2016-10-04 18:13:53 DEBUG orb Main 530.0 -- orb.py:__init__:62
2016-10-04 18:13:53 INFO scheduler Main Init Scheduler -- scheduler.py:__init__:87
2016-10-04 18:13:53 DEBUG scheduler Scheduler creating 5 workers -- scheduler.py:run:94
2016-10-04 18:13:53 INFO smarthome Main Init Plugins -- smarthome.py:start:261

Edit: Zwei Mal deswegen, weil von smarthome.py zwei Mal aufgerufen, um die Objekte für Sonne und Mond zu erzeugen:

            self.sun = lib.orb.Orb('sun', self._lon, self._lat, self._elev)
            self.moon = lib.orb.Orb('moon', self._lon, self._lat, self._elev)

[Onkelandy]

Heißt das, wir sind das Problem bald los ?

[psilo]

Ich glaube nicht..

[awknx]

Die Hoffnung stirbt zuletzt. Ich hab nicht gerade viel Zeit dafür momentan, der Quellcode ist so gut wie gar nicht dokumentiert, über mehrere Dateien verteilt und ich bin php skriptprogrammieren gewöhnt, muss mich also erst mit python und objektorientiert anfreunden. Aber ich bleib dran, Astronomie interessiert mich und mir gehen ja immer noch weitere Zustände zu Tag/Nacht ab :-)

Ach so - und gebe es denn weitere Wünsche zur Astronomie?

[awknx]

Ein paar Dinge kann ich nun klären:

1. Ephem liefert nicht einfach den Sonnenaufgang oder Sonnenuntergang für ein Datum, sondern mehrere Daten in Bezug auf ein angegebenes Datum inkl. Uhrzeit:

2016-10-09 13:58:12 DEBUG orb Main Beobachter Datum UTC2016/10/9 11:58:12 -- orb.py:__init__:69
2016-10-09 13:58:12 DEBUG orb Main Beobachter Breitengrad 48:10:30.0 -- orb.py:__init__:70
2016-10-09 13:58:12 DEBUG orb Main Beobachter Längegrad 11:30:25.9 -- orb.py:__init__:71
2016-10-09 13:58:12 DEBUG orb Main Beobachter Höhe 530.0 -- orb.py:__init__:72

2016-10-09 13:58:12 DEBUG orb Main Planet Sun -- orb.py:__init__:73
2016-10-09 13:58:12 DEBUG orb Main Planet Sun letzter Transit UTC 2016/10/9 11:01:07 -- orb.py:__init__:74
2016-10-09 13:58:12 DEBUG orb Main Planet Sun nächster Transit UTC 2016/10/10 11:00:51 -- orb.py:__init__:75
2016-10-09 13:58:12 DEBUG orb Main Planet Sun letzter Aufgang UTC 2016/10/9 05:24:44 -- orb.py:__init__:76
2016-10-09 13:58:12 DEBUG orb Main Planet Sun nächster Aufgang UTC 2016/10/10 05:26:12 -- orb.py:__init__:77
2016-10-09 13:58:12 DEBUG orb Main Planet Sun letzter Untergang UTC 2016/10/8 16:38:41 -- orb.py:__init__:78
2016-10-09 13:58:12 DEBUG orb Main Planet Sun nächster Untergang UTC 2016/10/9 16:36:42 -- orb.py:__init__:79

Das bedeutet, man müsste sich für eine rein datumsbezogene Angabe im Skript entscheiden, ob man den letzten oder den nächsten Wert verwenden möchte, je nachdem, wann der Scheduler die Abfrage macht.


2. Die Funktionen rise und set arbeiten mit 4 Parametern (doff Offset in Grad, moff Offset in Minuten, center ???, dt Datetimeobjekt "2016-10-08 00:00:00+02:00")

2016-10-09 13:58:20 DEBUG orb env_loc Offset in Grad 0 -- orb.py:rise:98
2016-10-09 13:58:20 DEBUG orb env_loc Offset in Minuten 0 -- orb.py:rise:99
2016-10-09 13:58:20 DEBUG orb env_loc center True -- orb.py:rise:100
2016-10-09 13:58:20 DEBUG orb env_loc Datetimeobjekt None -- orb.py:rise:101
2016-10-09 13:58:20 DEBUG orb env_loc Datum 2016/10/9 11:58:23 -- orb.py:rise:102
2016-10-09 13:58:20 DEBUG orb env_loc Sonnenaufgang 2016-10-10 05:26:11.603797 -- orb.py:rise:103
2016-10-09 13:58:20 DEBUG location env_loc Env Sunrise 2016-10-10 07:26:11.603797+02:00 -- location.py:<module>:7
2016-10-09 13:58:20 INFO item env_loc Item env.location.sunrise = 2016-10-10 07:26:11.603797+02:00 via Logic None None -- item.py:__update:374

Irgendwo geistert im Internet noch ein Beispiel rum (finde ich aber nicht mehr), wo sinngemäß Folgendes drin steht:

sh.sun.rise(-6) um ein Offset in Grad anzugeben, hier also z.B. Sonne befindet sich noch 6° unterhalb dem Aufgehen

und

sh.sun.rise(180m) um ein Offset in Minuten anzugeben, hier also z.B. Sonne befindet sich noch 60min unterhalb dem Aufgehen

Zweiteres Beispiel kann so nicht funktionieren, wird aber auch keinen auf Anhieb sichtbaren Fehler anzeigen. Für eine Zeitangabe müsste man immer schreiben:

brightness = sh.sun.rise(0, 180).day != sh.sun.set(0, 180).day

damit ein Offset in Minuten überhaupt verarbeitet wird.

2016-10-09 13:58:21 DEBUG orb env_loc Offset in Grad 0 -- orb.py:rise:98
2016-10-09 13:58:21 DEBUG orb env_loc Offset in Minuten 180 -- orb.py:rise:99
2016-10-09 13:58:21 DEBUG orb env_loc center True -- orb.py:rise:100
2016-10-09 13:58:21 DEBUG orb env_loc Datetimeobjekt None -- orb.py:rise:101
2016-10-09 13:58:21 DEBUG orb env_loc Datum 2016/10/9 08:58:23 -- orb.py:rise:102
2016-10-09 13:58:21 DEBUG orb env_loc Sonnenaufgang 2016-10-10 08:26:11.603797 -- orb.py:rise:103
2016-10-09 13:58:21 DEBUG orb env_loc Datum 2016/10/9 08:58:23 -- orb.py:set:124
2016-10-09 13:58:21 DEBUG orb env_loc Sonnenuntergang 2016-10-09 19:36:41.918144 -- orb.py:set:125
2016-10-09 13:58:21 DEBUG location env_loc Env Brightness True -- location.py:<module>:50

3. Auffällig bei mir ist, dass die Berechnungen anscheinend wunderbar funktionieren (auch bei der Uzsu), solange sie nicht vom Scheduler aufgerufen werden:

2016-10-09 14:28:20 DEBUG orb Scheduler Datum 2016/10/9 12:27:23 -- orb.py:set:124
2016-10-09 14:28:20 DEBUG orb Scheduler Sonnenuntergang 2016-10-09 16:37:41.918145 -- orb.py:set:125
2016-10-09 14:28:20 DEBUG orb Scheduler Datum 2016/10/9 12:28:23 -- orb.py:set:124
2016-10-09 14:28:20 DEBUG orb Scheduler Sonnenuntergang 2016-10-09 17:13:48.538929 -- orb.py:set:125
2016-10-09 14:28:20 DEBUG orb Scheduler Offset in Grad -5.0 -- orb.py:rise:98
2016-10-09 14:28:20 DEBUG orb Scheduler Offset in Minuten 0 -- orb.py:rise:99
2016-10-09 14:28:20 DEBUG orb Scheduler center True -- orb.py:rise:100
2016-10-09 14:28:20 DEBUG orb Scheduler Datetimeobjekt None -- orb.py:rise:101
2016-10-09 14:28:20 DEBUG orb Scheduler Datum 2016/10/9 12:28:23 -- orb.py:rise:102
2016-10-09 14:28:20 DEBUG orb Scheduler Sonnenaufgang 2016-10-10 04:59:05.258961 -- orb.py:rise:103
2016-10-09 14:28:20 DEBUG orb Scheduler Offset in Grad 0 -- orb.py:rise:98
2016-10-09 14:28:20 DEBUG orb Scheduler Offset in Minuten 1 -- orb.py:rise:99
2016-10-09 14:28:20 DEBUG orb Scheduler center True -- orb.py:rise:100
2016-10-09 14:28:20 DEBUG orb Scheduler Datetimeobjekt None -- orb.py:rise:101
2016-10-09 14:28:20 DEBUG orb Scheduler Datum 2016/10/9 12:27:23 -- orb.py:rise:102
2016-10-09 14:28:20 DEBUG orb Scheduler Sonnenaufgang 2016-10-10 05:27:11.603797 -- orb.py:rise:103

Hier werden immer wieder Offsets übermittelt, bei denen mir noch nicht klar ist, wie die zustande kommen. Vielleicht liegt da das Problem begraben? Sobald ich wieder Zeit habe, schaue ich da weiter.

EDIT: Bin da jetzt weiter, die komischen Offsets sind wohl in einer \lib\env\logic_conf hinterlegt...

Viele Grüße
Andi