Weiterentwicklung von Smartvisu -> Visual Display for Fhem

[joshi04]

Treiber: Verstanden, vielen Dank.

Grafik aktualisiert und hab nochmal über die Kästen nachgedacht. Aber irgendwas is immer 
Was meinst Du?

[herrmannj]

Hallo joshi04,

vielen Dank, ich sehe das so als sehr gut !

Speicher Dir das Schaubild mal weg - später ;( wird der Apache wegfallen.

vg
joerg

[dev0]

später ;( wird der Apache wegfallen.

Wird es eine Option geben, die es zuläßt einen externen Webserver zu benutzen ohne sich zu verrenken?

[herrmannj]

Guter Hinweis, Danke!

Ne, hab ich bisher nicht auf der Uhr. Eigentlich sollte sich diese Frage auch so nicht stellen weil dar eingebaute Server ja dafür da ist das alles viel schöner zu integrieren. Btw, der externe war für einige user auch der Grund die Finger davon zu lassen weil sie Vorbehalte bei dem Mehraufwand der Konfiguration hatten.

Der (als fhem modul) integrierte Server soll zum Beispiel sorgen das die Config (driver, host, port, design, pages-dir, Zertifikate, user) zentral, sprich einmal, verwaltet wird.

Hast Du einen speziellen Grund zu der Frage, bzw Befürchtungen (sprich erwartete Nachteile) ?

vg
Joerg

[joshi04]

Überarbeitet Artikel im Wiki sind online.

Komplex bleibt das ganze Zusammenspiel mM natürlich auch, wenn die Seiten im Root des FHEM-Webservers liegen, gespannt bin ich natürlich trotzdem.
Zwischenzeitlich habe ich die Hoffnung, dass mit den Artikeln die Einrichtung auch für Anfänger ein wenig einfacher wird - und ich nicht zu viele Kinken eingebaut habe.

Eine Frage nun wirklich zur Weiterentwicklung:
Ich habe festgestellt, dass die fronthem.err bei mir im Basisverzeichnis der fhem-Installation liegt (/opt/fhem/). Wäre es sinnvoll den Pfad zu ändern, so dass die Datei bei den anderen Logs von FHEM landet (opt/fhem/log/)?

Schöne Grüße,
John

[dev0]

Hast Du einen speziellen Grund zu der Frage, bzw Befürchtungen (sprich erwartete Nachteile) ?

Kurz:
Bei mir würden sich wahrscheinlich Performancenachteile zeigen, da der Webserver (der auch für Anderes genutzt wird) auf wesentlich potenterer Hardware läuft als FHEM. Meine FHEM/SV Installation läuft aber auch innerhalb einer recht komplexen Infrastruktur.

Lang:
Generell wäre meine Idealvorstellung von einem FHEM/SV Setup dreigeteilt:
* Fronthem als reines Websocket Gateway
* Smartvisu incl. Treiber als reines Frontend
* Tool/Mechanismus um Widgets automatisiert in SV einzubinden und mit FHEM Devices zu verknüpfen.

Die Vor- und Nachteile, die ich gegenüber einem gemeinsamen Paket sehe, sind:
+ Ein Höchstmaß an Flexibilität bei der Installation um z.B. die vorhandene Infrastruktur (Security, HA, LB, CA) zu berücksichtigen.
+ Die Entwicklung der einzelnen Bestandteile wäre unabhängiger voneinander: um fronthem beispielsweise mit einem anderen Frontend einzusetzen oder auch einen Fork eines der Pakete einfacher nutzen zu können.
+ Den Ausfall eines der Entwickler(teams) einfacher kompensieren zu können.
- Komplexere Installation, die man sich mit dem Mehr an Flexibilität erkauft.

Die Antwort geht etwas über die eigentliche Fragestellung hinaus, gehört aber aus meiner Sicht doch dazu. Ich weiß auch nicht, ob die angesprochenene Flexibilität überhaupt von mehr als 0.001% der Anwender benötigt/gewünscht wird oder nicht der einfachste Installationsweg das Hauptzeil seinen sollte, um massentauglicher zu werden. Sofern das mit FHEM überhaupt möglich ist...

[HCS]

Bei mir würden sich wahrscheinlich Performancenachteile zeigen, da der Webserver (der auch für Anderes genutzt wird)

Eine ähnliche Situation habe ich auch. Wobei ich bei mir weniger (aber auch) Bedenken wegen der Performance und mehr wegen der Machbarkeit und dem Konzept habe.
In SV habe ich mein komplettes ehemaliges Intranet integriert und gerade die Möglichkeit, außerhalb von FHEM das alles plus die Visualisierung der FHEM-Daten zusammenzuführen war für mich ein wesentlicher Aspekt.

Zumindest in dem Fall, wo man in SV weitere Dinge hat, die nichts mit FHEM zu tun haben, ist es nicht so toll, wenn das alles unter dem Kontext von FHEM läuft.

Wie dev0 schon geschrieben hat, es könnte ja sein, dass er und ich die Ausnahme sind, keine Ahnung, aber seine restlichen pro/contras kann ich ebenfalls unterschreiben.

Ich denke es gibt zwei Grund-Use cases:
1. Man möchte ein FHEM mit einer anderen Oberfläche als dem Standard-Frontend
-> Dann ist voll integriert sicher ideal

2. Man hat ein Intranet in dem FHEM "nur" eine Datenquelle von mehreren ist
(das "nur" sitzt in Anführungszeichen, weil ich es keinesfalls abwertend meine)
-> Dann möchte man es lieber getrennt

[herrmannj]

ok, aufgenommen.

Ich halte das zwar für "corner"-case, behalte das aber im Hinterkopf !

Danke, vg
joerg

[joshi04]

Befürchte, ich gehöre auch in die "Ecke" da beim mir der Webserver ebenfalls Wiki, phpmyadmin und noch ein paar andere Dinge beheimatet. Wäre daher ebenfalls froh, wenn Möglichkeit 2 erhalten bliebe. Den Webserver brauche ich eh.
Schöne Grüße, John

[marvin78]

Ich betreibe zwar akutell FHEM und Webserver auf einer Maschine aber mein Plan war auch, meinen "großen" Webserver demnächst auch für smartVisu zu verwenden. Trotzdem würde ich ggf. die Variante ohne externen Webserver zunächst testen.

[michael.winkler]

ich gehöre auch eher zu denen die ihren SmartVISU Server auf einem eigenen Webserver betreiben.

[herrmannj]

ich gehöre auch eher zu denen die ihren SmartVISU Server auf einem eigenen Webserver betreiben.

Im Augenblick ist das ja auch der einzige Weg. Lasst uns das mal anschauen wenn es soweit ist. Ich habe abgespeichert das es den Wunsch gibt den Webserver stand alone (apache, nginx etc) zu betreiben.

vg
joerg

[joshi04]

Hallo zusammen,
versuche gerade, das Wiki etwas weiterzubringen und dabei sind 2 Fragen aufgekommen:
Soweit ich verstanden habe, basiert das derzeitige cleaninstall von herrmannj auf v2.7. v2.8 ist derzeit nur alternativ beschrieben, offiziell noch nicht released und daher auf eigene Gefahr, greift aber auch auf Bestandteile von cleaninstall zu (Installationsbeschreibung wurde von dev0 bereitsgestellt). Welche smartVISU Version sollte derzeit am ehesten für die Installation beschrieben werden? Passt es derzeit so, wie im Wiki beschrieben?

Soweit ich verstanden habe, wurde im Mega-Fred bereits Konsens erzielt, dass man versuchen sollte, alle Widgets in einem Repository zu sammeln. Wäre das das smartVISU-widgets-Repository von herrmannj, bzw. welches sonst?

Ich würde das Wiki dementsprechend anpassen.

Schöne Grüße,
John

[dev0]

Soweit ich verstanden habe, wurde im Mega-Fred bereits Konsens erzielt, dass man versuchen sollte, alle Widgets in einem Repository zu sammeln. Wäre das das smartVISU-widgets-Repository von herrmannj, bzw. welches sonst?

Ich glaube, dass die Frage aufgrund dieser Antwort im Forums Thread aufgekommen ist:

Im ersten Mega Fronthem Thread gab es bereits eine Diskussion, wie man Widgets am Besten einbindet. Konsens war, dass wir includen wollen. Darauf hin wurden die Widgets im herrmannj Repo auch entsprechend umbenannt. So kann man sie einfach downloaden und in den pages Ordner kippen. Man muss sie dann nur einmal includen. Bei einem Update einfach die vorhandenen Dateien überschreiben.

Mit "includen" meinte ich die technische Art und Weise: Die Widget Dateien sind nach dem Schema widget_<name>.<ext> benannt und sollen in die SV Konfig nur eingebunden/verlinkt werden und nicht in die visu.css/visu.js kopiert werden. Daurch kann man bei einem Update die Dateien einfach kopieren und muss die visu.* nicht bearbeiten. Beschrieben habe ich das hier: https://github.com/ddtlabs/smartvisu-widgets/wiki/HowTo-Install-Widgets

Davon abgesehen wurden die Widgets tatsächlich im herrmannj Repository gesammelt. Meine Widgets liegen dort nicht, da sie nicht mit der 2.7er Version kompatibel sind. Ich würde alle Repositories im Wiki angeben, die bekannt sind, da z.B. Weiterentwicklungen nicht zwangsläufig bei herrmannj landen (zur Zeit beispielsweise UZSU).

v2.8 ist derzeit nur alternativ beschrieben, offiziell noch nicht released und daher auf eigene Gefahr

So wie es im Moment aussieht (KNX Forum), wird es auch keine offizielle SV 2.8 von Martin Gleiss mehr geben. Forks werden aber mit Sicherheit nicht auf der 2.7er Version basieren -> Zukunft 2.8. Die Umstellung auf ein 2.8er-cleaninstall ist mMn nie umgesetzt worden, da Jörg sein next Release wiederholt verschoben hat und ihm niemand mit einem eigenen 2.8-pre-cleaninstall dazwischen funken wollte (zumindest ich nicht).
Um aber konkret auf Deine Frage bzgl. Wiki zu antworten: Ich würde das Wiki in diesem Zusammenhang so lassen wie es ist und das nächste Release von herrmannj oder Cybers abwarten. Wer jetzt schon die 2.8 benutzt und Widgets aus dem herrmannj Repo nutzt, muss damit rechnen, dass diese Widgets angepasst werden müssen, wenn sie pngs verwenden.

Mal schauen was die Anderen dazu sagen, ich würde aber vorschlagen diese Diskussion im Forums Thread weiterzuführen, da es hier um das Forken von SV geht.

@Cybers @herrmannj:
Gibt es bei Euch schon was neues in bezug auf sv fork bzw. next release?

[herrmannj]

work in progress. Wobei ich, als Empfehlung, bei neuen install gleich das 2.8er installieren würde.

vg
joerg