erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[herrmannj]

start mal über die cmd line und schau nach Meldungen.

vg
jörg

[mele]

start mal über die cmd line und schau nach Meldungen.

vg
jörg

Damit kann ich nichts anfangen. Beispiel? In FHEM oder Putty?

[herrmannj]

oh ha. .. log Dich mal auf dem cubi ein, geh console. Beende fhem (service fhem stop), geh in das fhem Verzeichnis (/opt/fhem ?) und starte dort fhem mit perl fhem.pl fhem.cfg.

vg
jörg

[mele]

oh ha. .. log Dich mal auf dem cubi ein, geh console. Beende fhem (service fhem stop), geh in das fhem Verzeichnis (/opt/fhem ?) und starte dort fhem mit perl fhem.pl fhem.cfg.

vg
jörg

Erledigt, danach im WebIF:

Code Auswählen Erweitern

Error messages while initializing FHEM:
configfile: Cannot load module fronthem
Cannot load module fronthemDevice

[bgewehr]

Ich hab nochmal Bernds Vorschlag weitergdacht - ich glaub das könnte funktionieren.

Ideen? Einwände? Vorschläge? Whatever ?

Ich denke die wichtige Überlegung ist Systemlast. Wenn nur die neuen Punkte im refreshzyklus übertragen werden müssen, ist das evtl günstiger als wenn jedesmal alle Daten übertragen werden müssen, erzeugt aber auf der SV Seite eine Aufgabe der Rekombination der Historie mit den neuen Daten.

Wann muss denn ein Chart aktualisiert werden? Da wir ja kein EKG haben, reicht ja ein Zyklus von 5 min, 30s oder 10s sicher immer aus, oder?

Allerdings müssten dann alle x Sekunden alle Daten neu übertragen werden, obwohl die meisten schon da sind, was unglücklich erscheint! Der Mehraufwand des Nachschiebens neuer Daten und des Löschens von alten ist aber auch nicht null.

Wie wäre es, wenn man grundsätzlich vereinbart, dass ein Chartempfänger auf der SV Seite grundsätzlich JSON Pakete empfangen kann, die 1-n Datensätze aus [X, Y1, Y2, ...] beinhalten. Beim initial fill schiebt man einmal den aktuellen Stand rüber und bei jedem scheduled refresh dann nur noch die Differenz bis jetzt. Der JS code des Charts schiebt immer nur die empfangenen Daten zusätzlich ins Chart. Das Chart hat eine definierte x-Länge, also fliegen alte Daten hinten raus. Die Daten können dabei aus derselben Quelle kommen, das ist ja egal für das Ergebnis.

Eine Aktualisierung der Charts bei jedem Datenevent kann auch deutlich zu oft sein, das würde ich gar nicht anstreben.

[HCS]

Bei dem Beispiel hast Du ja schon ein customized chart - da würde ich einen kurzen step auf die eingebauten zurückgehen wollen (erst mal)

Das würde ich nicht machen. Das endet sicher damit, dass wir das wegwerfen und doch mit einem eigenen enden.
Der Domitiga kann übrigens überhaupt keine plots ansteuern, auch die originalen von SV nicht.

Interval ist doch (richtig?) hier die kleinste Auflösung, nicht das Aktualisierungs interval.

Das ist das Intervall, in dem die Serie geschickt werden soll.
Eine Auflösung hatte ich noch gar nicht im Focus. Die stelle ich mir aber auch schwierig vor, wenn die geloggten Werte in einem unregelmäßigen zeitlichen Abstand sind.

Doch, ich schon aber vielleicht meinen wir etwas unterschiedliches. Wunsch lautet: ich hab (zB) auf meiner Seite einen plot mit temp der letzten 24h. Der läuft mit, aktualisiert sich fortlaufend.

Genau das macht meine Implementierung seit einigen Wochen. In dem Beispiel aus dem Link ist ein Chart mit Temperaturen, das immer genau die letzten zwei Tage darstellt. Alle 5 Minuten wird es aktualisiert, da schickt mein addon Treiber die komplette neue Serie rüber.

Ich hab nochmal Bernds Vorschlag weitergdacht - ich glaub das könnte funktionieren. Idee: Man gibt an um welches device/reading es sich handelt, welches logfile und wie (regex?) die Daten im logfile liegen. Fronthem öffnet das log in einem child prozess (weil evtl langsam), und liefert die Daten, file bleibt offen. Das device/reading wird überwacht (gleiche logik wie jetzt item/GAD).  Wenn ein passendes event reinkommt gebe ich dem child einen ping, der liest weiter die quelle (filelog) und schickt das an fronthem, das weiter an sv. So brauch ich nicht ständig zu pollen und die Signale werden trotzdem in realtime produziert. Im Idealfall kann aus device/reading sogar abgeleitet werden WIE das im log liegt, das wäre dann schon in etwa die Art des user comforts den ich ggern sehen würde (user braucht nicht mehr rum-regexen)

Da stellt sich die Frage: will man, dass ein Chart alle x Minuten, Stunden, .. aktualisiert wird oder will man eine Aktualisierung, sobald sich in dem zugrundeliegenden Log etwas ändert.

Wir könnten das aber auch beides realisieren. Wenn man in der Definition des Widget als Intervall anstatt einem Wert (10s, 60s, ...) "OnChange" angibt, dann könnte fronthem die Daten schicken, sobald ein neuer Wert vorliegt, im anderen Fall alle n Sekunden.

Nach meinem Verständnis sende ich initial eine Serie (geordnet über die Zeit, Auflösung min zoom size). Dann schiebe ich Daten hinterher und das plot hängt die rechts ran (und links fällt einer raus).

Mein bisheriger Plan war, dass fronthem immer die komplette Serie schickt, nicht nur initial sondern auch danach.
Bei den Highcharts fällt links erst mal nichts raus. Der Treiber müsste den Wert ganz links rausnehmen. Das ist aber nicht so einfach.
Beispiel: SV fordert eine Serie für die letzten zwei Stunden an, in FHEM gbit es aber nur Werte für die letzte Stunde. Dann müsste der Treiber erkennen, dass der Wert links nicht weg darf, weil wir noch keine zwei Stunden haben.
Da ist es viel einfacher, in fronthem einfach grundsätzlich bis max. zwei Stunden rückwärts zu holen und stumpf zu liefern und den Treiber das Chart aktualisieren zu lassen.

IWie wäre es, wenn man grundsätzlich vereinbart, dass ein Chartempfänger auf der SV Seite grundsätzlich JSON Pakete empfangen kann, die 1-n Datensätze aus [X, Y1, Y2, ...] beinhalten. Beim initial fill schiebt man einmal den aktuellen Stand rüber und bei jedem scheduled refresh dann nur noch die Differenz bis jetzt. Der JS code des Charts schiebt immer nur die empfangenen Daten zusätzlich ins Chart. Das Chart hat eine definierte x-Länge, also fliegen alte Daten hinten raus. Die Daten können dabei aus derselben Quelle kommen, das ist ja egal für das Ergebnis.

Du schreibst das immer, während ich es auch gerade schreibe 

Das Chart links zu begrenzen ist eine Sache. Das Problem ist, dass die Werte aus der Datenquelle des Chart (Array) auch raus müssen, sonst zeigt man im Chart zwar nur zwei Tage an, hat aber im Array "3 Monate" drin, was nicht lange gut geht.

Auch wenn es etwas Übertragungsoverhead ist, die stressfreiste und am wenigsten fehlerträchtigste Variante ist komplett schicken.
Mein Ölstand-Chart hat knapp 2000 Werte und aktualisiert z.Zt. testweise alle 10 Sekunden. Da merkt man nichts davon und man sieht auch nichts, da die Highcharts sehr smooth aktualisieren.

[herrmannj]

erzeugt aber auf der SV Seite eine Aufgabe der Rekombination der Historie mit den neuen Daten.

Ja, das macht der driver (soll er machen)

Wann muss denn ein Chart aktualisiert werden? Da wir ja kein EKG haben, reicht ja ein Zyklus von 5 min, 30s oder 10s sicher immer aus, oder?

Ich würde da jetzt keinen künstlichen Engpass einbauen wollen. Ob jeder Wert (event) Sinn macht läßt sich mMn nicht so pauschal beantworten.

Nehme ich den aktuellen Energieverbrauch in einer Sicht von 20min hätte ich sicher schon jeden. Mach ich das gleiche auf 14Tage - Sicht brauch ich das nicht. Generell hat so ein plot ja irgendeine Auflösung, schon rein physikalisch auf dem Screen. Die Dichte der Daten müsste sich doch dann an der Auflösung (und evtl gewünschter Zoomfähigkeit) orientieren. Dazu müsste fronthem evtl Daten verdichten (wenn der sensor schneller liefert als Datenpunkte dargestellt werden können)

Bzgl des Daten Paketes brauchen wir mMn keine "neue Vereinbarung" , die plots sind doch schon Bestandteil von sv und ich würde mich dafür aussprechend as erst einmal so zu bedienen - die Kür können wir ja danach mit eigenen widget plots machen.

vg
jörg

[bgewehr]

Nach den Erfahrungen von HCS mit den blöde angedockten Parametern in den Originalcharts würde ich auch lieber sofort eine neue Chart-widget-Serie beginnen, das ist ja nicht weniger SV- konform. Wir kriegen da sicher was hübsches hin...

[herrmannj]

Das würde ich nicht machen. Das endet sicher damit, dass wir das wegwerfen und doch mit einem eigenen enden.

Nur mal für mich zum Verständnis, woher kommen denn die Vorbehalte gegenüber den mitgelieferten plots - die sehen doch ganz charmant aus ?

Wir könnten das aber auch beides realisieren. Wenn man in der Definition des Widget als Intervall anstatt einem Wert (10s, 60s, ...) "OnChange" angibt, dann könnte fronthem die Daten schicken, sobald ein neuer Wert vorliegt, im anderen Fall alle n Sekunden.

Das hört sich gut an - check.

Das Problem ist, dass die Werte aus der Datenquelle des Chart (Array) auch raus müssen, sonst zeigt man im Chart zwar nur zwei Tage an, hat aber im Array "3 Monate" drin, was nicht lange gut geht.

Berechtigter Hinweis - das sollten wir im Auge behalten.

Mit Sicht auf die perfomance bin ich mir trotzdem sicher das es besser ist die Daten nur zu ergänzen und die alten Werte aus dem array zu nehmen. Als ich fronthem geschrieben habe wär ich auch nie auf die Idee gekommen das jemand jammert weil 600 GADs einige Sekunden brauchen 

vg
jörg

[herrmannj]

Nach den Erfahrungen von HCS mit den blöde angedockten Parametern in den Originalcharts würde ich auch lieber sofort eine neue Chart-widget-Serie beginnen, das ist ja nicht weniger SV- konform. Wir kriegen da sicher was hübsches hin...

ich hab den post verpasst, nimm mich mal mit bitte. Für mich sehen die Originale ok aus (was nicht gegen Erweiterungen spricht - das wird kommen!)

vg
jörg

[HCS]

Nach den Erfahrungen von HCS mit den blöde angedockten Parametern in den Originalcharts

Das hatte ja schon völlig verdrängt. Das geht meiner Ansicht nach gar nicht.
Um Jörg abzuholen: http://forum.fhem.de/index.php/topic,30909.msg262386/topicseen.html#msg262386

Nur mal für mich zum Verständnis, woher kommen denn die Vorbehalte gegenüber den mitgelieferten plots - die sehen doch ganz charmant aus

Ja. Nur technisch ist das nix.
Die angedockten Parameter.
Keinerlei Konfigurationsmöglichkeit
...
siehe Link oben

[HCS]

Nach den Erfahrungen von HCS mit den blöde angedockten Parametern in den Originalcharts würde ich auch lieber sofort eine neue Chart-widget-Serie beginnen, das ist ja nicht weniger SV- konform. Wir kriegen da sicher was hübsches hin...

Ich habe schon was hübsches 
Es sind eh nur zwei, die es da gibt. Den period (habe ich fertig) und den rtr, der auch ein period ist, auf dem noch ein PacMan Chart für die Ventilstellung mit drauf ist. Das kann man beides mit einem erledigen.

[herrmannj]

ok, die Parameter sind echt blöd. Ich schau mal in den anderen drivern.

Die Series (@fronthem und im driver) so gestalten das sie mit den orignal plots und custom charts laufen muss also klares Ziel sein.

vg
jörg

[HCS]

Die Series (@fronthem und im driver) so gestalten das sie mit den orignal plots und custom charts laufen muss also klares Ziel sein.

Warum?

[herrmannj]

Damit dokumentierte und beschriebene widgets (plot - out of the box) verwenden kann. Ich seh da auch kein Problem, ich habe fronthem, den driver und Du die charts im Zugriff - woran soll es scheitern ?

vg
jörg