Weiterentwicklung von smarthome.py

[Hochpass]

Da ich da nun zu viel Arbeit reingesteckt habe werde ich die nächsten 3-5 Jahre das Vorhandene nutzen. So oder so.
Eine Weiterentwicklung würde mich natürlich freuen.

[mumpf]

Hi,

ich werde callidomus sicherlich nutzen, aber auf absehbare Zeit nur den Visu-Teil. Es ist unglaublich, was Marcus da an Geschwindigkeit rausgeholt hat. Selbst auf schwacher Hardware ging seine Visu richtig flott! Damit kann man SmartVisu gar nicht vergleichen.
Die Umgebung, die ich mir für sh.py-Items programmiert habe, um bei den derzeit 5500 Items den Überblick zu behalten, möchte ich aber nicht missen, deswegen sehe ich den Umstieg noch nicht - da muss ich ein Gefühl bekommen, wie man bei callidomus Items generieren kann. Und solange callidomus keine State-Engine hat, kann ich sowieso nicht umsteigen...
Insofern würde auch ich mich über die Weiterentwicklung von sh.py freuen. Mein Beitrag dazu wird sich allerdings eher auf Hilfestellung im Forum beschränken, da ich aus beruflichen Gründen nur am Wochenende überhaupt was machen kann, und derzeit komme ich nicht mal zu meinen Haus-Projekten.

Gruß, Waldemar

[cmalo]

Hi Alex,

ich würde in dem Zuge auch ein Fork von Smartvisu ziehen. Die Entwicklergruppen überschneiden sich stark und sind in hohem Maße voneinander abhängig. Außerdem sind momentan die jeweiligen Development Versionen von Smarthome.py und smartvisu nicht kompatibel. Das sollten wir wieder herstellen.

Ist so ne Sache, smartVISU wird noch von anderen Projekten verwendet (FHEM, DomotiGa,.. ). Ich würde zuerst zusehen, das smarthome.py sich der smartVISU anpasst, das kann man leicht innerhalb von smarthome.py machen.

EDIT: Ach ja die Plots :-/

Ein neues Release ist dort nicht geplant. Ein Blick in die Git Logs bzw. letzten Aktivitäten des Admins sollte dazu ausreichen.
Ich würde mich freuen, wenn smartvisu mit ins neue Repo übernommen wird. Sobald das steht, stelle ich dort die laufenden Pull-Requests ein, um die Kompatibilität wieder herzustellen.

Im smartVISU Forum hat jonah64 das Thema fork mal angesprochen. Das mit den Pull-Requests und verteilter Software über repositories ist leider traurig und bremst die Entwicklung, wurde aber auch schon mehrmals angesprochen, Mal schauen was Martin dazu sagt.

Gruß
Christian

[psilo]

Um nochmal den Diskussionspunkt mit der Geschwindigkeit aufzugreifen: mir ist aktuell unklar, wo bei der SV Probleme sein sollen. Zumindest dann, wenn man aktuelle Hardware verwendet. Auf sämtlichen aktuellen Mobilgeräten bei uns im Haushalt läuft die SV mega schnell. Auch mehrere Charts etc mit größeren Datenmengen. Ich kann mir gut vorstellen, dass das SQlite im SH.py irgendwann ein Bottleneck wird, aber auch hier sollte man mit Hardware eines halbwegs aktuellen Serversystems gegensteuern können. Ja, wenn ich auf nem Raspi 1 kombiniert mit einem iPad 1 oder ähnlichem den ganzen Verbund laufen habe glaube ich auch, dass die Performance hakt, aber die Hardware entwickelt sich nun mal nach vorne und nicht nach hinten... Zumindest meine pers. Meinung... Ich lasse mich gerne von Callidomus positiv überraschen, ich glaube nur nicht daran, dass eine webbasierte Anwendung noch schneller laufen kann als es SH/SV aktuell bei mir tut. Spannend wäre, wieviel Datenbestand bei der Demo von Callidomus bereits im Hintergrund erfasst war.

[psilo]

Wie gehen wir mit dem "alten" sh.py Wiki um? Nachdem ich gerade bei DWD auf Änderungen seitens des DWD FTP Servers reagiere, müssten Wikieinträge auch angepasst werden... Auch könnte ich mir gut vorstellen, mit einem ausgebauteren Wiki doch mehr neue Interessenten "anzulocken".

[cmalo]

Hi,

mein Vorschlag wäre die ganze Dokumentation primär im Wiki zu pflegen. In das "alte", also von Marcus muss ein Hinweis hin, dass es einen Fork und eine aktuelle Version der Dokumentation gibt.
Meiner Meinung nach lebt oder stirbt mit der Doku ein Projekt, deswegen sollte diese gut zu gebrauchen sein.

Wenn jemand Lust hat die Doku zu überarbeiten (auch für die Plugins) darf sich melden.

Grüße
Christian

[aschwith]

Danke Christian für Deine Initiative! Top Sache!

[blutwurst]

Hallo,

nachdem ich ich vor mehr als 3 Jahren von Misterhouse zu Smarthome.py gewechselt bin, möchte ich ungern wieder diesen Wechsel vornehmen.
Zudem ich mich nun 4 volle Tage mit openHab beschäftigt habe, bin ich sehr unschlüssig, da "unser" sh.py schon viele Vorteile bietet.
Alleine die Performance auf einem Pi 2 ist um Welten besser, als bei OpenHab und das bei nur wenigen Items und (Rules) Logiken.
Von der Visu mal ganz abgesehen.....

Daher werde ich wohl in nächster Zeit "zweigleisig" fahren, wobei mir das Smarthome schon etwas ans Herz gewachsen ist.

Sollte es es weiter gehen, bin ich jedenfalls mit dabei, da Smarthome meine erste Wahl bleibt.

Gruss

axl

[psilo]

@blutwurst: hast Du in OpenHAB mal die REST Schnittstelle angesehen? Taugt die was? Das wäre für mich DER Grund gewesen das auch mal anzusehen. Aktuell ist meine selber geschriebene Schnittstelle auf Basis EIBD, LinKNX und PHP, das aber nur weil ich zu Anfang keine andere Alternative kannte. Das Python-Zeug wird aber vermutlich immer schneller als Java laufen. Frage ist halt, ob das auf stärker Hardware noch merkbar ist..

PPS: Habe jetzt auch angefangen das neue Wiki zu pflegen. Meine Änderungen am DEV-Stand des DWD Plugins sind reinkommentiert. Wäre super, wenn irgendwer das Plugin auf diesem Stand auch mal testen würde.

[blutwurst]

Hallo,

@psilo:
nein, soweit bin ich noch nicht gekommen, bzw. ich hatte da andere Prioritäten gesetzt.
Habe mir hauptsächlich die Programmierung der Logiken und Einrichtung der Bindings angesehen.

Einen Tag hatte ich auch der openHab version 2.0 gewidmet.
Die hat echt Potential, grade in Verbindung mit habmin2.

Die vielen Bindings sind natürlich sehr interessant, aber ....
Aber das träge Java Gedöhns ist absolut nicht performant auf nem 2 er Pi.
(licht an / aus )hat manchmal ne Sekunde Verzögerung.
...und extra die Hardware zu tauschen kommt momentan nicht in Frage.

Grüsse

axl

[psilo]

@blutwurst: auch wenn mich Python in der Entwicklung echt etwas frustet bin ich deshalb auch eher für die smarthome.py Weiternutzung, auch wenn das NAS im Keller ordentlich Power / RAM unter der Haube hat... wir kriegen das in der Community schon vernünftig hin. Dann baue ich vielleicht die PHP REST Schnittstelle auch etwas generischer und stelle auf smarthome.py um, so dass von Haus aus auf alle Items Zugriff ist..

[henfri]

Zudem ich mich nun 4 volle Tage mit openHab beschäftigt habe, bin ich sehr unschlüssig, da "unser" sh.py schon viele Vorteile bietet.
Alleine die Performance auf einem Pi 2 ist um Welten besser, als bei OpenHab und das bei nur wenigen Items und (Rules) Logiken.
Von der Visu mal ganz abgesehen.....

Das interessiert mich jetzt.

Abgesehen von der Performance: wo siehst du die Nachteile von OH?

Bei OH reizt mich die breite Entwicklerbasis.

Gruß,
Hendrik

[blutwurst]

Hallo,

also, die Programmierung der Logiken ( bei oh Rules genannt) ist eigentlich super.
Die Plugins (bei oh bindings) sind reichlich vorhanden, aber alleine für einen callmontor für die fritzbox hab ich 3 verschiedene Bi Dinge testen müssen.
Es ist zwar eine große Entwicklergemeinschaft vorhanden, doch kommt es mir sehr wild und undurchsichtig vor. ( Beispiel Fritz Plugin).
Teile der Bindings/ Adonis werden nicht weiterentwickelt - siehe greent Visu.
Für eine pushnachricht mit Foto zu versenden, musste ich es über ein perl Skript realisieren. Nur testweise....
naja, es ist ein ziemliches Gefrickel um diverse Abfragen hin zu bekommen.

Ok, ich bin wohl auch ein klitzekleines bisschen Eingenommen von unserem schönen......sh.py.


Die Visu hat etwas von meiner alten Misterhouse Visu, aus dem Jahre 2010. ( wobei die damals richtig gut war) ... DAMALS!
...sieht sehr nach der Handschrift von RaK aus.
Die cometvisu hab ich mal außen vor gelassen.

Mit persönlich ist momentan die Baustelke zu groß und ich werde OH2 abwarten, das hat mir richtig gut gefallen.
...ist aber sehr buggy.

Aber ich hoffe ehrlich, dass wir das Smarthome.py am Leben halten und weiterentwickeln können.

grüsse


Axl

[psilo]

Na dann bitte fleißig beteiligen. Am Wiki könnte man anfangen, mE. ist viel zu wenig Info da drin. Man könnte auch mal mehr zum SH Core dokumentieren, wenn da schon jemand tiefer reingeschaut hat... Und vor allem sollten wir acht geben, dass am Ende eben nicht genau das hier passiert: "Es ist zwar eine große Entwicklergemeinschaft vorhanden, doch kommt es mir sehr wild und undurchsichtig vor."

[bmx]

Ja, das mit dem Wiki ist eine gute Idee. Ich habe mal angefangen und einen Eintrag für die Fehlersuche erstellt. Aus gegebenen Anlaß für Neulinge wäre es schön, wenn man das ein wenig erweitern könnte.
Auch eine Seite mit Featurewünschen bzw. Änderungswünschen wäre recht nett. Ich habe mal was vorbereitet.

Gruß,
Bernd