Aktualisierung Treiber SmartVisu

[cruser1800]

Hallo,

Ich wollte mal nachfragen, wie es mit dem neuen Treiber aussieht! Können wir noch damit rechnen?

Der alte funktioniert gut, aber der neue sollte noch etwas an Geschwindigkeit bringen!

Gruß Lutz

[smai]

Können wir noch damit rechnen?

Klar, ich bin dran.
Genau genommen bin ich fertig, ich hätte aber noch gerne Feedback von @HCS (welcher den Treiber entwickelt hat). Leider habe ich keine Antwort von ihm erhalten.

Der alte funktioniert gut, aber der neue sollte noch etwas an Geschwindigkeit bringen!

Das ist beides so nicht korrekt.
Der alte Treiber läuft mit der Entwicklungsversion (aka 2.9) meines Wissens gar nicht.
Und mehr Geschwindigkeit bringt nicht der neue Treiber, sondern die smartVISU in der nächsten Version. Aber um diese mit dem FHEM-Treiber verwenden zu können, muss dieser eben erst angepasst werden.

Falls du keine spezifischen Features (wie Add-on-Treiber oder Offlinemodus) verwendest, kannst du aber die Entwicklungsversion mit dem DomotiGa-Treiber verwenden.

[HCS]

Genau genommen bin ich fertig, ich hätte aber noch gerne Feedback von @HCS (welcher den Treiber entwickelt hat). Leider habe ich keine Antwort von ihm erhalten.

Wo ist der denn?
Das hier: https://github.com/Martin-Gleiss/smartvisu/blob/master/driver/io_fhem.js
ist ja alt.

[HCS]

Aber um diese mit dem FHEM-Treiber verwenden zu können, muss dieser eben erst angepasst werden.

Was wäre wie anzupassen?

[smai]

Es lebt!

Ich habe einen extra Branch dafür gemacht: https://github.com/Martin-Gleiss/smartvisu/blob/fhem-driver/driver/io_fhem.js

Den Treiber habe ich in zwei Schritten angepasst:

• Nur den Teil mit dem Update der Widgets:
  https://github.com/Martin-Gleiss/smartvisu/commit/5f58f81633eab25ed0ef25a798a4f29464900e40#diff-f41e3ab522e0aa63211301385b132bcc
  
• Weitere lokal implementierte Funktionen auf solche von smartVISU geändert und dabei das ganze GAD-Splitting etwas umgebaut:
  https://github.com/Martin-Gleiss/smartvisu/commit/86209e7349968171ad8eea85391b32a02e883e5c#diff-f41e3ab522e0aa63211301385b132bcc
  

Der erste Schritt ist zwingend, damit der Treiber mit sV 2.9 funktioniert. Mit dem zweiten habe ich dann weitergemacht, weil ich grad so schön dran war. 

Allerdings habe ich nur eine minimale Testumgebung für FHEM, deshalb braucht das sicher weiteres debugging.
Unklar für mich und ungetestet ist vor Allem der Teil mit den Series.

Ich wollte dich auch nicht vor den Kopf stossen und deshalb das eigentlich erst "persönlich" klären. Der Treiber ist ja meines Wissens dein Baby.
Gerne können wir die Details auf Gitter besprechen, da lässt es sich etwas einfacher "real time" diskutieren.

[HCS]

OK, ich setzte mal ein SV2.9 in einer Testumgebung auf, vermutlich von hier:
https://github.com/Martin-Gleiss/smartvisu.git/branches/develop

und packe den FHEM Treiber von hier
https://github.com/Martin-Gleiss/smartvisu/blob/fhem-driver/driver/io_fhem.js
dazu

und schaue mal, was meine Page, die auf 2.8 problemlos läuft, dann macht.

Korrekt?

[HCS]

Und warum heißt der Thread eigentlich "Aktualisierung fronthem"?
Da wird genau nichts in fronthem aktualisiert.

[smai]

Korrekt?

Genau, danke.

Und warum heißt der Thread eigentlich "Aktualisierung fronthem"?
Da wird genau nichts in fronthem aktualisiert.

Das habe ich auch schon gedacht.

[cruser1800]

Klar, ich bin dran.
Genau genommen bin ich fertig, ich hätte aber noch gerne Feedback von @HCS (welcher den Treiber entwickelt hat). Leider habe ich keine Antwort von ihm erhalten.
Das ist beides so nicht korrekt.
Der alte Treiber läuft mit der Entwicklungsversion (aka 2.9) meines Wissens gar nicht.
Und mehr Geschwindigkeit bringt nicht der neue Treiber, sondern die smartVISU in der nächsten Version. Aber um diese mit dem FHEM-Treiber verwenden zu können, muss dieser eben erst angepasst werden.

Falls du keine spezifischen Features (wie Add-on-Treiber oder Offlinemodus) verwendest, kannst du aber die Entwicklungsversion mit dem DomotiGa-Treiber verwenden.

Also bei mir läuft die 2.9 Smartvisu auch mit dem alten Treiber sehr gut! Habe Ihn seit ca. 2 Monaten im EInsatz!

Aber ich teste mal den neuen!

Danke für die Weiterentwicklung!

[smai]

Das überrascht mich, aber ich kann es nicht ausschliessen, getester habe ich es nicht.
Hast du einen aktuellen Pull? Ich hätte gedacht, dass der Treiber nach den Änderungen vom 9. November 2017 nicht mehr funktioniert hat.

Aber so oder so wäre der Datenfluss und die Performance nicht optimal.

[herrmannj]

Der angepasste driver hatte ein fallback falls er die widgets im Dom nicht findet. Der könnte schon laufen.

[HCS]

Habe eine 2.9 eingerichtet und meine page draufgepackt.

Das passt noch nicht so ganz, wobei ein Teil nichts mit dem Treiber zu tun hat.
Angehängt der Vergleich 2.8/2.9

- die Buttons oben passen von der Größe nicht mehr
- das   rechts wurde nicht aufgelöst
- Probleme mit den Charts

Zu den Charts muss ich etwas ausholen:
Da fronthem (leider bis jetzt immer noch) keine Daten für plots liefern kann, hatte ich damals die add on driver Sache erfunden, um auf anderem Weg Daten für plots in das System einzuspeisen, ohne komplett an den SV-Mechanismen vorbei zu arbeiten.

Code Auswählen Erweitern

gadFilter: "^hcs.data.", // reg ex, to hide these GADs to FHEM
addonDriverFile: "io_hcs.js", // file name of an optional add-on driver

Das funktioniert scheinbar noch.
Das chart.period-widget, mit dem ich das plot.period-widget von SV ersetzt habe, funktioniert überhaupt nicht mehr, ist aber evtl. nicht schlimm, wenn das plot.period-widget es hinbekommt (was nicht der Fall ist, siehe unten)

Darum habe ich dann auf das original SV plot.period-widget zurückgerudert und bekomme damit auch zumindest irgend welche Kurven (siehe angehängte plot.png)
Allerdings sieht es etwas seltsam aus und es verhält sich auch seltsam, siehe angehänge plot_nach_einiger_zeit.png

Ich kann mich schon gar nicht mehr recht erinnern, weil das schon so lange her ist, aber ich glaube, dass ich in meinem chart.period-widget etwas gemacht hatte, dass die Aktualisierung funktioniert, egal ob nur ein weiterer Punkt oder das komplette chart nochmal kommt.

Ich werde jetzt wohl in die Forschungsphase eintreten müssen ...

[HCS]

Ohh, mein sebstgebautes shutter widget funktioniert auch nicht mehr richtig.
Fahren lassen geht, Zustand nicht.
Hat aber vermutlich auch nichts mit dem Treiber zu tun.
Gibt es einen generellen Hinweis, was man in eigenen widgets für die 2.9 anpassen muss?

[smai]

Danke für das Feedback

die Buttons oben passen von der Größe nicht mehr

Dies überrascht mich, weil ich davon das erste mal höre. Wie sieht dein Code davon genau aus?
Grundsätzlich kann es Abweichungen der Darstellung kommen, weil in 2.9 jQuery Mobile auf 1.4.5 migriert wurde. Dieses hat ein komplett neues CSS und erstellt an vielen Stellen andere (einfachere) HTML-Strukturen, wodurch alte CSS-Regeln nicht mehr passen.

das   rechts wurde nicht aufgelöst

Das ist Feature und nicht Bug.  Früher gab es kein HTML encoding in Widgets wie basic.formula und basic.value, was aber meist nicht so gewollt war.
Du kannst alternativ basic.print mit format=html verwenden oder den no-breaking Space direkt als UTF-8 Zeichen anstatt als HTML-Entität eingeben.

Probleme mit den Charts

Ich hatte schon befürchtet, dass dies am meisten Probleme macht.
Kannst du mir den add-on Treiber zeigen bzw. die Daten, welcher dieser liefert?

Ohh, mein sebstgebautes shutter widget funktioniert auch nicht mehr richtig.
Fahren lassen geht, Zustand nicht.

Kannst du mir den Code des Widgets zeigen?

Gibt es einen generellen Hinweis, was man in eigenen widgets für die 2.9 anpassen muss?

Die Widgets sollten prinzipiell weiter funktionieren.

Damit die Performanceverbesserung voll zur Geltung kommt, müssen Widgets mit eigenem JavaScript umgebaut werden. Die neue Struktur ist aber noch nicht dokumentiert, weil sie bis vor Kurzem noch nicht definitiv war.
Aber das gilt nur für solche mit eigenem Script bzw. genauer gesagt einem change event. Und auch die alte Struktur funktioniert noch, halt einfach nicht beschleunigt.

[HCS]

Dies überrascht mich, weil ich davon das erste mal höre. Wie sieht dein Code davon genau aus?

Ursprünglich so, was in 2.8 das Ergebnis aus der hardcopy ergab

Code Auswählen Erweitern

  <a class="ui-btn ui-corner-all" id="menu-overview" data-ajax="true" href="index.php?page=page_overview">
    <img class="icon" src="{{ page == 'page_overview' ? icon1 : icon0 }}control_building_empty.svg"/>
  </a>

Jetzt so, damit passt es wieder.

Code Auswählen Erweitern

  <a id="menu-overview" data-ajax="true" href="index.php?page=page_overview">
    <img class="icon" src="{{ page == 'page_overview' ? icon1 : icon0 }}control_building_empty.svg"/>
  </a>

Wobei ich mich jetzt auch gerade wundere, warum es mit der ursprüngliche Variante in 2.8 nicht ein Button wurde.

Das ist Feature und nicht Bug.  Früher gab es kein HTML encoding in Widgets wie basic.formula und basic.value, was aber meist nicht so gewollt war.
Du kannst alternativ basic.print mit format=html verwenden oder den no-breaking Space direkt als UTF-8 Zeichen anstatt als HTML-Entität eingeben.

Ja, das war einfach zu lösen, wusste nur nicht, ob es der Plan war.

Kannst du mir den add-on Treiber zeigen bzw. die Daten, welcher dieser liefert?
Kannst du mir den Code des Widgets zeigen?
Die Widgets sollten prinzipiell weiter funktionieren.

addon-Treiber usw. funktioniert, die Daten kommen auch korrekt ins widget rein.
Wenn ich das 2.9er plot.period nehme, kommen auch Kurven, nur klappt die Aktualisierung nicht, weil ich immer alle Werte komplett neu schicke.
Ich habe gerade begonnen, mein chart.period (mein bisher in 2.8 persönlicher Ersatz vom plot.period) umzuschreiben.

Damit die Performanceverbesserung voll zur Geltung kommt, müssen Widgets mit eigenem JavaScript umgebaut werden. Die neue Struktur ist aber noch nicht dokumentiert, weil sie bis vor Kurzem noch nicht definitiv war.
Aber das gilt nur für solche mit eigenem Script bzw. genauer gesagt einem change event. Und auch die alte Struktur funktioniert noch, halt einfach nicht beschleunigt.

Ja, das schaue ich mir gerade an einigen 2.9er widgets ab, wie das geht.