ephem 3.7.6.0 in DEV vom 10.08.2016 bringt Fehler

[Msinn]

Reicht es dann nicht in lib.orb mit jeweils einem Lock für sun und einem Lock für moon die ephem Aufrufe zu versehen?

Oder sind im orb noch weitere Probleme vergraben?

[awknx]

Ich habe das eigentlich bei mir eh schon aufgesplittet (astronomy.py, env_astro.py und env_astro_pos.py), weil die ganzen Daten eigentlich nur ein Mal am Tag berechnet werden müssen. Nur die aktuellen Positionswerte müsste man öfter ermitteln, wenn man den Stand/Lauf der Sonne mitverfolgen will. Die orb.py habe ich dabei durch meine astronomy.py ersetzt gehabt.

Ich hänge grad aber an der Installation (siehe heutiger Thread) meines Beaglebone, weil ich festgestellt habe, dass es keinen Sinn macht auf meinem alten Stand nun diese Ergänzungen/Korrekturen vorzunehmen und erst mal die aktuelle Version brauche.

Update: Mein System läuft nun wieder und das auf dem aktuellen Stand. Werde dann die kommenden tage meine astronomischen Berechnungen von damals bei mir wieder einbauen und mich dann um das Thema Locks kümmern.

[awknx]

So, ich habe jetzt als ersten Schritt bei mir mal alles neu aufgesetzt (Beaglebone, SmarthomeNG 1.4.2, SmartVISU 2.9) und meine Dateien an das .yaml Format angepasst (liegt auf github bereit - siehe weiter oben) und wieder in mein SmarthomeNG integriert, so wie in meiner Install.txt beschrieben, damit wir vom aktuellen Stand ausgehen können.

Das Thema Threadsicherheit habe ich verstanden und schau ich mir als Nächstes an. Insgesamt wäre es aber wichtig, mal abzuklären, wie der ganze Rechenablauf eigentlich sinnvoll integriert werden soll.

Jetziger Stand ist ja, dass es die orb.py gibt (die ich durch meine astronomy.py ersetzen würde). Dies ist ja die zugrundeliegende Klasse, in der mit Hilfe von ephem die ganzen Berechnungen ausgeführt werden.

Mein Vorgehen war jetzt analag zur bisherigen Vorgehensweise Folgendes:
- Wenn eine Berechnung ausgeführt werden soll, wird durch die Klassenfunktion constellation() eine Berechnung gestartet (dabei kann dem Funktionsaufruf über mehrere Parameter Umfang, Art, Zeitpunkt usw. mitgegeben werden). Das Ergebnis ist dann ein Dictionary, dass alle berechneten Wert enthält (ein Aufruf reicht also aus, um gleich alle Daten zu bekommen).
- Um die bisherige Vorgehensweise für die env items beizubehalten, habe ich den Funktionsaufruf selbst in zwei "Verarbeitungsskripte" gelegt. Einmal die env_astro.py (die eigentlich nur ein Mal am Tag alle relevanten Werte holen müsste und in die entsprechenden items der env_astro.yaml schaufelt (daher gibt es bei mir auch die Werte previous und next, damit ich egal zu welcher Uhrzeit immer eindeutig zuordnen kann, ob Auf- und Untergänge für gestern, heute oder morgen gelten - das ist in der bisherigen Version nämlich ziemlich zweideutig). Das zweite Skript env_astro_pos.py ruft zwar ebenfalls wieder die (einzige) Klassenfunktion auf, liefert aber nur die aktuellen Positionsdaten (für den gewünschten Planeten) zurück. Wer also (laufend) wissen will, wo z.B. die Sonne gerade steht, muss dieses Skript dann regelmäßig starten, um z.B. das Wandern der Sonne im Tagesverlauf tracken zu können.
- Den Aufruf dieser beiden Skripte habe ich dabei der Einfachheit halber auch erst mal in der logic.yaml untergebracht, in der ja bisher auch die location.py getriggert wird, die die bisherigen Berechnungen macht.

Das Ganze schaut daher ein bischen umständlich aus, aber es ging mir damals ja erst mal drum, parallel zum laufenden System meines gleichzeitig betreiben und gegentesten zu können.

Die grundsätzliche Frage wäre nun, ob man das Ganze im Core lässt (env Items) oder generell ausgliedert als Logik oder Plugin oder... Dann könnte man die Item evals entsprechend überarbeiten.

[awknx]

Und hier noch zwei Bildchen dazu:



Astronomie_neu.png

[bmx]

Ok, schau Dir noch mal die aktuelle Develop Version an: Zum einen ist das die Basis für das nächste Release 1.5 ca. im Juni und zum anderen ist die Logik mit Sonnenpositionsberechnung bereits vom Rest abgesondert. Es wäre IMHO sinnvoll die Systemitems beizubehalten bzw. um Deine Items zu ergänzen.

[awknx]

Jetzt habe ich wohl wieder einen Wurm in meiner Installation. Mangels Platz (wollte zum schon laufenden NG parallel in einem zweiten Ordner den Develop branch installieren) musste ich es mit "git branch checkout develop" im vorhandenen wechseln. Nur startet NG nun nicht mehr - bekomme aber auch keine Fehlermeldung.

Was mache ich da nun am Besten?

[psilo]

awknx irgendwas muss das log ja sagen. was sagt es denn? notfalls löschen und neu auschecken?

[bmx]

Hm. SmarthomeNG im Debug-Modus starten (python3 bin/smarthome.py -d) und es sagt nix?

[awknx]

Wollte es eh im Debug starten. Nach einer kurzenDenkpause stehe ich auf der Shell wieder an der Eingabe.

Im Logfile finde ich was - leider ausgerechnet zu meiner neuen Klasse:

2018-05-17 17:04:33 WARNING __main__ -------------------- Init SmartHomeNG 1.4d.e27c1a4.develop --------------------
2018-05-17 17:04:33 ERROR __main__ Unhandled exception: 'SmartHome' object has no attribute '_tzinfo'
<class 'AttributeError'>
File "/usr/local/smarthome/bin/smarthome.py", line 1155, in <module>
sh = SmartHome(extern_conf_dir=extern_conf_dir)
File "/usr/local/smarthome/bin/smarthome.py", line 318, in __init__
self.astro = lib.astronomy.Astronomy(self._tzinfo, self._lat, self._lon, self._elev)


Wurde da mit _tzinfo etwas verändert?

[awknx]

Aber auch, wenn ich mein Modul auskommentiere, sehe ich im Debug nicht mehr viel:

Konsole:
smarthome@ibbgateway:/usr/local/smarthome$ /usr/local/smarthome/bin/smarthome.py --d
sh.start()
[17/May/2018:17:13:00] ENGINE Bus STARTING
[17/May/2018:17:13:00] ENGINE Serving on http://192.168.2.75:8384
[17/May/2018:17:13:00] ENGINE Serving on http://192.168.2.75:8383
[17/May/2018:17:13:00] ENGINE Bus STARTED

Im Log steht nur:
2018-05-17 17:12:56 WARNING __main__ -------------------- Init SmartHomeNG 1.4d.e27c1a4.develop --------------------

[bmx]

Schau mal in den Hauptcode im Developbranch:

def tzinfo(self):
    """
    Returns the info about the actual local timezone
    DEPRECATED - Use the Shtime-API instead
    :return: Timezone info
    :rtype: str
    """

    self._deprecated_warning('Shtime-API')
    return self.shtime.tzinfo()

[bmx]

Um zu entwickeln würde ich mir an Deiner Stelle allerdings eher ein Linux in einer VM installieren statt am offenen Herzen Deines Beagles zu schneiden ...

[awknx]

Wo du recht hast, hast du recht. Wird wohl doch etwas aufwändiger, bis ich mein Zeug angepasst hab. Nachdem ich jetzt dann auch erst mal im Urlaub bin, werde ich da bis zum Release im Juni vermutlich nicht liefern können. Werd aber mal schauen, ob ich am WE noch was zu Wege bringe.

Gibts irgendwo eine fertige VM, die ich direkt verwenden könnte?

[bmx]

Nein, aber nach Komplettanleitung geht das recht fix wenn Du das Linux erstmal als Images hast.

[awknx]

Ich setze gerade eine VM mit dem aktuellen Debian auf. Ganz so einfach läuft das aber dann doch nicht. So einer frischen Installation fehlt im Grunde alles Mögliche (z.B. schon mal git). Vielleicht wäre das für die Zukunft auch noch mal eine Idee, zum Testen eine fertige VM anzubieten, die für SmarthomeNG und smartVISU schon fertig konfiguriert ist (ähnlich einem Image für Raspi usw.).

Beim Vorgehen nach der Installationsanleitung (Developer) passiert dann noch Folgendes:

smarthome@VM-Debian:/usr/local/smarthome$ git checkout develop
warning: unable to rmdir plugins: Das Verzeichnis ist nicht leer
Branch develop konfiguriert zum Folgen von Remote-Branch develop von origin.
Zu neuem Branch 'develop' gewechselt


Und dann beim pip:

cherrypy 15.0.0 has requirement six>=1.11.0, but you'll have six 1.10.0 which is incompatible.
cheroot 6.3.0 has requirement six>=1.11.0, but you'll have six 1.10.0 which is incompatible.


Und wenn ich nun SmarthomeNG starte, bekomme ich ein paar Fehler:

2018-05-18 17:19:10 INFO Main Loading module 'http': args = '{'starturl': "'backend'", 'module_name': "'http'"}'
2018-05-18 17:19:10 CRITICAL Main Module 'http' (modules.http) exception during import of __init__.py: cannot import name 'unquote_to_bytes'

...

2018-05-18 17:19:10 INFO Main Load plugins
2018-05-18 17:19:10 DEBUG Main Plugins, section: BackendServer
2018-05-18 17:19:10 INFO Main Loading '/usr/local/smarthome/plugins/backendserver/plugin.yaml' to 'OrderedDict'
2018-05-18 17:19:10 WARNING Main YAML-file not found: /usr/local/smarthome/plugins/backendserver/plugin.yaml
2018-05-18 17:19:10 DEBUG Main PluginWrapper __init__: Section BackendServer, classname BackendServer, classpath plugins.backend
2018-05-18 17:19:10 ERROR Main Plugin 'BackendServer' exception during import of __init__.py: cannot import name 'unquote_to_bytes'
Traceback (most recent call last):
File "/usr/local/smarthome/lib/plugin.py", line 498, in __init__
exec("import {0}".format(classpath))
File "<string>", line 1, in <module>
File "/usr/local/smarthome/plugins/backend/__init__.py", line 34, in <module>
from .BackendSysteminfo import BackendSysteminfo
File "/usr/local/smarthome/plugins/backend/BackendSysteminfo.py", line 25, in <module>
import cherrypy
File "/usr/local/lib/python3.5/dist-packages/cherrypy/__init__.py", line 73, in <module>
from ._cptools import default_toolbox as tools, Tool
File "/usr/local/lib/python3.5/dist-packages/cherrypy/_cptools.py", line 33, in <module>
from cherrypy.lib import auth_basic, auth_digest
File "/usr/local/lib/python3.5/dist-packages/cherrypy/lib/auth_digest.py", line 26, in <module>
from six.moves.urllib.parse import unquote_to_bytes
ImportError: cannot import name 'unquote_to_bytes'