ephem 3.7.6.0 in DEV vom 10.08.2016 bringt Fehler

[psilo]

awknx wir haben Docker Images dafür.. das ist m.E. die bessere Option als eine Full Blown VM...

[awknx]

Ich bin jetzt mal soweit, dass die VM läuft und ich auch eine Verbindung zur smartVISU habe. Den pip Fehler mit six konnte ich lösen über ein upgrade von six. Gestolpert bin ich dann noch über die plugin.yaml, weil die Einträge da drin wohl momentan je nach Plugin entweder mit plugin_name oder class_name angegeben werden müssen und da hatte ich nicht drauf geachtet.

Jetzt hänge ich aber noch beim Backend. Das erste Problem konnte ich beseitigen und die ebenfalls noch fehlenden Pakete cherrypy und jinja2 manuell nachinstallieren. Anscheinend haut das mit dem "pip3 install -r requirements/all.txt" zumindest bei mir nicht so hin.

Trotzdem bekomme ich mit dem Backend keine Verbindung hin. Auf der Konsole sehe ich:

2018-05-19 17:27:34 INFO CP Server Thread-9 ModuleApp: local.name '192.168.2.76', local.port '8383'
2018-05-19 17:27:34 INFO CP Server Thread-9 192.168.2.10 - - [19/May/2018:17:27:34] "GET / HTTP/1.1" 200 66 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0"
2018-05-19 17:27:34 ERROR CP Server Thread-9 [19/May/2018:17:27:34] HTTP
Traceback (most recent call last):
File "/usr/local/lib/python3.5/dist-packages/cherrypy/_cprequest.py", line 631, in respond
self._do_respond(path_info)
File "/usr/local/lib/python3.5/dist-packages/cherrypy/_cprequest.py", line 690, in _do_respond
response.body = self.handler()
File "/usr/local/lib/python3.5/dist-packages/cherrypy/lib/encoding.py", line 221, in __call__
self.body = self.oldhandler(*args, **kwargs)
File "/usr/local/lib/python3.5/dist-packages/cherrypy/_cpdispatch.py", line 60, in __call__
return self.callable(*self.args, **self.kwargs)
File "/usr/local/smarthome/plugins/backend/__init__.py", line 293, in index
return self.render_template('index.html')
File "/usr/local/smarthome/plugins/backend/__init__.py", line 275, in render_template
self.find_visu_plugin()
File "/usr/local/smarthome/plugins/backend/__init__.py", line 248, in find_visu_plugin
for p in self._sh._plugins:
AttributeError: 'SmartHome' object has no attribute '_plugins'
2018-05-19 17:27:34 INFO CP Server Thread-9 [19/May/2018:17:27:34] HTTP

Damit kann ich aber nix anfangen. Wäre schön, wenn ihr mir da nochmal auf die Sprünge helfen könntet.

[Msinn]

Zur Plugin.yaml: class_name und class_path müssen nur bei Plugins angegeben werdn, die keine Metadaten enthalten. Im Develop Branch sollten jedoch alle plugins Metadaten haben. Dann ist plugin_name hinreichend. Es kann jedoch auch für diese Plugins der alte Syntax mit class_name und class_path verwendet werden.

Der Fehler den Du schilderst deutet darauf hin, dass Du zwar den Core aus dem Develop Branch verwendest, jedoch Plugins (zumindest das backend) aus dem master branch. Nimm bitte auch die Plugins aus dem Develop Branch, wenn Du den Core aus dem Develop nimmst.

[awknx]

Das würde sich dann ja mit dem Fehler beim Branchwechsel decken, den ich hier schon beschrieben hatte:

https://knx-user-forum.de/forum/supp...38#post1232638

Ich wollte daher nun mit "sudo git clone -b develop --recursive git://github.com/smarthomeNG/smarthome.git" gleich nur den develop branch holen.

Da fehlt dann aber der komplette plugin Ordner. Soll das so sein?

[Msinn]

Ja, ab der nächsten Version (also für develop) musst Du das --recursive weglassen, in das leere plugins gehen und dort ein git clone auf das plugins repo machen.

Die beiden Repos sind jetzt (wieder) komplett getrennt. Das submodule Geraffel hat mehr Probleme gemacht als gelöst.

[awknx]

Okay.

Also mit "sudo git clone -b develop git://github.com/smarthomeNG/smarthome.git" hole ich es. Dort gibt es dann aber erst mal gar keinen Ordner plugins, nun also im Verzeichnis smarthome nochmal mit "sudo git clone -b develop git://github.com/smarthomeNG/plugins.git" die Plugins nachinstallieren.

War oben ein bischen missverständlich, da hatte ich dann den Ordner plugins in plugins. Das müsste möglichst auch in die englische Developer-Doku, an die hatte ich mich nämlich gehalten.

Und der smarthome.py fehlen am Ende immer noch die ausreichenden Rechte, ist das erst mal Absicht?

Aber es läuft jetzt und ich komme ins Backend. Jetzt muss ich mal sehen, wie weit ich es vorm Urlaub mit der Astronomie noch schaffe.

[Msinn]

An den Rechten tut git erstmal gar nichts die steuerst Du (z.B. dadurch dass Du sudo nutzt). Am besten ist es die Installation ohne Sudo durchzuführen.

In der Doku zum kommenden Release sieht der Teil der Installationsanleitung folgendermaßen aus:

cd /usr/local
sudo mkdir smarthome
sudo chown -R smarthome:smarthome /usr/local/smarthome

cd smarthome
git clone git://github.com/smarthomeNG/smarthome.git .  

mkdir plugins
cd plugins git clone git://github.com/smarthomeNG/plugins.git .

Bitte auf den Punkt am Ende der git clone Kommandos achten!

[awknx]

Bei mir hat git die Ordner selbst erzeugt. Das lag dann wohl an dem . am Ende. Mit Rechten meinte ich nicht den user smarthome. Nur der smarthome.py fehlen am Ende die Ausführrechte, sodass ich sie mit "/usr/local/smarthome/bin/smarthome.py --start" erst mal nicht starten kann und die Rechte auf 755 geändert habe.

[bmx]

Ich starte das immer aus dem Verzeichnis /usr/local/smarthome heraus mit python3 bin/smarthome.py

[awknx]

Meine Klasse (astronomy.py) ist jetzt angepasst, verwendet nun die shtime und ist mit einem Lock versehen. Ich habe das Ganze wieder bei git hochgeladen als develop branch.

Was jetzt noch offen ist, ist die Anpassung der Items und der zyklischen Aufrufe. Da geht mir jetzt vorm Urlaub grad die Zeit aus. Vor allem, weil mir nun aufgefallen ist, dass man die Daten/Items im Grunde in drei Teile zerlegen müsste:

1. Einmal täglich nach Mitternacht die komplette Berechnung aller Tagesdaten (vorausgesetzt man will sich auf Sonne und Mond beschränken, jeder andere Planet muss natürlich extra berechnet werden). Bisher ist das die location.py, bei mir die astro.py

2. Alle x Minuten die Berechnung der Positionsdaten Altitude und Azimut für den Planeten (in der Regel wohl nur für die Sonne interessant). Bisher/neu ist das die sunpos.py, bei mir die astro_pos.py

3. Alle x Minuten die Berechnung von Zuständen wie Tag, Nacht, Dämmerungen. Dazu braucht es aber eigentlich nur den Vergleich der aktuellen Uhrzeit mit den schon unter Punkt 1 ermittelten Zeiten für Aufgang, Untergang usw.. Das wird dann eine dritte Datei, die einfach nur Zeitvergleiche macht.

Den dritten Teil hatte ich so nämlich nicht auf dem Schirm, weil das bisher auch nur durch sich ewig wiederholende Ephem-Aufrufe gelöst war, aber nicht notwendig wäre.

Insgesamt hätte man damit dann auch das Thema vom Hals, ob z.B. der Sonnenaufgang der von gestern, heute oder morgen ist, das war ja bisher immer davon abhängig wann die Berechnung erfolgt.

[awknx]

Ich habe mir jetzt auch nochmal die Struktur meiner Items angeschaut, weil ja der Wunsch war, das an die bisherige Struktur anzupassen (also meine astro.yaml an die location.yaml). Das macht m.E. nicht viel Sinn, da ich ja wesentlich mehr Werte berechne und dann die Übersicht leiden würde. Ich habe mich auch mehr an die astronomischen Begriffe gehalten wegen der Eindeutigkeit. Insofern ist damit zwar die Abwärtskompatibilität nicht gegeben, aber wenn eh schon sehr viele grundsätzliche Änderungen passieren, ist ein sauberer Schnitt sinnvoll und eine Verwechslung mit bisherigen Items ausgeschlossen.

Der zweite Punkt sind die Zustandsänderungen. Astronomisch gesehen ist eindeutig festgelegt, wann Tag und wann Nacht ist. Ich gehe davon aus, dass viele User diesen Unterschied für Steuerungen nutzen, sofern sie so wie ich, nicht über einen Helligkeitssensor verfügen. Nun ist es aber so, dass jemand in Äquatornähe Tag/Nacht ganz anders erlebt wie jemand in Skandinavien (z.B. Mitternachtssonne) und insofern braucht wahrscheinlich jeder eine individuelle Einstellung, wann ihm das SmarthomeNG sagen soll, dass Tag oder Nacht ist. Ich habe das derzeit (ähnlich wie bisher in der location.py, wo es mit -6 Grad festgelegt ist) so gelöst, dass ich für day und brightness (neues Item) in meiner astro.yaml ein Attribut definiert habe, mit dem ich ein beliebiges Offset einstellen kann. Damit bin ich nicht an die astronomische Festlegung (-6) gebunden, sondern kann das passend für meinen Wohnort definieren. Das ist noch nicht die super Lösung, aber hilft denen die keinen Sensor haben, den Tag teilweise zur Nacht oder umgekehrt zu machen ;-)

Aus meiner Sicht könnte man das Ganze nun grundsätzlich ins Release aufnehmen, es wird aber sicher notwendig sein, Plugins o.ä. zu überprüfen, die bisher sunrise und sunset direkt angesprochen haben. Bei der Umstellung auf die shtime API habe ich sowieso gesehen, dass sicher einige Plugin noch aktualisiert werden müssten.