Aktualisierung Treiber SmartVisu

[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.