Weiterentwicklung von smarthome.py

[blutwurst]

Ich hatte alles mal dokumentiert, Installation auf Raspbery 2 mit Jessie, sowie die Installation vom hombridge.

kann ich aufarbeiten und beisteuern......

wie sieht es mit ner Rubrik "CODESCHNIPSEL" oder sowas ähnlichem aus?
Da hätte ich noch Input.

Gruss

AXL

[psilo]

Würde ich ggf. aufteilen in Logiken, Plugins, Sonstiges. Und die Kategorien dann jew. weiter unterteilen. Ich fände so eine Rubrik aber auch gut. Einfach mal zum Sammeln von komplexen, kreativen, nützlichen Logiken. Als Beispiel: ich rechne die Windstärke meiner Wetterstation per Logik in Beaufort um und packe noch eine textuelle Beschreibung dazu. So ein Codeschnipsel hätte mir Arbeit erspart.

[cmalo]

Manche Logiken können eigentlich auch ins sh.py, oder? Zumindest wenn sie allgemein und vernünftig geschrieben sind. Ich habe bei mir auch ein paar die würden sofort bei jedem anderen auch laufen. Man könnte in ein sh.py Release so ein Set an Logiken unterbringen und wenn der Nutzer sie braucht kann er sie über die conf aktivieren.
Hat den Vorteil, dass man nicht alles zusammensuchen muss.

[psilo]

Naja die Items sind halt meist speziell. Daher fände ich mind. im Falle meiner Logiken die im Wiki als "Beispiele" besser untergebracht.

[cmalo]

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.

Ich kann mal als nächstes ein REST Plugin implementieren, ist nicht die Welt wenn man weiß wie das Zeug funktionieren muss.

[psilo]

Jo wäre cool. Mit Python nen Web-Server aufspannen ist nicht so tragisch?

Ansonsten würde ja reichen, in der URL die item-Hierarchie abzubilden und ein "set" bzw. "get" plus den jew. Wert. Intern müsste dann natürlich eine Prüfung auf die Gültigkeit des Wertes erfolgen, das sollte das Item-System aber jetzt schon handeln, oder?

[hotzen]

Bitte halbwegs idiomatisches REST, GET & POST/PUT statt get/set

[henfri]

Naja die Items sind halt meist speziell. Daher fände ich mind. im Falle meiner Logiken die im Wiki als "Beispiele" besser untergebracht.

Na, man kann die logik an sich ja mit generischen Variablen namen schreiben. Im Header der Logik kommt dann eine Zuweisung zu zw. den internen Variablen und den items des Projekts.

Ähnlich einem LBS beim Homeserver.

[cmalo]

man kann die logik an sich ja mit generischen Variablen namen schreiben.

Sehe ich auch so, wenig Aufwand, aber die Sauberkeit steigt, enorme Vorteile durch Wiederverwendung und jeder muss nicht immer für alles seine eigene Logik entwickeln.

[heckmannju]

Sehe ich auch so, wenig Aufwand, aber die Sauberkeit steigt, enorme Vorteile durch Wiederverwendung und jeder muss nicht immer für alles seine eigene Logik entwickeln.

Das finde ich eine Sehr gute idee!

[awknx]

Wenn ich als Anfänger auch was dazu sagen darf:

Ich bin bei smarthome.py und smartVISU gelandet, weil ich ich mir das Cape von Robert für den Beaglebone gekauft habe und es dort vorinstalliert ist. Ausschlaggebend für das Board war für mich, dass ich im Gebäudebestand im Lauf der Zeit teilweise KNX nachrüste und mir schon bei anderen Gelegenheiten 1-wire gut gefallen hat. Die Fenstergriffe für EnOcean haben es dann für mich perfekt gemacht.

Ich fand es anfangs extrem schwierig, zu entscheiden, ob KNX, EnOCean, FHEM, OpenHAB usw. für mich das Richtige sind (oder die FS20 usw. einfacher sind) und habe mir zum ganzen Thema auch das Buch von Stefan Heimle besorgt gehabt. Nach der Weihnachtslektüre war für mich klar, es soll die Eigenbaulösung werden und nicht ein Homeserver o.ä. von der Stange.

Ich habe jetzt einige Stunden damit verbracht, alles mal rudimentär zum Laufen zu bringen. das liegt an mehreren (auch eigenen) Ursachen:

- Für einen Linux-Nichtprofi stellen sich die ersten Hürden beim Starten, Stoppen und Debug (doppelt laufende Prozesse, Suche nach den Logdateien, Klarkommen mit unterschiedlichen Pfadangaben je nach Linuxsystem, fehlender ftp-Server, danach falsche Rechte usw.). Habe z.B. bis heute den Monitor am HDMI nicht zum Laufen bekommen und mache es nun mit Kitty und rdp...

- Es fehlt in der Doku zu smarthome.py so eine Art Einleitung, wie das Zusammenspiel der ganzen Komponenten eigentlich abläuft.

- Ich kann aus den doch sehr knappen Angaben z.B. beim knx Plugin nicht wirklich erschließen, was die einzelnen Befehle (z.B. knx_cache) letzlich genau tun und wann man welchen Befehl besser einsetzt. Es gibt zwar viele, viele Beispiele, aber in jedem wird es anders gemacht. Hilfreich wären für mich da "offizielle" Beispiele für Grundfunktionen (Licht schalten, Licht dimmen, Temperaturen lesen, usw.). Ich glaube, das würde vielen Einsteigern schnell weiter helfen. Alle Beispiele bringen mir aber nur was, wenn ich die item.conf und auch den Einsatz in der smartVISU sehe - meist fehlt die item.conf zum Verständnis.

Mindestens genauso schwierig war für mich jetzt der Einstieg in smartVISU, obwohl ich schon lange Websites baue:

- Es läuft anfangs out of the box, aber bei der Gestaltung der Seiten stolpert man dann ziemlich schnell über viele Kleinigkeiten, deren Ursache man nicht gleich findet (z.B. bei mir ein Projektordner in pages, den ich smarthome genannt hatte, dann die zwei unterschiedlichen Möglichkeiten für den Seitenaufbau manuell oder automatisch mit sv_ usw., die ganze Inkludiererei über verschiedene Verzeichnisse)

- Viele unklare Angaben (z.B. über die Verwendung der svg-Icons), die dann im smartVISU-Ordner auch nicht konsequent durchgezogen sind oder Zahlenwerte, die als Strings behandelt werden

- "Offizielle" Beispiele, die dann aber komplett unterschiedliche Seitenstrukturen referenzieren (z.B. rooms_menu und navigation)

- Auch hier keine Übersicht, wie die Templates und die Einbindung von css usw. überhaupt strukturiert sind, usw.


Versteht mich bitte nicht falsch - ich will hier nicht meckern, sondern aufzeigen, an welchen Stellen man den Einsteiger besser abholen könnte. Letztlich findet man ja im Netz dann alle Infos und auch die Hilfe hier im Forum hat mir viel und schnelle Hilfe gebracht, ich könnte mir aber vorstellen, dass Andere da früher aufgeben.

Wichtig finde ich insgesamt, dass alles zu smarthome.py und smartVISU möglichst zentral an einem Ort zu finden ist und die Doku ausführlicher wird. Zumindest beim Thema Doku könnte ich mich ggf. mit einbringen.

Damit und mit meinem seit heute funktionierenden, ersten Dimmer in der Visu :-)) wünsche ich euch ein schönes Wochenende
Andi

[psilo]

@awkn: ich stimme Dir voll zu. Als ich vor einem 3/4 Jahr in der Elternzeit eingestiegen bin, kursierten auch 1000 unterschiedliche Beispiele und kein Befehl war wirklich klar. Vor 2 Jahren fand ich vieles im Projekt noch so konfus, dass ich erstmal auf linknx und eine eigene PHP-basierte Webservice-Schicht obendrüber gegangen bin.

Zu SV: Ich habe auch 2stellige Jahre Webentwicklung hinter mir, habe bis heute aber nicht 100% das Templatesystem von SV begriffen - kriege bspw manchmals "if"s nicht hin, weiß nicht ob es ein else gibt etc.. Habe früher viel mit der Templateengine "Smarty" gearbeitet, die war deutlich flexibler... Trotzdem baue ich mitlerweile komplexere Widgets, aber immer unter Einschränkungen bzgl. "Programmierung"..

Zu SH: Auch wenn ich das AVM Plugin für SH meines Erachtens ganz passabel hinbekommen habe, lerne ich zum Kern und den anderen Plugins aktuell noch massiv dazu. Gerade bei Attributen die überall anders verwendet werden, hilft m.E. nur der Blick in den aktuellen Code!
Und das sollte man genau dann auch vernünftig in eine Doku gießen, so dass es der nächste nicht auch machen muss. Ich denke für unsere Doku ist das der richtige Ansatz - man muss halt bereit sein "unter die Haube" zu schauen.