SmartVISU + fronthem - Plotübergabe (gelöst)

[Johann.S]

Wenn du die smartVISU Seiten meinst, die stehen im Post ganz am Anfang.

Code Auswählen Erweitern

{{ plot.period('', 'ws.windspeed.plot', 'raw', '47h', now, 0, 20, 100, 'Windgeschwindigkeit', '#a00', 'spline', ['raw 47h', 'Geschwindigkeit in km/h']) }}

Code Auswählen Erweitern

{{ plot.period('', 'ws.windspeed.plot', 'raw', '48h', now, 0, 20, 100, 'Windgeschwindigkeit', '#a00', 'spline', ['raw 48h', 'Geschwindigkeit in km/h']) }}
Der Modus ist bei beiden gesetzt, einziger unterschied ist die Zeitspanne!
Wie du schon festgestellt hast, werden die Anzahl der Datensätze ignorriert!
Ich habe mit 100,200,1000,10000 und 100000 getestet, macht aber keinen Unterschied.

Noch etwas das vielleicht wichtig ist, ich habe mit 56h und 57h begonnen und
musste dann mit fortlaufender Zeit immer mehr verringern.
Mal so ein Gedanke, kann man die Daten in kleineren Pakten verschicken?
Wenn ich das log richtig lese, werden beide Aufrufe in zwei Pakten verschickt, sollten es beim zweiten nicht eher drei Pakete werden?

Gruß
Johann

[wvhn]

Ich meine die drei Plots für windgust, WZ_th.temp und WZ_th.humidity, die im smartVISU Log erscheinen. Dort fehlen die Modi und die Datensätze sind leer.

Das Senden in kleinen Paketen ist nicht vorgesehen. Lediglich die nachträglichen Updates kommen in kleinen Einheiten.

Wenn Du schreibst, Du hättest die Zeitspanne immer weiter verkürzen müssen: geht die Dauer 1:1 mit der Zeit? Das würde ja bedeuten, dass es ein Problem mit einer bestimmten Startzeit der Serie gibt.

[Johann.S]

Ich hatte im Firefox einen anderern Tab mit der Hauptversion offen, anscheinend sind die Daten von dort~~~

Nicht die Startzeit, es sind Echtzeitwinddaten und die verändern sich, bei mir geht ständig der Wind
Jetzt Teste ich mit 33h und 34h um den Effekt zu bekommen, in einer Stunde wieder mit anderen!

Währe es möglich das versenden auf Pakete umzustellen? Ich denke es wird hier irgendwo ein Buffer/Cach überlaufen!

Ich habe es jetzt mit nur einem smartVISU-Tab noch einmal durch geführt!
Um eine bessere Übersicht zu haben, habe ich beim zweiten Plot eine neue Variable verwendet.
Die sind aber im fronthem absolut gleich defieniert!

HTML:

Code Auswählen Erweitern

/**
* -----------------------------------------------------------------------------
* @package     smartVISU
* @author      Johann Schierl
* @copyright   2019
* @license     GPL [http://www.gnu.de]
* -----------------------------------------------------------------------------
*/

{% extends "base.html" %}

{% block content %}

{{ plot.period('', 'ws.windspeed.plot', 'raw', '33h', now, 0, 20, 100, 'Windgeschwindigkeit', '#a00', 'spline', ['raw 33h', 'Geschwindigkeit in km/h']) }}

{{ plot.period('', 'ws.windkmh.plot', 'raw', '34h', now, 0, 20, 100, 'Windgeschwindigkeit', '#a00', 'spline', ['raw 34h', 'Geschwindigkeit in km/h']) }}

{% endblock %}


Bilder und Log's wieder als Anhang.

Mir ist aber etwas aufgefallen im fhem-log, der Datenbankaufruf erfolgt zweimal mit ws.windspeed.plot.
Müsste es nicht einmal 'ws.windspeed.plot und einmal ws.windkmh.plot sein?

[wvhn]

Das Verhalten ist das Gleiche wie vorher. smartVISU erhält nur eine der Serien, obwohl innerhalb von fronthem beide Serien korrekt vorbereitet werden. Es fällt auf, dass bei beiden Versuchen die ankommenden Messages unter 64 kB groß sind, während die nicht ankommenden Messages mehr als 64kB haben (um genau zu sein: mehr als 65.536 ASCII-Zeichen). Deine Vermutung, dass ein Puffer überläuft, scheint damit richtig. Das muss der Sendepuffer des Websockets sein.

Anschließend werden die Updates der neu hinzugekommenden Datenpunkte für beide Serien korrekt gesendet.

Der neue Name der Plot-Serie in fronthem wird auch richtig angegeben. Im fhem Log wird der Name des Readings verwendet und der ist natürlich für beide Serien gleich.

Ich denke wir kommen hier ohne die Hilfe von fronthem-Profis nicht weiter. Aktuell gibt es keinen Hinweis, dass das Problem in smartVISU zu suchen ist - was meine Baustelle wäre.

Gruß
Wolfram

[Johann.S]

Hallo Wolfram,

ich habe gesehen, das du ein Issues bei herrmannj eingetragen hast,
der dürfte die Entwicklung aber anscheinend eingestellt haben!

Die Erweiterung für Plot stammt, so weit ich das sehe, von raman und das ist auch schon einige Zeit her!
Es gibt anscheinend auf GitHub keine Version die der von raman entspricht, vielleicht sollte man ihn per PM kontaktieren!
Währe schade wenn fronthem nicht mehr weiter Entwickelt wird.

Gruß
Johann

[herrmannj]

Ich hab die Einträge gesehen, vielen Dank. Die Plots kommen tatsächlich nicht von mir aber das hat erstmal nichts zu sagen. Problem ist eher das fronthem ein poc war, man müsste eigentlich einige Sachen grundlegend neu machen. So richtig dringend wars nie, dafür läuft fronthem zu gut. Grundsätzlich habe ich vor das anzugehen. Ich schaue Mal was geht

[Johann.S]

Hallo,

hat sich vielleicht etwas getan in diesem Fall?
Würde gerne meine Daten, die ich seit 2017 gesammelt habe, Anzeigen und Vergleichen!

@herrmannj: habe in der Zwischenzeit ernsthaft vesucht Perl, die Programmierung von fhem und die Kommunikation zwischen fhem und smartvisu zu lernen! Ist mir echt zu hoch!

Gruß
Johann

[wvhn]

Hallo Johann,

Mit ramans Hilfe haben wir ein Repository https://github.com/wvhn/fronthem aufgemacht, in dem ich mit meinen ebenfalls nicht vorhandenen Perl-und fronthem-Kenntnissen den bisherigen Stand von fronthem mit allen wichtigen Erweiterungen aus dem Forum zusammen getragen habe (master branch). Raman hat dann ein paar Weiterentwicklungen integriert und u.a. das Problem mit dem Websocket-Puffer gelöst (develop branch). Beides ist rudimentär getestet, aber außer einem Versuch von Funsailor mit den neuen UZSU-Funktionen gab es kein Feedback aus der Community. Und bisher auch keine Unterstützung bei der Analyse / Lösung des UZSU-Problems.

Du könntest Dich also als Tester engagieren und erstmal den master branch testen. Wenn sich damit alles so verhält wie bisher,  kannst Du entweder den ganzen develop branch ziehen und testen, oder Du spielst nur die Änderung im Websocket-Modul ein. Das müsste durch Austausch der 01_fronthem.pm und der fhewbsocket.pm klappen. Man kann dann Port und Puffergröße des Websockets in fronthem parametrieren. Raman hat seine Änderungen ab hier kurz beschrieben: https://forum.fhem.de/index.php/topic,127432.msg1234015.html#msg1234015.

Gruß Wolfram

P.S. wenn Du ein Backup Deiner bisherigen fronthem-Dateien machen und mir mal privat zukommen lassen würdest, dann wäre das für die Analyse von Problemen echt hilfreich.

[alkazaa]

Moin!

Ich habe die develop Version eingespielt und das neue Attribut maxSendSize ausprobiert. Ich habe es probehalber auf große Werte (128000) und kleine Werte (0) gesetzt, aber keine Auswirkungen festgestellt, d.h. Plot- und sonstige Daten wurden wie gewohnt in Smartvisu angezeigt. Smartvisu- und Browser-Cache waren jeweils gelöscht worden.

-Franz

[wvhn]

Moin Franz,

Bei Änderung der maxSendSize muss fhem neu gestartet werden. @JohannS hat dies ausführlich getestet und er konnte deutlich größere Plots darstellen, wenn er den Wert erhöhte. Das könntest Du nochmal verifizieren.

Wir haben aber noch ein anderes Problem entdeckt: bei der Auswertung der durations in der Subroutine ,,fronthem_Time" wird nur ein Term mit 2 Ziffern und einer Einheit zugelassen, also z.B. ,,99d" für 99 Tage. 100 Tage gehen dann schon nicht mehr.  ( klar könnte man "15w" schreiben, aber das sind dann halt 105 Tage). SmartVISU sieht eigentlich vor, die duration aus mehreren Termen zusammenzusetzen: ,,1y 3m 10d". Um das in fronthem verfügbar zu machen, müsste man den Ausdruck in der Subroutine an den Leerzeichen splitten, die Terme einzeln auswerten und deren Ergebnisse summieren. Da ich Perl nicht beherrsche, bin ich auf Mithilfe angewiesen. Bis dahin werde ich als Zwischenlösung die Begrenzung auf 4 Ziffern erweitern. Das hat Johann auch schon getestet.
Hierzu muss man das Regex in fronthem_Time und fronthem_Duration ändern in

Code Auswählen Erweitern

if ($period =~ /^(\d{1,4})(s|i|h|d|w|m|y)/)
und

Code Auswählen Erweitern

if ($duration =~ /^(\d{1,4})(s|i|h|d|w|m|y)/)

Weitere Ergebnisse folgen.

Gruß
Wolfram

P.S.: die Änderung in der 99_fronthemUtils.pm mit Kommentaren zum "to do" habe ich soeben in den develop branch gepusht. Wenn das ausreichend getestet ist, ziehe ich das im Master nach. Rückmeldungen sind willkommen.

[alkazaa]

Moin Wolfram, danke für die schnelle Rückmeldung.
Neustart hat in der Tat geholfen, ich hatte vorher nur mit "reload xxxx.pm" die entsprechenden Module aktualisiert.

Das (unabhängige) Problem mit '99' und '100' hatte ich auch schon gesehen und wollte es noch fürs Forum dokumentieren, ist aber nun ja nicht mehr nötig, Dank auch dafür.
Ich spiel mal weiter...

Gruß
Franz

Nachtrag
OK, hier das erste Ergebnis meines weiteren Spielens:
Du schriebst:

SmartVISU sieht eigentlich vor, die duration aus mehreren Termen zusammenzusetzen: ,,1y 3m 10d". Um das in fronthem verfügbar zu machen, müsste man den Ausdruck in der Subroutine an den Leerzeichen splitten, die Terme einzeln auswerten und deren Ergebnisse summieren. Da ich Perl nicht beherrsche, bin ich auf Mithilfe angewiesen.

Ich habe mal versucht, das splitten eines Ausdrucks á la ,,1y 3m 10d" in der der Routine fronthem_Time zu implementieren; es scheint zu funktionieren. Die andere Routine (fronthem_Duration) muss ich erst noch verstehen, dann probier ich das auch mal.

So sieht die Routine jetzt aus, meine 2 Einfügungen habe ich markiert:

Code Auswählen Erweitern

sub
fronthem_Time($$)
{
my ($time, $period) = @_;
#### Anfang 1. Einfügung
my @periods = split(' ', $period);
foreach my $period (@periods)
{
#### Ende 1. Einfügung
if ($period =~ /^(\d{1,4})(s|i|h|d|w|m|y)/)
{
my $newTime = 0;
#main::Debug('$2: '.$2);
if ($2 eq "s")
{
$newTime = $1;
}
elsif ($2 eq "i")
{
$newTime = $1 * 60;
}
elsif ($2 eq "h")
{
$newTime = $1 * 3600;
}
elsif ($2 eq "d")
{
$newTime = $1 * 3600 * 24;
}
elsif ($2 eq "w")
{
$newTime = $1 * 3600 * 24 * 7;
}
elsif ($2 eq "m")
{
$newTime = $1 * 3600 * 24 * 30;
}
elsif ($2 eq "y")
{
$newTime = $1 * 3600 * 24 * 365;
}
$time = $time - $newTime;
}
#### Anfang 2. Einfügung
}
#### Ende 2. Einfügung
return $time;
}

[alkazaa]

Moin!
Ich habe nun auch die Routine fronthem_Duration geändert. Diese Routine berechnet den Mittelungsmodus für den Fall, dass in SV der plot.period Parameter 'mode' ungleich 'raw' ist. Wenn ich das richtig verstanden habe, wurde in der vorhandenen Implementierung von fronthem_Duration dafür nur der SV-Parameter 'tmin' ausgewertet. Für den Fall, dass das [tmin,tmax] Intervall relativ kurz und weiter in der Vergangenheit liegt, ergaben sich damit unsinnig lange Mittelungszeiten.

Die neue Implementierung wertet jetzt  die Intervalllänge tmax-tmin aus. Der Code von fronthem_Duration lautet nun

Code Auswählen Erweitern

sub
fronthem_Duration($)     # duration of interval (tmax - tmin) in seconds
{
my ($duration) = @_;
if ($duration > 2*365*24*3600)
{
return 'yearstats';
}
elsif ($duration > 2*30*24*3600)
{
return 'monthsstats';
}
elsif ($duration > 2*7*24*3600)
{
return 'weekstats';
}
elsif ($duration > 2*24*3600)
{
return 'daystats';
}
elsif ($duration > 2*3600)
{
return 'hourstats';
}
return 'timerange';
}

In der eigentlichen Plotroutine Plot() ist dann noch folgende Anpassung wichtig:

Code Auswählen Erweitern

if ($mode ne "raw") {
my $duration_seconds = main::fronthem_Time(0, $end) - main::fronthem_Time(0, $start);
$duration = main::99_fronthemUtils.pm($duration_seconds);
}
# if ($mode ne "raw") {
# $duration = main::fronthem_Duration($start);
# }

Die Datei 99_fronthemUtils.pm mit den neuen Routinen fronthem_Time und fronthem_Duration hänge ich hier an (der alte fronthem_Duration code ist zum Vergleich noch drin, aber auskommentiert).

Rückmeldungen vom code-reviewing und Testen gern auch per PN.

Beste Grüße
Franz

[wvhn]

Moin Franz,

das sieht super aus. Vielen Dank!
Nach einem kurzen "Code Review" habe ich die Änderungen gleich in den develop branch gepusht.

Die Idee, die Intervalllänge als Basis für die Mittelungsmethoden zu nehmen, ist ein großer Schritt in die richtige Richtung. Meines Erachtens könnte man nochmal probieren, ob dies nicht am "Abtastintervall" orientiert werden muss, also an (tmax-tmin)/count. Ich könnte mir vorstellen, dass dies die Genauigkeit der Darstellung erhöht. Habe allerdings keine Ahnung, wie die Datenbankabfrage realisiert ist. 

Gruß
Wolfram

[alkazaa]

Moin Wolfram,
Du schriebst:

Die Idee, die Intervalllänge als Basis für die Mittelungsmethoden zu nehmen, ist ein großer Schritt in die richtige Richtung. Meines Erachtens könnte man nochmal probieren, ob dies nicht am "Abtastintervall" orientiert werden muss, also an (tmax-tmin)/count. Ich könnte mir vorstellen, dass dies die Genauigkeit der Darstellung erhöht. Habe allerdings keine Ahnung, wie die Datenbankabfrage realisiert ist. 

Da wird sich (ohne sehr großen Aufwand) nicht viel machen lassen. Die Datenbankabfrage ist in dem Modul 93_DbLog.pm realisiert (Doku siehe https://fhem.de/commandref_DE.html#DbLog) und liefert mit den Modi hourstats, yearstats etc. Statistikdaten (min, max, avg...) über den jeweiligen Zeitraum, unabhängig von der Zahl der in dem Zeitfenster gesampelten Daten.

Beste Grüße
Franz

[wvhn]

Moin Franz,

Danke für die Einschätzung. Das kann man tatsächlich nicht so einfach umbiegen. Ich habe auch jetzt erst gesehen, dass der "count"-Parameter aus der Anfrage von smartVISU nicht an fhem weitergegeben wird. Somit ist die Idee erstmal vom Tisch. IMHO macht smarthomeNG das besser, indem es mit dem count-Parameter Daten pro Abtastintervall gruppiert und darauf die Methoden (min, max, avg) anwendet. So kann man die gewünschte  Genauigkeit durch Vorgabe der Anzahl von Punkten selbst wählen.

Gruß
Wolfram

P.S.: in Zeile 100 habe ich noch einen Typo gefunden ("monthsstats" statt "monthstats") und im develop korrigiert.