Was schwebt Euch bzgl. Visu vor?

[henfri]

Hallo,

die Performance mit einem 'einfachen' update der jQuery-Version zu verbessern klingt reizvoll.
Meine Gedanken zur Visu -die Reihenfolge ist keine Priorisierung:

• Kein Malen nach Zahlen. Ich will keine Männervisu, sondern Freizeit. Das ist in meinen Augen die große Schwäche von EDOMI. Da gibt es keine Templates nix. Jeder RTR muss einzeln aus vielen 'basic' Elementen zusammen gebastelt werden. Dann kann er kopiert werden. Will ich aber alle 15 ändern, so muss ich halt alle 15 ändern.
• https Unterstützung inklusive Authentifizierung
• Keine App nötig
• Auto-Reconnect
• Editor, möglichst WYSIWYG
• Editierung auch in Konfig-Files möglich (ist oft einfach schneller, für sich wiederholende Dinge)
• Auswahl von Objekten im Editor aus List-Boxen (ich kann mir meine Items nicht merken), oder ähnlich
• Schnell
• Hübsch

Die Comet-Visu ist sicher einen Blick wert. Ich kann die Kritik, dass sie nicht so hübsch ist nachvollziehen. Das liegt aber nicht an der CV, sondern an den existierenden Designs. Es gibt für mich keinen Grund zu glauben, dass es einfacher ist, eine neue, hübsche Visu aus dem Nichts zu zaubern, als ein schönes Design für die CV, denn für beides braucht man jemanden, der ein Händchen für das Design hat.
Was bei der CV vielleicht noch speziell ist, ist wie die Diagramme erzeugt werden (rrdtool); Ich bin nicht sicher, dass es damit getan ist, ein Backend zu schreiben, welches die Statii überträgt.
Ansonsten, erfüllt die CV die Kriterien glaube ich sehr gut. V.a. gibt es eine User und Entwicklerbasis.

Gruß,
Hendrik

[psilo]

Ich verstehe ja den Drang nach einer "automatisch zusammenklickbaren" Visu, ich möchte aber nicht wissen, was da an HTML dann herauskommt.. Und eine andere Chance als HTML hat man bei "keine App nötig" wohl kaum. Für mich muss daher die Visu zwingend auch im Codeeditor baubaer sein, PHP, Python oder Java + das mind. für die Websocket-Updates nötige Javascript ist mir als dahinterliegende Programmiersprache wurscht.

Bei HTTPS und Passwortschutz verstehe ich nicht, wieso man das nicht einfach auf Apache-Ebene konfiguriert so wie es sich gehört? Eine Visu muss (und mE darf) nicht die eierlegende Wollmilchsau sein. Im Endeffekt will man eine schnelle schlanke und hübsche "responsive" HTML5 Webapp haben und nicht ein featureüberladenes Monster.

Was mir an der SV aktuell nicht behagt:
Werte werden nur in größere HTML Strukturen eingefügt. Ich würde bspw. gerne über SH.py auch URLs/IPs in Items schreiben und einfach in einen "a href" einfügen. Das geht so out of the Box erstmal nicht. Auch kann ich auf die Werte keine komplexen Logiken in der GUI anwenden.
Dazu - soweit habe ich das jetzt auch gefühlt - die Performance. Ich nutze bei "schnellen" Aktionen mitlerweile nur noch meine App, auch wenn die weder hübsch noch komfortabel noch sonders strukturiert programmiert ist.

[smai]

Bei HTTPS und Passwortschutz verstehe ich nicht, wieso man das nicht einfach auf Apache-Ebene konfiguriert so wie es sich gehört?

Volles Einverständnis. Zuminest HTTPS muss ja zwingend der Webserver übernehmen, dies kann die Visu gar nicht.
Beim Passwortschutz kann man sich allenfalls fragen, ob Basic Authentication wirklich die beste Methode ist. Tauglich ist sie allemal.

Damit HTTPS benutzt werden kann, darf die Visu allerdings Clientseitig ausschliesslich per HTTP kommunizieren. Genau dies ist aber bei der SV nicht gegeben, weil diese direkt aus dem Browser mit SH.py/KNXD/... spricht.
Dies ist für mich neben der Performance der grösste Nachteil der SV.

[bmx]

Ok, dann mein Senf auch dazu:

• Das Hauptproblem derzeit ist der Entwicklungsstau bei SmartVISU durch das Nichtmelden des Entwicklers.
• Die Idee mit den Widgets ist prima und die würde ich auch gerne behalten. Es ist wenig reizvoll 10 RTR immer zusammenzuklicken um nachher festzustellen, das die doch alle irgendwie anders sind.
• Auto-Reconnect gibt es als Patch, Code ist im Forum verfügbar
• Auf einen WYSIWYG Editor kann ich derzeit verzichten. Aber Anfängern könnte das sicher helfen. Ich wäre aber eher für eine automatisch generierte Visu über das SmartHomeNG Plugin und eine entsprechende Doku, wie sich das in eigene Seiten umsetzen läßt ohne das alles überschrieben wird.
• Editierung vor allem in HMTL-Files
• Auswahl von Objekten im Editor aus List-Boxen (ich kann mir meine Items nicht merken), oder ähnlich
• Schnell(er) ja, dazu siehe Entwicklungsstau
• Hübsch - ist sie schon, jeder kann ja machen was er will. Das macht die Visu so universell. (Aber auch nicht unbedingt einfach zu verstehen am Anfang)
• PHP mag ich nicht. Ich hätte schon lieber nativ was via Python. Letztendlich ist es aber wurscht, wer den HTML Code zusammenträgt ob Python oder PHP. Mir geht nur die Unstrukturiertheit der SmartVISU in Bezug auf Dokumentation "wann wird von wo was eingebunden" und "wie kann ich verhindern, das für jedes Widget x-mal das zugehörige JavaScript eingebunden wird" auf den Keks. Da wäre es schon praktisch wenn das besser geregelt und nachvollziehbar ist.

[Boomer55]

Zum Thema möchte ich jetzt auch noch meinen "Senf" dazugeben...

Ich habe mich damals für SmarthomeNG entschieden, weil ich die Kombination von Logik und Visualisierung (SmartVisu) cool fand.
Auch die Autogenerierung der Visuseiten mithilfe der sv_widgets hat mir dabei sehr geholfen und meine Visu läuft heute noch so. Sicher nicht sonderlich hübsch, aber für mich und meine bessere Hälfte vollkommen ausreichend. Für den Fall, dass ich das Ganze nun "aufhübschen" möchte, hab ich mir ein Buch über HTML und CSS gekauft. Der ein oder andere möge nun sicherlich schmunzeln, aber für mich als Anwender fühlt es sich so richtig an. Die Autogenerierung war übrigens auch der Grund, wieso ich in der Zeit als es so aussah, dass dieses Projekt tot wäre von Edomi doch wieder zu SmarthomeNG retour wechselte. Ich wollte mir einfach nicht für jeden "Furz", was Eigenes zusammenklicken, zeichnen und parametrieren. Da wäre ich sicherlich einen (zugegebenermaßen) hübschen und sehr zeitaufwändigen Tod gestorben. Das wollte ich mir und meiner Familie echt nicht antun.

Daher wäre für mich an 1. Stelle noch immer die SmartVisu wegen der einfachen Autogenerierung der Seiten. Schade halt, dass beim SmartVisu-Projekt (für mich gefühlt) die Entwicklung eingestellt wurde. An 2. Stelle kann ich auch gut mit einer anderen Visualiseriung leben, wenn nur die Autogenerierung bestehen bleibt.

Beste Grüße,
Markus

[henfri]

Volles Einverständnis. Zuminest HTTPS muss ja zwingend der Webserver übernehmen, dies kann die Visu gar nicht.
Beim Passwortschutz kann man sich allenfalls fragen, ob Basic Authentication wirklich die beste Methode ist. Tauglich ist sie allemal.

Damit HTTPS benutzt werden kann, darf die Visu allerdings Clientseitig ausschliesslich per HTTP kommunizieren. Genau dies ist aber bei der SV nicht gegeben, weil diese direkt aus dem Browser mit SH.py/KNXD/... spricht.
Dies ist für mich neben der Performance der grösste Nachteil der SV.

Fullquote, denn genau das wollte ich auch gerade schreiben.

• Auf einen WYSIWYG Editor kann ich derzeit verzichten. Aber Anfängern könnte das sicher helfen. Ich wäre aber eher für eine automatisch generierte Visu über das SmartHomeNG Plugin und eine entsprechende Doku, wie sich das in eigene Seiten umsetzen läßt ohne das alles überschrieben wird.

Ja, es muss kein WYSIWYG Editor sein.
Aber ein Editor wäre schon sehr schön. Wie oft habe ich mich beim Zählen der , '', '', '', 24h verzählt... Und wo gehört jetzt noch mal der Parameter 'legende' hin? Wie war noch gleich die Syntax?
Die Auto-Generation habe ich nie genutzt, da es mir zu einschränkend war, die Visu genau so wie die Items zu strukturieren. Vielleicht gibt es dafür aber ja auch eine Lösung, die ich nicht kenne.


Gruß,
Hendrik

[smai]

Eine gute Autogenerierung ist für mich übrigens auch ein absolutes Muss.
Ich nutze ausschliesslich die Autogenerierung. Wenn man sich bei der Definition der sv_widget Attribute etwas geschickt anstellt, erhalte ich genau das Ergebnis, das ich will.
Meine Anlage ist noch im Wachstum und ich habe keine Lust, bei jedem neuen Item auch in der Visu etwas anzupassen.

[Msinn]

Eine gute Autogenerierung ist für mich übrigens auch ein absolutes Muss.

Ich habe die Autogenerierung für das Release 1.2 erweitert. Die Erweiterungen sind größtenteils im Wiki dokumentiert (https://github.com/smarthomeNG/smart...utogen_in_v1.2). Hast Du noch Ideen/Wünsche für eine Erweiterung/Verbesserung?

[smai]

Mit der Generierung für die SV bin ich absolut zufrieden, danke.
Meine Aussage war bezogen auf einen allfälligen Ersatz der Visu.

[henfri]

Hallo,

um die Autogeneration zu nutzen, sollten die Items ja nach Raum sortiert sein (oder?). Momentan habe ich sie nach Gewerk sortiert.
Hat jemand eine Idee, wie man das am einfachsten ändern kann?
Ich fürchte, es gibt da keinen Editor, der einem da wirklich behilflich ist, oder?

Außerdem fällt es mir schwer, die Dokumentation in Code umzusetzen. Es ist nur ein recht kurzes Beispiel dabei. Wäre jemand bereit seine Visu hier als Beispiel zu zeigen? (Code&Screenshots)

Gruß,
Hendrik

[Msinn]

Hallo Hendrik,

ich habe das bei mir so gelöst, dass ich die Visu Attribute in einer .conf Datei abgelegt habe, die alphabetisch von meinen anderen .conf Dateien liegt. In dieser Datei habe ich NUR die Visu spezifischen Einträge (sv_widget, sv_nav_aside, ...). Dort habe ich die Raum Struktur so aufgebaut, wie sie in der Visu erscheinen soll.

Ich füge mal ein (zugegeben komplexes) Beispiel bei.

Die ellenlangen sv_nav_aside2 Einträge dienen dazu in der Navigation je nach Status verschiedene Icons in verschiedenen Farben anzuzeigen.

Nachtrag:

• Voraussetzung ist SmartHomeNG 1.2. Sonst kennt das Plugin die neuen Attribute (sv_nav_aside, ...) nicht.
• Außerdem kann meine Installation bereits mit mehrzeiligen Attributen umgehen (kommt mit SmartHomeNG 1.3). Das hilft sehr bei der Les- und Bearbeitbarkeit. In älteren Versionen von SmartHomeNG muss das '\' am Zeilenende und der Zeilenumbruch entfernt werden, damit die Attribute richtig ausgewertet werden.

[bmx]

Sehr schöner Ansatz Martin, danke für's teilen im Forum!

[thesing]

Wenn ich mir was für die Autogenerierung wünschen darf:
- Möglichkeit das Zeilenende zu maskieren. Aktuell muss man alle Widgets in eine Zeile schreiben. Spätestens bei einer Tabelle wird es unübersichtlich.
- '#' sollte benutzt werde können. Folgendes führt z.B. zum Fehler {{ plot.period('p2', ['bath_plot1', 'bath_plot2', 'bath_plot3'], 'avg', '1h', 0, 0, 100, '', '',['#aa0', '#a00', '#00a'], ['area', 'column', 'line']) }} (Beispiel auf SV-Doku)

- die Seite Apps (smartvisu/index.php?page=apps) ist IMO überflüssig
- Bei den Kategorien (smartvisu/index.php?page=category) werde die generierten Seiten nicht auf dem Handy angezeigt. Es wäre auch schön, wenn die ganzen Links auf der Kategorienseite durch etwas sinnvolles ersetzt werden würden.
- Eine Möglichkeit ein Widget komplett auf eine Seite zu bringen wäre auch schön (ohne es in einen kleinen Block zu packen. Am PC kann ein Plot ruhig die volle Bildschirmbreite nutzen)
- Noch als Idee: die Ids der Widgets könnte man sicherlich auch automatisch generieren. (z.B. $ID durch eine fortlaufende Nummer ersetzen)

Das wäre es erst mal

Viele Grüße,
Thomas

[henfri]

ich habe das bei mir so gelöst, dass ich die Visu Attribute in einer .conf Datei abgelegt habe, die alphabetisch von meinen anderen .conf Dateien liegt. In dieser Datei habe ich NUR die Visu spezifischen Einträge (sv_widget, sv_nav_aside, ...). Dort habe ich die Raum Struktur so aufgebaut, wie sie in der Visu erscheinen soll.

Verstehe.
Allerdings verstehe ich dann den Sinn der Autogeneration nicht mehr.
Denn ein großer Vorteil ist doch, dass ich die Items nicht mehr tippen muss, wenn ich die sv_widgets bei den Items definiere. Wo ist bei dieser Lösung der Vorteil gegenüber dem einfachen Schreiben von HTML-Seiten?

Ich denke, wenn man die Autogeneration konsequent nutzen will, muss man die Items wie die Visu strukturien -wahrscheinlich nach Räumen/Etagen.

Ich füge mal ein (zugegeben komplexes) Beispiel bei.

Danke!

[Msinn]

Hallo Thomas,

- Möglichkeit das Zeilenende zu maskieren. Aktuell muss man alle Widgets in eine Zeile schreiben. Spätestens bei einer Tabelle wird es unübersichtlich.

Schau mal in mein Beispiel. Dort sind die Widgets in einzelenen Zeilen. Das setzt aber ein Feature von SmartHomeNG voraus, dass es erst in das Release 1.3 schaffen wird. (Im Dev ist es bereits drin)

- '#' sollte benutzt werde können. Folgendes führt z.B. zum Fehler {{ plot.period('p2', ['bath_plot1', 'bath_plot2', 'bath_plot3'], 'avg', '1h', 0, 0, 100, '', '',['#aa0', '#a00', '#00a'], ['area', 'column', 'line']) }} (Beispiel auf SV-Doku)

Guter Punkt. Aber auch dieser Punkt muss in SmartHomeNG im Config-Parser geändert werden. '#' und alles dahinter werden bereits beim Parsen gekappt. und schaffen es gar nicht bis in das Attribut.

- die Seite Apps (smartvisu/index.php?page=apps) ist IMO überflüssig

Muss in der smartVISU geändert werden.

- Bei den Kategorien (smartvisu/index.php?page=category) werde die generierten Seiten nicht auf dem Handy angezeigt. Es wäre auch schön, wenn die ganzen Links auf der Kategorienseite durch etwas sinnvolles ersetzt werden würden.

Schau ich mir an. Eigentlich sollten die Links die jeweilige Config Seite anzeigen.

- Eine Möglichkeit ein Widget komplett auf eine Seite zu bringen wäre auch schön (ohne es in einen kleinen Block zu packen. Am PC kann ein Plot ruhig die volle Bildschirmbreite nutzen)
- Noch als Idee: die Ids der Widgets könnte man sicherlich auch automatisch generieren. (z.B. $ID durch eine fortlaufende Nummer ersetzen)

Merke ich mir mal vor und schaue demnächst mal was geht.