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.

[smai]

Vielleicht kann ich das auch im integrierten Plot handeln.
Man könnte z.B. bereits vorhandene Datenpunkte einfach ignorieren.

[HCS]

Vielleicht kann ich das auch im integrierten Plot handeln.
Man könnte z.B. bereits vorhandene Datenpunkte einfach ignorieren.

Das wäre cool. Dann bräuchte ich meinen chart.priod nicht mehr.
Aber ich glaube, nur anhängen ist auch nicht optimal, das werden sonst immer mehr Daten, oder?

Bislang sehe ich aber kein Problem in dem 2.9er Treiber.
Gib mir mal etwas Zeit, ich muss jetzt erst mal die Page komplett zum Laufen bekommen, die widgets auf "$.widget(" umbauen und dann schaue ich mir die plots an und versuche zu ermitteln, was ich in meinem chart.period alles anders mache als der plot.period.
Dann kannst Du überlegen, ob Du dafür was einbaust.

Und in den Treiber muss ich dann auch mal endlich rein schauen 

[HCS]

Die page habe ich jetzt in 2.9 komplett "modernisiert" und laufen, außer die charts.

- meine widgets nach <page>/widgets geschoben
- alle auf jQuery widgets umgestellt
- die deprecated (basic.value usw.) umgestellt
- einigen optische Feinheiten gerichtet

Das läuft mit dem 2.9er Treiber so weit problemlos.

Nur die charts machen noch Probleme.
Inzwischen bin ich auch wieder dahinter gekommen, was die Hauptgründe waren, charts.period als Ersatz für plot.period zu schreiben und mit dem FHEM-Treiber entsprechend zu versorgen:

keine Aktualisierung mit kompletten Serien
plot.period akzeptiert zur Aktualisierung kein erneutes Senden der kompletten Serie

Aktualiserung nur wenn alle Serien vorliegen
Die Serien werden (wie für alle Widgets) gesammelt, bis sie für alle GADs im Widget vorliegen, erst dann wird der chart aufgebaut.
Da ich die Daten für manche Serien verzögert oder manchmal gar nicht bekomme, habe ich dann gar kein chart.
Ob dieses Vorgehen, das bei anderen Widgets, die darauf angewiesen sind, alle Daten zu habe, um korrekt zu arbeiten,
durchaus Sinn macht, bei den charts auch so sein muss, wäre zu überlegen.

Konfiguration des highchart
Ich wollte eine Konfiguration für das highchart in das widget rein schicken können.
Ein Beispiel dafür kann man hier sehen: https://github.com/herrmannj/smartvisu-widgets/tree/master/chart

Und es gab noch ein paar Kleinigkeiten, wie z.B. ein class parameter im widget, um verschiedene charts unterschiedlich stylen zu können.

Also habe ich versucht, mein chart.period wieder zum Laufen zu bekommen, aber das geht nur mit einer Änderung im Treiber (dass er ausschließlich bezüglich chart.* wieder wie meine ursprüngliche Version arbeitet), die ich nicht hinbekommen habe.

io_fhem.js ab Zeile 258

Code Auswählen Erweitern

        for (i = 0; i < data.items.length; i++) {
          var item = data.items[i];
         
          // FHEM charts, see https://github.com/herrmannj/smartvisu-widgets/tree/master/chart
          var seriesdata = {
            "gad": item.gad,
            "data": item.plotdata,
            "updatemode": item.updatemode
          }
         
// <LOOK HERE>         
          //// can not use this: widget.update(item.gad, seriesdata);
          // Here I would like to call something that directly calls the _update of the widget
          // without using the "collect GAD values logic" and so on
          // something like: widget.directUpdate(seriesdata);
// </LOOK HERE>

         
          // sV plots


"<LOOK HERE>" ist die interessante Stelle.
Hier würde ich gerne etwas aufrufen, das direkt die _update vom widget aufruft, ohne dass da noch irgend eine SV-Logik eingreift, sammelt oder sonst was macht.
Wenn das irgendwie geht, bekomme ich meinen chart.period wieder zum Laufen.

Den Teil drunter, der auf "plot." widgets ausgerichtet ist, kann man vermutlich schlicht vergessen, weil mein add-on-Treiber dafür nichts liefert und fronthem eh keine Daten für charts oder plots liefert. somit gibt es eigentlich nichts, was diese Schiene bedient.

[dev0]

Darf ich an dieser Stelle einmal fragen wo der Grund liegt, warum die SV-Graph-Widgets mit historischen Werten nicht funktionieren und wir (die Fronthem-User) bisher auf ein einziges DbLog Widget Widget angewiesen sind? Ist die Ursache im Fronthem Design generell zu finden oder könnte ein erweiterter Treiber das Problem lösen?
Falls es der Treiber ist: wäre jemand bereit diese Funktionalität einzubauen?

[herrmannj]

ja, fronthem hat keinen reader für logfiles.

Das fhem log system ist nicht besonders schön, daher die Anbindung via DBLog. Geplant ist es aber das einzubauen, wer mag kann gern

[HCS]

@smai: Ich habe die page nun komplett laufen, das chart widget habe ich auch wieder in den Griff bekommen.
Dazu habe ich den Treiber (angehängt) angepasst.
Außerdem habe ich ihn etwas ausgemistet und bereinigt.

Kannst Du ihn in den develop branch (https://github.com/Martin-Gleiss/smartvisu/blob/develop/driver/io_fhem.js) packen, dass FHEM-User, die die 2.9 testen wollen, die aktuelle Version testen?

Wenn Du den fhem-driver branch nur wegen dem FHEM-Treiber gemacht hast, kannst Du ihn eigentlich wegkippen (https://github.com/Martin-Gleiss/smartvisu/tree/fhem-driver)
Es sei denn, Du brauchst ihn für irgend was, ich brauche ihn nicht.

Muss noch ein wenig testen, aber mit den umgebauten widgets sieht das gut und schnell aus.

Edit1: neue Version vom Treiber angehängt (fix crash wenn kein addon on treiber vorhanden)
Edit2: aktueller Treiber hängt an einem späteren Post

[raman]

Hallo,

ich habe den überarbeiteten Treiber mal kurz angetestet.

Bei mir endet das Laden mit einem Fehler in Zeile 391 io.addon is null.
Da ich keinen Addon-Treiber nutze, ist "io.addon" immer null und alle Abfragen
von "io.addon.gadFilter" führen  bei mir zu einem Fehler.

Gruß
R.

[HCS]

Habe am vorhergehenden Thread eine neue Version angehängt, probier damit mal bitte.

[smai]

Du warst zu schnell für mich. 

Ich hatte schon folgende Antwort vorbereitet:

Vielen Dank HCS für das ausführliche Feedback.

Davon inspiriert habe ich alle Plots so umgebaut, dass sie bereits beim create erstellt werden und danach mit einzelnen Serien gefüttert werden können.
Zusätzlich werden bestehende Punkte verglichen und aktualisiert.

Damit sollten deine ersten beiden Punkte erledigt sein.

Die Plots im develop verwenden übrigens den neuen styled mode von Highcharts.
Dadurch lassen sich u.A. Farben und Schrift per CSS definieren und müssen nicht mehr über Chart Options gesetzt werden.
Und anstelle des class-Parameters kannst du im CSS auch die ID verwenden oder dem darüber liegenden Container eine Klasse geben.

Wenn die Chart Options aber ein grosses Bedürfnis sind, kann ich diese auch in plot.period einbauen.
Ich hatte mir das früher bereits einmal angeschaut und mich dagegen entschieden, weil für viele User die Plots jetzt schon zu kompliziert sind und mit den Chart Options die Verwirrung noch grösser wird.

Ich hatte das nur noch nicht gepostet, weil ich noch an den letzten Details der Plot-Aktualisierung feile und deshalb noch nicht committed habe.

Den Treiber werde ich gerne übernehmen und den Branch löschen.

[raman]

@HCS: Funktioniert jetzt!

Eine Kleinigkeit, die mir noch aufgefallen ist:

Vor io.monitor(); in Zeile 124 muss noch ein widget.refresh();
Sonst wird beim Seitenwechsel z.B. für basic.symbol der aktuelle Zustand
nicht richtig angezeigt.

[HCS]

Vor io.monitor(); in Zeile 124 muss noch ein widget.refresh();
Sonst wird beim Seitenwechsel z.B. für basic.symbol der aktuelle Zustand
nicht richtig angezeigt.

Korrekt. Habe es eingebaut, anbei die neue Version vom Treiber.

Da ich nicht alle (aber viele) widgets verwende: hast Du UZSU in Benutzung und funktioniert das?

@smai: falls Du den Treiber schon oben geholt hattest, dann bitte nochmal von hier.

Edit: Treiber entfernt, die aktuelle Version ist hier: https://github.com/Martin-Gleiss/smartvisu/blob/develop/driver/io_fhem.js

[HCS]

Du warst zu schnell für mich. 

Macht nichts, ich habe die page incl. charts.period in 2.9 laufen, sie evtl. mit plot.period zu ersetzen ist dann die Kür.

Zusätzlich werden bestehende Punkte verglichen und aktualisiert.

Ich glaube, dass das noch nicht ganz zu meinem use case passt.
Meine Datenquelle schickt immer die kompletten Serien, das ist ein sich vorwärts bewegendes Zeitfenster von zwei Tagen.
Somit legt praktisch sie fest, was angezeigt wird.
Ein Ergänzen der schon vorhandenen Serien würde doch dazu führen, dass die Seriendaten in SV im Lauf von Tagen oder Wochen immer mehr werden?

Die Plots im develop verwenden übrigens den neuen styled mode von Highcharts.

Ja, ich habe das Setzen der Farben in meinem chart.period auf das programmatische Setzen der styles umgebaut, so wie es in plot.period gemacht wird.

Wenn die Chart Options aber ein grosses Bedürfnis sind, kann ich diese auch in plot.period einbauen.

Für mich ist es ein großes Bedürfnis, wie sehr es die Menschheit generell braucht, vermag ich nicht zu schätzen.
Aber es eröffnet einem die wirkliche Macht über das Aussehen und Verhalten der Charts.
Da es optional ist, muss es sich ja nicht jeder antun.

Ich hatte das nur noch nicht gepostet, weil ich noch an den letzten Details der Plot-Aktualisierung feile und deshalb noch nicht committed habe.

Wenn es im develop branch angekommen ist, schaue ich mal, ob ich meinen chart.period damit ablösen kann.

[raman]

@HCS: UZSU funktioniert bei mir!

[smai]

Ich habe meine Plots nun committed (noch ohne Plot Options, diese werde ich noch einbauen).
Meine Änderungen am Treiber habe ich gemerged und den Branch gelöscht.

Deine Änderungen habe ich noch nicht rein genommen. Ich fände es besser, wenn du diese auf GitHub als Pull Request einstellst. So bist du als Autor ersichtlich. (Und ich habe noch zwei kleine Punkte, die ich da dann anmerken könnte).
Die Änderungen finde ich übrigens sehr sinnvoll. Damit muss nicht mehr die Treiber-Datei editiert werden, um ein Addon zu verwenden.
Und für die entfernten offline Daten gibt es ja einen eigenen Treiber. Die Logik in deinem war aber etwas ausgeklügelter, evtl. werde ich noch etwas davon in den Offlinetreiber übernehmen.

Meine Datenquelle schickt immer die kompletten Serien, das ist ein sich vorwärts bewegendes Zeitfenster von zwei Tagen.
Somit legt praktisch sie fest, was angezeigt wird.
Ein Ergänzen der schon vorhandenen Serien würde doch dazu führen, dass die Seriendaten in SV im Lauf von Tagen oder Wochen immer mehr werden?

In plot.period wird die Anzahl anzuzeigender Datenpunkte definiert. Werden es mehr, fliegen die ältesten beim update raus.
Die ebenfalls angegebene Periode hingegen wird aktuell nur an den Treiber weitergegeben. Korrekterweise sollte diese eigentlich auch noch in der update-Methode geprüft werden.

Eine Diskrepanz gibt es wohl noch:
plot.period ergänzt das Item (ihr nennt das meines Wissens GAD) um die Angaben zu Aggregatsfunktion, Zeitbereich und Anzahl.
Ein einfaches widget.update() mit der GAD ohne diese Angaben funktioniert also nicht. Wenn ich es richtig verstanden habe, liefert dein Addon-Treiber das aber nur so.

[HCS]

Deine Änderungen habe ich noch nicht rein genommen. Ich fände es besser, wenn du diese auf GitHub als Pull Request einstellst. So bist du als Autor ersichtlich. (Und ich habe noch zwei kleine Punkte, die ich da dann anmerken könnte).

Ich befürchte, dass ich das nicht hinbekomme. Ich verwende eigentlich kein GitHub (habe hier alles in SVN repositories) und habe keine Ahnung, wie ich da einen Pull Request draus mache. Kannst Du den Treiber nicht einfach als komplette Beistellung von FHEM betrachten?
So war es früher ja auch mal.
Die zwei kleinen Punkte könntest Du aber so oder so schon mal anmerken.

Die Änderungen finde ich übrigens sehr sinnvoll. Damit muss nicht mehr die Treiber-Datei editiert werden, um ein Addon zu verwenden.

Ja, ich arbeite gerade (auch mit meiner Page) darauf hin, dass man an der SV-Installation genau nichts anpassen oder ergänzen muss.
AddOn-Treiber nach page/js werfen und schon läuft er.
Ich glaube, dass ich nur noch das "icons"-Thema habe, weil ich noch smartvisu/icons/or und smartvisu/icons/gn verwende, aber das Thema frage ich wohl besser mal KNX/smartVISU Forum, wie ich die in der page unterbringe.

In plot.period wird die Anzahl anzuzeigender Datenpunkte definiert. Werden es mehr, fliegen die ältesten beim update raus.
Die ebenfalls angegebene Periode hingegen wird aktuell nur an den Treiber weitergegeben. Korrekterweise sollte diese eigentlich auch noch in der update-Methode geprüft werden.

Sollte nicht ausschließlich die Periode relevant sein?
Wieviele Datenpunkte kommen werden und ich haben will/sollte, ist eigentlich nicht vorhersehbar.

ihr nennt das meines Wissens GAD

So wurde (oder wird noch?) das damals in SV genannt.

This is the interactive and online smartVISU documentation. Here you will find the API to all widgets, some design modules and the icons and backgrounds. Use the widgets in your html-pages, the number is not limited, but each widget needs it's own and unique identifier (id) on a page. The gad/s or item/s may be used as often as you need them. Mention that each driver has it's own format of the gad/s or item/s.

Wir haben damals sogar gerätselt, wofür GAD wohl steht 
Aber vielleicht kanst Du uns ja zum Thema gad/item etwas erhellen.

Elot.period ergänzt das Item (ihr nennt das meines Wissens GAD) um die Angaben zu Aggregatsfunktion, Zeitbereich und Anzahl.
Ein einfaches widget.update() mit der GAD ohne diese Angaben funktioniert also nicht. Wenn ich es richtig verstanden habe, liefert dein Addon-Treiber das aber nur so.

Ja, das GAD (oder item?) wird in FHEM (komplett wie es ankommt) als Identifikation für eine Information verwendet und in einem Konfigurator wird ihm ein Reading in FHEM zugewiesen. Da fand ich es unpraktisch, dass Konfig-Informationen (Aggregatsfunktion, Zeitbereich und Anzahl, ...) Bestandteil davon sind, da die nichts daran ändern, um welche Information es sich handelt, es aber, wenn man sie in SV ändert, zu einem anderen GAD wird.

Zu dem ganzen "plot-Thema" muss ich aber anmerken, dass man aktuell von fronthem überhaupt keine plot-Daten bekommt (ich hoffe immer noch, dass das noch kommt), das funktioniert momentan ausschließlich über einen add on Treiber, in dem man etwas implementiert, das die Daten besorgt.
Aber hier gilt das auch.

[herrmannj]

Für können das ja offiziell von GAD nach ITEM umbenennen.

[smai]

Für können das ja offiziell von GAD nach ITEM umbenennen.

Das fände ich sehr sinnvoll, denn etwa die Hälfte der Zeit für die Treiberanpassung hatte ich gebraucht, um die Variablennamen zu begreifen. 
GAD kommt von KNX und heisst Group ADdress. Das gilt in der smartVISU also, wenn man knxd bzw. eibd direkt als Backend verwendet.
Unterdessen habe ich auch aus Doku und Widgets alle GAD rausgeschmissen, die ich gefunden habe.
Item heisst es z.B. in SmartHomeNG/py. Dieser Begriff ist aber IMHO recht allgemein und deshalb passender.

Wenn ich es richtig verstanden habe, wird hier Item oft  für etwas verwendet, dass ich Widgetinstanz nennen würde (also ein auf einer Page verwendetes Widget).

Ich befürchte, dass ich das nicht hinbekomme. Ich verwende eigentlich kein GitHub (habe hier alles in SVN repositories) und habe keine Ahnung, wie ich da einen Pull Request draus mache. Kannst Du den Treiber nicht einfach als komplette Beistellung von FHEM betrachten.

Klar, kann ich machen. Aber eine einzelne Datei kannst du auf GitHub auch einfach im Webinterface editieren und gleich mit einem Klick als PR einreichen (ohne irgendwie git verwenden zu müssen).

Die zwei kleinen Punkte könntest Du aber so oder so schon mal anmerken.

Es sind nur zwei eher theoretische Performanceverbesserungen:
Das eine ist auf Zeile 232 und 233:
Diese könntest du so schreiben:

Code Auswählen Erweitern

          $.mobile.activePage.find('[data-item*="' + item.gad + '"][data-widget*='chart.']")

Entgegen dem Filter wird damit nicht zwei mal iteriert.

Und damit das Regex zum Splitten nicht mehrmals gebildet werden muss, könntest du das auf Zeile 338 hoch ziehen:

Code Auswählen Erweitern


              if (io.addon && io.addon.gadFilter) {
                var re = new RegExp(io.addon.gadFilter);

Die Zeilen 394-403 könnten dann auf folgendes reduziert werden (und ähnlich bei normalen Werten, Plots und Charts).

Code Auswählen Erweitern


              if (re && re.test(plotInfo.gad)) {
                io.ownSeries.push(plotInfo);
              } else {
                io.fhemSeries.push(plotInfo);
              }


Sollte nicht ausschließlich die Periode relevant sein?
Wieviele Datenpunkte kommen werden und ich haben will/sollte, ist eigentlich nicht vorhersehbar.

Da die Daten nicht in der smartVISU aggregiert werden, sondern der "Lieferant" dies tun muss, ist dies schon relevant.
Wenn ich z.B. eine Serie mit AVG und 24 Datenpunkte in den letzten 24h abfrage, gibt das andere Werte als die gleichen Logdaten desselben Items mit MAX und 30 Datenpunkten in 30 Tagen.
Damit die beiden Plots dann nicht mit denselben Daten gefüttert werden, wird das Item intern eben um diese Angaben ergänzt und so differenziert.

[HCS]

Wow, ich glaube dass ich es hinbekommen habe 
https://github.com/Martin-Gleiss/smartvisu/pull/200

Ich werde dann mal noch alles "gad" im Treiber in "item" umbenennen.
Und die oben vorgeschlagene Optimierung einbauen.

[smai]

Danke. Soll ich mergen oder auf die Änderungen warten?

[HCS]

Mergen. Ich mache dann für die weiteren Änderungen jeweils einen eigenen pull request.

Ich habe es übrigens gerade gewagt und die 2.9 auf das Produktivsystem geschoben (OK, mit fallback falls es ernst wird)
Anders merkt man sonst nie, ob es wirklich funktionert 

[HCS]

Für können das ja offiziell von GAD nach ITEM umbenennen.

Ich habe meinen Teil erledigt: https://github.com/Martin-Gleiss/smartvisu/pull/202
Mein Vorschlag wäre Item anstatt ITEM.

[herrmannj]

mach ich.

[raman]

Hallo,
ich habe folgendes mal zum Anlass genommen und stelle der Allgemeinheit meine angepasste Version
von fronthem zum Testen zur Verfügung zu stellen.

ja, fronthem hat keinen reader für logfiles.

Das fhem log system ist nicht besonders schön, daher die Anbindung via DBLog. Geplant ist es aber das einzubauen, wer mag kann gern

Alles Weitere im folgenden Thema
https://forum.fhem.de/index.php/topic,86584.msg790077.html#msg790077

Gruß
R.

[Chris46]

Ich habe den neuen Treiber noch nicht getestet, da meine Testinstanz aktuell bei einem Kollegen läuft und ich am Produktivsystem noch nicht basteln wollte. Hat jemand getestet, ob die dynamischen Icons von SmartVISU mit dem neuen Treiber funktionieren? Mit dem alten FHEM Treiber gehen diese bei mir leider nicht. Damit diese funktionieren musste ich leider auf den Domotiga Treiber umstellen.

[smai]

Getestet habe ich es selbst nicht, aber ich sehe keinen Grund mehr, dass diese nicht funktionieren sollten.
Soweit ich weiss hat @HCS dynamische Icons getestet.

[cruser1800]

Ich habe den neuen Treiber noch nicht getestet, da meine Testinstanz aktuell bei einem Kollegen läuft und ich am Produktivsystem noch nicht basteln wollte. Hat jemand getestet, ob die dynamischen Icons von SmartVISU mit dem neuen Treiber funktionieren? Mit dem alten FHEM Treiber gehen diese bei mir leider nicht. Damit diese funktionieren musste ich leider auf den Domotiga Treiber umstellen.

Ich habe es mal gestestet. Bei mir laufen diese nicht! Zum Bsp. Windrose. Steht immer auf der selben Stelle!

[smai]

Was sendest du denn für Werte?

[cruser1800]

Ich habe eine Wetterstastion und sende das reading windDirection.

Funktioniert beim anderen treiber ohne Probleme. Das gleiche habe ich auch beim shutter festgestellt. Also gehe ich davon aus, dass es etwas mit den Dynamic Icons zu tun haben muss.

[Chris46]

Danke fürs testen. Also leider noch das gleiche Problem wie bisher. Ich habe auch schon nachgeforscht warum das mit dem FHEM Treiber nicht funktioniert, leider reichen allerdings meine Kenntnisse nicht aus, um festzustellen wo es da im Treiber hakt. Aber sowohl mit dem Domotiga Treiber sowie "offline" funktionieren diese.

EDIT: Mit dem alten Treiber habe ich einen Slider von 0 - 255 verwendet sowie einen 0/1 Switch. Beides dann in smartVISU mit basic.switch und basic.slider eingebunden. Beides funktioniert, das dynamische icon (icon.ventilation) bewegt sich nicht.

[cruser1800]

Hallo funktioniert auch mit basic.shifter nicht! (Bei den Jalousien)

Vielleicht hilft es!

[HCS]

Ich habe auf meiner page icon.windrose, icon.windsock und icon.graph
Alle drei funktionieren. Siehe Anhang.
Die Daten kommen von einer in FHEM eingebundenen Wetterstation WS1600.

Das hat bei mir aber auch schon in SV 2.8 mit dem 2.8er FHEM-Treiber funktioniert.

Eingebunden so:

Code Auswählen Erweitern

{{ icon.windrose('ws1600.windrose', '', 'WS1600.windDirection', 0, 360) }}
{{ icon.windsock('ws1600.windsock', '', 'WS1600.windSpeed', 0, 50) }}
{{ icon.graph('ws1600.windspeed1, '', 'WS1600.windSpeed', 0, 50) }}
{{ basic.print("ws1600.windspeed2", "WS1600.windSpeed", "km/h") }}

Zuordnung in fronthem:

Code Auswählen Erweitern

item: WS1600.windDirection
mode: item
device: WS1600
reading: windDirectionDegree
converter: Direct

Code Auswählen Erweitern

item: WS1600.windSpeed
mode: item
device: WS1600
reading: windGustKMH
converter: Direct

Und hier das device in FHEM (auf das Wesentliche gekürzt)

Code Auswählen Erweitern

Internals:
   NAME       WS1600
   READINGS:
     2018-04-05 09:04:30   battery         ok
     2018-04-05 09:04:30   humidity        74
     2018-04-05 09:04:30   rain            613
     2018-04-05 09:04:30   temperature     10.6
     2018-04-05 09:04:30   windDirectionDegree 292.5
     2018-04-05 09:04:30   windDirectionText WNW
     2018-04-05 09:04:26   windGust        4.2
     2018-04-05 09:04:30   windGustKMH     15.12
     2018-04-05 09:04:30   windSpeed       2.8
     2018-04-05 09:04:30   windSpeedKMH    10.08
Attributes:
   userReadings windSpeedKMH { ReadingsVal("WS1600","windSpeed",0) eq "---" ? ReadingsVal("WS1600","windSpeed",0) : (ReadingsVal("WS1600","windSpeed",0) * 3600 / 1000) }, windGustKMH { ReadingsVal("WS1600","windGust",0) eq "---" ? ReadingsVal("WS1600","windGust",0) : (ReadingsVal("WS1600","windGust",0) * 3600 / 1000) }

[smai]

@Chris46 Die animierten Icons wie icon.ventilation laufen in vielen Browsern nicht so richtig, funktionieren denn andere Icons?
Du verwendest schon den aktuellsten Treiber von https://github.com/Martin-Gleiss/smartvisu/blob/develop/driver/io_fhem.js, welchen HCS oben angehängt hat?

[raman]

Dass die Icons funktionieren, kann ich für mich bestätigen!
Habe auch testweise "basic.shifter" mal eingebaut, und auch
die gehen bei mir! Getestet mit Firefox und Chrome auf PC und Android.
Auch das "icon.ventilation" funktioniert!

@smai: Könnte man für die Config-Page bei den Treibereinstellungen die Vorgabe des Ports für FHEM noch einbauen?
            Standard ist wie bei Domotiga Port 2121.

[HCS]

... welchen HCS oben angehängt hat?

Guter Hinweis, der ist auch nicht mehr aktuell, drum habe ich ihn an dem Beitrag oben weggenommen.

Die aktuelle Version ist hier: https://github.com/Martin-Gleiss/smartvisu/blob/develop/driver/io_fhem.js

@smai: Könnte man für die Config-Page bei den Treibereinstellungen die Vorgabe des Ports für FHEM noch einbauen?
            Standard ist wie bei Domotiga Port 2121.

Ich vermute, das ist einfach nur ein

Code Auswählen Erweitern

* @default driver_port 2121
Da ich eh noch die Treiber-Version mit Deinen Änderungen für fronthem-plot als pull request einwerfen muss, kann ich das gleich mit einbauen.

[smai]

Ich vermute, das ist einfach nur ein

Code Auswählen Erweitern

* @default driver_port 2121
Da ich eh noch die Treiber-Version mit Deinen Änderungen für fronthem-plot als pull request einwerfen muss, kann ich das gleich mit einbauen.

Richtig.
Im Infotext beim Fragezeichen rechts werde ich das auch noch anpassen.

[Chris46]

Die unterschiedlichen Aussagen haben mir nun keine Ruhe gelassen sodass ich den neuen Treiber von hier: https://github.com/Martin-Gleiss/smartvisu/blob/develop/driver/io_fhem.js nun auf meinem produktiv System mit smartVISU 2.8 getestet habe. Und die dynamischen Icons funktionieren einwandfrei. Danke dafür! Mit der Version 1.10 vom FHEM Treiber haben diese bei mir definitiv nicht funktioniert. Soweit läuft mit dem neuen Treiber auch alles andere, was mit dem "alten" Treiber auch funktioniert hat.

[cruser1800]

Also auf 2.8 funktioniert bei mir auch alles!

Ich teste auf 2.9. Hier habe ich jetzt festgestellt, dass ein alter io.fhem.min.js die Windrose korrekt darstellt. Bei den neuen Treibern funktioniert es nicht und das Symbol wird auf in der eingestellten Farbe dargestellt. (bei mir Grün)

In dem Fall wo es funktioniert bleibt das Symbol weis und dreht sich in die richtige Richtung!

Ich habe aber keine Ahnung von der Programmierung, um den Fehler zu finden!

[HCS]

Richtig.

OK, ist raus: https://github.com/Martin-Gleiss/smartvisu/pull/204

Ich teste auf 2.9. Hier habe ich jetzt festgestellt, dass ein alter io.fhem.min.js die Windrose korrekt darstellt. Bei den neuen Treibern funktioniert es nicht und das Symbol wird auf in der eingestellten Farbe dargestellt. (bei mir Grün)

Stell mal sicher, dass deine SV2.9 Installation mindestens neuer als dieser commit ist:
https://github.com/Martin-Gleiss/smartvisu/commit/7d58da9b9f7eec9a2091cb4aee382678b470d6e8
Da gab es nämlich mal kurzzeitig ein icon.xxx Problem.

[cruser1800]

Stell mal sicher, dass deine SV2.9 Installation mindestens neuer als dieser commit ist:
https://github.com/Martin-Gleiss/smartvisu/commit/7d58da9b9f7eec9a2091cb4aee382678b470d6e8
Da gab es nämlich mal kurzzeitig ein icon.xxx Problem.

Danke das war das Problem! Jetzt ist alles wieder OK!