Weiterentwicklung von Smartvisu -> Visual Display for Fhem

dev0 · 04 Juni 2016, 12:08:28

- Apollo hatte angefangen ein Color Parameter bei den Widgets einzuführen. Ich hatte das mal für weitere Widgets fortgeführt. Kann ich gerne auf github einpflegen und einen PR stellen. Wohin eigentlich?
- Ich hatte vor einiger Zeit mal den Account "smartvisuNG" (next generation) als Organisation registriert. Macht es Sinn ggf. solch einen Organisationsaccount für das Projekt zu nutzen (muss nicht dieser sein)? Verderben viele Köche den ~~Brei~~Code oder macht das aus eurer Sicht auch Sinn?

herrmannj · 04 Juni 2016, 13:32:21

Zitat von: dev0 am 04 Juni 2016, 12:02:54
Meinst Du mit dem Codevorschlag das "includen" von js und css oder wirklich automatisch?

Automatisch laden.

Idee so: man hat jeweils pro "pages" ordner (damit nicht alles überall geladen wird -> performance) Unterordner wo eben die *.js, *css, *.html für ein widget liegen.

base (oder einer seiner Nachfolger) schaut einfach ob da was drin liegt (wie gesagt, pro "pages" ordner").
Wenn da was liegt dann wird es direkt automatisch eingebunden.

Die Idee:
ich muss für eine widget nicht mehr die user.js und user.css editieren und das umständlich includen.
Dadurch kann man widgets bequem per (fhem?) cmdline installieren. Der Installer muss wissen wo die source des widgets liegen (svn zb) und in welchen Pages das widget verwendet werden soll. Das lies sich (später) sogar bequem mit einem update kombinieren.

Das wäre imho ein guter Startpunkt für ein Ecosystem von user widgets. Müsste man für devs dann (halbwegs) vernünftig dokumentieren.

vg
joerg

herrmannj · 04 Juni 2016, 13:46:03

Zitat von: dev0 am 04 Juni 2016, 12:08:28
Verderben viele Köche den ~~Brei~~Code oder macht das aus eurer Sicht auch Sinn?

persönliche Meinung:

Es ist gut wenn einer den Hut auf hat und sagt wo es lang geht. (an der Position sind auch Nehmerqualitäten gefragt).

Warum? Sonst (alles persönliche Ansicht!) ist es sehr schwer eine Strategie und Architektur nachhaltig durchzusetzen.

Man kann eine gegebene Aufgabenstellung ja meist mit a,b oder c umsetzen - führt in der Regel alles zu akzeptablen Ergebnissen. Nach einer Weile stellt sich dann aber raus das neue Aufgaben, die auf vorhergehenden Aufgabenstellungen aufbauen, sich nicht mehr zufriedenstellend lösen lassen weil die bereits verwendeten Ansätze 'A' und 'B' (c,d,e---) sich "unter der Haube" doch so unterscheiden das man keine weiteren, zusätzlichen Lösungen (einfach, stabil etc) darauf aufsetzen kann.

Das braucht (mMn) eben einen "Kapitän" der auch Ansagen macht _wie_ etwas umgesetzt wird. Das ist, zugegebenermaßen, langsamer als die "Feuer freu" taktik, aber eben am Ende nachhaltiger.

Idealerweise (siehe vorhergehender Post) findet man eine Architektur in der die Domänen so getrennt sind das sich (zB) eine Gruppe gleichdenkender um den Core kümmert und andere Teile (zb Widgets) komplett getrennt entwickelt und gewartet werden können (ohne den core zu tangieren).

Das ist (meiner Erfahrung nach) dann der reichhaltigste Ansatz wo sich eben auch jeder einzelne gut Wiederfinden kann.

but: just my 5cc

vg
joerg

Cybers · 06 Juni 2016, 11:50:14

ich hatte für die Weiterentwicklung von Smartvisu den Account SmartViDi auf Github angelegt.
Alle Forks und Pull Requests habe ich eingebunden. Aktuell sitze ich an der Aktualisierung von Jquery. Sobald ich das fertig habe werde ich die neue Version auf Github uploaden

Gruß, Sascha

joshi04 · 11 Juni 2016, 21:53:56

Hallo Zusammen,

ich würde gerne das Wiki ein wenig überarbeiten (https://forum.fhem.de/index.php/topic,54506.msg460917.html#msg460917).

Damit ich dort nichts falsches hineinschreibe wäre ich dankbar, wenn jemand diese Übersicht kommentieren würde? Ich bin noch am Einlesen und hoffe, ich liege nicht ganz falsch.
Hinzu geplant kommt natürlich noch erklärender Text, der ist aber noch in Arbeit.

Ich habe die Hoffnung, dass sich der Einstieg zu fronthem/smartVISU dadurch noch weiter erleichtern lässt und auch die Dokumentation im Wiki weiterwachsen wird.

Den Entwicklern bis hierher für das Projekt in jedem Falle schon jetzt vielen Dank!

Schöne Grüße,
John

Edith: Das Diagramm wurde aufgrund der folgenden Posts aktualisiert.

dev0 · 12 Juni 2016, 09:45:24

Die Zeichnung ist nicht ganz richtig: Ein Smartvisu Browser greift auf 2 Datenquellen zu. Die (statischen) Webseiten werden vom Webserver (apache, http) geliefert, der dynamische Inhalt kommt vom Websocket Server (fronthem, ws). Eine Verbindung zwischen Webserver und ws server gibt es nicht. Die ws IP, die in Smartvisu konfiguriert wird, wird nur in die ausgelieferten Webseiten geschrieben, damit der Client darauf zugreifen kann.

drdownload · 12 Juni 2016, 09:53:46

Und die plots in smartvisu gehen direkt auf den MySQL

joshi04 · 12 Juni 2016, 12:13:16

Danke, genau wg, dieser Detail habe ich das hier gepostet.

Habe im obigen Post die Grafik geändert. Die Übersichtlichkeit hat leider durch die zusätzlichen Details etwas gelitten. Wenn man das im Text im Wiki aber näher beschriebt, sollte man das auffangen können.

Wusste nicht, wie und dass Plots überhaupt schon gehen, daher kann ich das nur auf Zuruf einfügen. Wenn der smartVISU Browser vom Endgerät direkt auf den MySQL Server zugreift, vermutlich dann über port 1433, oder?
Das könnte für Firewall- und VPN-Benutzung wichtig sein.

dev0 · 12 Juni 2016, 12:16:19

Nicht der browser greift auf den sql server zu, sondern der webserver mit hilfe von php.

joshi04 · 12 Juni 2016, 12:24:48

Next try (siehe post #34).

Sorry, wie erwähnt, Plots kenn ich noch nicht.

Aber eigentlich hab ich mir das schon gedacht, hab das von drdownload nur falsch gedeutet.

dev0 · 12 Juni 2016, 14:46:43

"Inhalte für Diagramme" ist mMn auch zu weit gefasst. Genau 1 Widget benutzt diese Verbindung zur DB derzeit. Auf Dauer würde ich davon ausgehen, dass das auch über die ws Schnittstelle läuft. Andere Plots (ohne historische Werte) funktionieren jetzt schon so.

herrmannj · 12 Juni 2016, 15:43:16

ZitatAuf Dauer würde ich davon ausgehen, dass das auch über die ws Schnittstelle läuft

Yepp!

joshi04 · 12 Juni 2016, 16:59:40

Ich denke, dann werde ich für das allgemeine Diagramm, dass die Zusammenhänge zum allgemeinen Verständnis darstellen soll, die Geschichte mit dem Datenbankserver und dem "Inhalt für Diagramme" lieber ganz weg lassen. Es soll ja auch Anwender geben, die anstatt DbLog Filelogs verwenden.

Solche Details/Sonderfälle (derzeit nur von einem Widget verwendet) gehören mM dann nicht auf eine solche Übersicht und sollten besser als Ausnahme dann spezifisch beim Widget beschrieben sein. Vor allen Dingen, wenn langfristig sowieso Anderes geplant ist.

Euch bis hierher erstmal vielen Dank. Wenn Ihr noch was für die Darstellung habt, natürlich immer gerne (letzte Version in #34).

Ich plane das Diagramm im Wiki-Artikel "smartVISU" verwenden.

joshi04 · 26 Juni 2016, 10:11:44

Ich bin bei der Beschreibung der Treiber-Funktion und noch nicht ganz sicher, ob meine Interpretation richtig ist. Würde mich freuen, wenn Ihr noch einmal drüber schaut:
Endgerät -> Anfrage an Webserver (Port 80)
Antwort vom Webserver -> Statische Inhalte + Information woher die dynamischen Inhalte kommen
dynamische Inhalte werden vom Endgerät beim WS angefragt und geliefert (Port 2121)

dev0 · 26 Juni 2016, 11:08:26

Der Treiber ist ein Stück Software (js), das in die ausgeliefertern Webseiten per Link eingebettet ist, auf dem Client ausgeführt wird und die Kommunikation zwischen Client und Websocketserver (fronthem) übernimmt und anpasst.

Weiterhin finde ich, dass in der Graphik der Kasten mit dem Frontend (pgm2,...) sich ebenfalls auf der Höhe der Module befinden sollte, da pgm2 alias FHEMWEB auch "nur" ein Modul ist.