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

[alkazaa]

Moin Wolfram,

ich möchte meine Einschätzung "großer Aufwand" korrigieren.
Sie basierte darauf, dass man für die Funktionalität 'avg, min, max, ...' die bereits in 93_DbLog.pm implementierten Funktionen nutzt.

Man hat aber natürlich in der Plot() Routine in 99_fronthemUtils.pm die raw-Daten zur Verfügung und kann dort das averaging etc. durchführen.

Ich habe das mal für ein averaging über count Messpunkte realisiert.

Dazu habe ich die foreach-Schleife in sub Plot()

Code Auswählen Erweitern

foreach my $data (@response) {
my $i = 0;
foreach my $row (@{$data->{data}}) {
if ($mode eq "raw") { # [TIMESTAMP,VALUE]
push(@{$data[0]->{plotdata}[$i]}, main::fronthem_TimeStamp($row->{TIMESTAMP}));
push(@{$data[0]->{plotdata}[$i]}, sprintf("%#.4f", $row->{VALUE}) * 1);
}
elsif ($mode eq "avg") { # [TIMESTAMP,AVG]
push(@{$data[0]->{plotdata}[$i]}, main::fronthem_TimeStamp($row->{TIMESTAMP}));
push(@{$data[0]->{plotdata}[$i]}, $duration eq "timerange" ? sprintf("%#.4f", $row->{VALUE}) * 1 : sprintf("%#.4f", $row->{AVG}) * 1);
}
elsif ($mode eq "sum") { # [TIMESTAMP,SUM]
push(@{$data[0]->{plotdata}[$i]}, main::fronthem_TimeStamp($row->{TIMESTAMP}));
push(@{$data[0]->{plotdata}[$i]}, $duration eq "timerange" ? sprintf("%#.4f", $row->{VALUE}) * 1 : sprintf("%#.4f", $row->{SUM}) * 1);
}
elsif ($mode eq "min") { # [TIMESTAMP,MIN]
push(@{$data[0]->{plotdata}[$i]}, main::fronthem_TimeStamp($row->{TIMESTAMP}));
push(@{$data[0]->{plotdata}[$i]}, $duration eq "timerange" ? sprintf("%#.4f", $row->{VALUE}) * 1 : sprintf("%#.4f", $row->{MIN}) * 1);
}
elsif ($mode eq "max") {  # [TIMESTAMP,MAX]
push(@{$data[0]->{plotdata}[$i]}, main::fronthem_TimeStamp($row->{TIMESTAMP}));
push(@{$data[0]->{plotdata}[$i]}, $duration eq "timerange" ? sprintf("%#.4f", $row->{VALUE}) * 1 : sprintf("%#.4f", $row->{MAX}) * 1);
}
$i++;
}
}
         
ersetzt durch:

Code Auswählen Erweitern

foreach my $data (@response) {
my $i = 0;
my $avgval = 0;
my $timestampvalue = 0;
my $avgcount = 0;
my $jmax = scalar(@{$data->{data}});
my $j = 0;
foreach my $row (@{$data->{data}}) {
if ($mode eq "raw") { # [TIMESTAMP,VALUE]
$avgcount++;
$avgval += $row->{VALUE};
$timestampvalue += main::fronthem_TimeStamp($row->{TIMESTAMP});
$j++;
if (($count < 0) && ($avgcount == -$count || $j == $jmax))
{
push(@{$data[0]->{plotdata}[$i]}, $timestampvalue/$avgcount);
push(@{$data[0]->{plotdata}[$i]}, sprintf("%#.4f", $avgval/$avgcount) * 1);
$avgcount = 0;
$avgval = 0;
$timestampvalue = 0;
$i++;
}
elsif ($count >= 0)
{
push(@{$data[0]->{plotdata}[$i]}, main::fronthem_TimeStamp($row->{TIMESTAMP}));
push(@{$data[0]->{plotdata}[$i]}, sprintf("%#.4f", $row->{VALUE}) * 1);
$i++;
}
}
elsif ($mode eq "avg") { # [TIMESTAMP,AVG]
push(@{$data[0]->{plotdata}[$i]}, main::fronthem_TimeStamp($row->{TIMESTAMP}));
push(@{$data[0]->{plotdata}[$i]}, $duration eq "timerange" ? sprintf("%#.4f", $row->{VALUE}) * 1 : sprintf("%#.4f", $row->{AVG}) * 1);
$i++;
}
elsif ($mode eq "sum") { # [TIMESTAMP,SUM]
push(@{$data[0]->{plotdata}[$i]}, main::fronthem_TimeStamp($row->{TIMESTAMP}));
push(@{$data[0]->{plotdata}[$i]}, $duration eq "timerange" ? sprintf("%#.4f", $row->{VALUE}) * 1 : sprintf("%#.4f", $row->{SUM}) * 1);
$i++;
}
elsif ($mode eq "min") { # [TIMESTAMP,MIN]
push(@{$data[0]->{plotdata}[$i]}, main::fronthem_TimeStamp($row->{TIMESTAMP}));
push(@{$data[0]->{plotdata}[$i]}, $duration eq "timerange" ? sprintf("%#.4f", $row->{VALUE}) * 1 : sprintf("%#.4f", $row->{MIN}) * 1);
$i++;
}
elsif ($mode eq "max") {  # [TIMESTAMP,MAX]
push(@{$data[0]->{plotdata}[$i]}, main::fronthem_TimeStamp($row->{TIMESTAMP}));
push(@{$data[0]->{plotdata}[$i]}, $duration eq "timerange" ? sprintf("%#.4f", $row->{VALUE}) * 1 : sprintf("%#.4f", $row->{MAX}) * 1);
$i++;
}
#$i++;
}
main::Debug('imax: '.$i.'; jmax: '.$jmax);
}

         
(Das Debug-statement am Schluß schreibt imax und jmax in die FHEM-Logdatei)

Zum Testen:
Man muss einen negativen (!) count Parameter in SV angeben und den 'raw' Modus nutzen.

Außerdem geht die Mittelung davon aus, dass die Messwerte äquidistant in der Zeit sind, was in FHEM (und zumindest bei mir ist es oft so) auch anders sein kann. So eine gewichtete Mittelwertbildung zu implementieren erfordert dann noch etwas mehr Mühe. Mal schaun, ob's interessiert.

Beste Grüße
Franz

[wvhn]

Klasse!

Es wäre toll, wenn ein paar Plot-Intensivnutzer dies testen und bewerten könnten, ob die Darstellung - abhängig von der Anzahl angeforderter Punkte - besser wird, als mit der Standard-Statistik. Wenn das bestätigt ist, lohnt sich eine Weiterentwicklung. Zur ganz korrekten Mittelung muss übrigens jeder einzelne Wert im Abtastintervall mit seiner Dauer multipliziert werden und die Summe dieser Werte durch die gesamte Dauer des Abtastintervalls geteilt werden.

Gibt es übrigens eine Möglichkeit, das Abonnement eines Plot-items zu stoppen? Nach den Tests von @JohannS scheinen die "Geister"-Telegramme auf dem Websocket daher zu kommen, dass fhem Update-Events für nicht mehr benötigte Plots triggert und diese in fronthem nicht abgefangen werden. Ich kann von smartVISU aus bei jedem Seitenwechsel einen Befehl z.B. "series_cancel" über den Websocket schicken, der dieselben Parameter wie "series" hat und jedem Plot einzeln abbestellt. Das ist in Verbindung mit smarthomeNG schon standardmäßig umgesetzt.

Gruß
Wolfram

[Johann.S]

Hallo Wolfram und Franz!

Wegen den "Geister" Telegrammen möchte ich noch was erklähren!

So wie in dem Screenshot sieht bei mir z.B. ein Heizkörper in smartVISU aus.
Die Einstellungen in fronthem sind im nächsten Bild.
Links in jedem Bild sieht man ob das Item aktiv ist oder nicht!
Bei den Plots wird das nicht gemacht!
Sobald sich in einem Plot etwas ändert, egal ob aktiv oder nicht, wird die Information an smartVISU gesendet!
Vielleicht hilft das bei der Suche!

Ich habe mir auch die avg Änderung angesehen!
Meine Testeinstellungen in smartVISU sehen so aus:

Code Auswählen Erweitern

{{ plot.period('', 'ws.windspeed.plot', 'raw', '1m', '1h', '', '', -100, 'Windgeschwindigkeit', '#a00', 'spline', ['raw 1m 1h', 'Geschwindigkeit in km/h']) }}

Code Auswählen Erweitern

{{ plot.period('', 'ws.windspeed.plot', 'raw', '1m', '1h', '', '', '-100', 'Windgeschwindigkeit', '#a00', 'spline', ['raw 1m 1h', 'Geschwindigkeit in km/h']) }}

Code Auswählen Erweitern

{{ plot.period('', 'ws.windspeed.plot', 'raw', '1m', '1h', '', '', '!100', 'Windgeschwindigkeit', '#a00', 'spline', ['raw 1m 1h', 'Geschwindigkeit in km/h']) }}
Da ich mir in der Schreibweise nicht sicher bin!
Getestet habe ich mit 100,200,300 und 1000 wobei sich die Datenlänge (~190.500) nur minimal geändert hat!
Zur Sicherheit habe ich alle Dateien aus dem Developer und die 99_fronthemUtils.pm aus dem Anhang noch mal übertrage und geteste.
Leider kein Unterschied!

Gruß
Johann

[alkazaa]

Moin Johann,
Dank fürs Testen.

Solch große Datensätze wie Du hatte ich nicht zum Testen. Ich hänge hier mal 4 Bilder an, in denen jeweils ca. 2500 Daten mit 500, 50, 10 Punkten und gar nicht gemittelt wurden.

Der SmartVISU code sowie die ins FHEM-Log geschriebene Debug Information sah dabei so aus:

Code Auswählen Erweitern

SV-Definition: {{ plot.period('', 'ESP1_rFplot', 'raw', '5d','1h','','','-500','T-WZ','#060','',['Zeit'],'',[2],[1,0])}}
FHEM-Log-Zeile: 2022.11.22 17:06:20 1: DEBUG>imax: 6; jmax: 2501

SV-Definition: {{ plot.period('', 'ESP1_rFplot', 'raw', '5d','1h','','','-50','T-WZ','#060','',['Zeit'],'',[2],[1,0])}}
FHEM-Log-Zeile: 2022.11.22 17:11:35 1: DEBUG>imax: 51; jmax: 2501

SV-Definition: {{ plot.period('', 'ESP1_rFplot', 'raw', '5d','1h','','','-10','T-WZ','#060','',['Zeit'],'',[2],[1,0])}}
FHEM-Log-Zeile: 2022.11.22 17:12:47 1: DEBUG>imax: 250; jmax: 2500

SV-Definition: {{ plot.period('', 'ESP1_rFplot', 'raw', '5d','1h','','','10','T-WZ','#060','',['Zeit'],'',[2],[1,0])}}
FHEM-Log-Zeile: 2022.11.22 17:14:12 1: DEBUG>imax: 2501; jmax: 2501

Was standen denn bei Dir in der Log-Datei für Werte von imax und jmax?

Die jeweils erhaltenen SmartVISU Plots sind in den anghängten Dateien.
Gruß
Franz

[alkazaa]

Ich habe das averaging jetzt auch mal mit einem größeren Datensatz getestet, und es läuft bei mir im Prinzip korrekt.
'Im Prinzip' heißt dabei, dass der große Datensatz (ca. 320000 Daten) korrekt dargestellt und gemittelt wird. Allerdings dauert das ganze etwa 85 sec, und in meiner FHEM-Logdatei tauchen dabei merkwürdige Fehlermeldungen von verschiedenen anderen devices auf (der MQTT2-Server meckert besonders häufig). Ich vermute, dass die Plot() Routine in 99_fronthemUtils.pm im blocking-mode läuft und damit das FHEM-System kräftig durcheinander bringt.

Die benutzte Hardware: aktuelles FHEM auf Raspi 3B+, MariaDB Server auf einer Synology DS216j, beide im LAN verbunden. SmartVISU 3.2.0

Ich hatte übrigens die averaging Routine auf gewichtete Mittelwertbildung erweitert, war gar nicht so schwer. (Siehe Datei im Anhang.)

Mein Zwischenfazit wäre: das averaging in 99_fronthemUtils.pm zu machen ist nur für kürzere Datensätze sinnvoll. Wo genau die Grenze zwischen kürzer und länger liegt, hängt vielleicht von der verwendeten Hardware ab.

Wünschenswert wäre es, die statistischen Auswertungen (avg, min, max etc.) wie bisher vom db-Server machen zu lassen, aber mit besserer Kontrolle des Auswerteintervalls.

Und den Trick wie das geht verrate ich vielleicht demnächst   
Muss noch bisschen testen...

-Franz

[wvhn]

Hallo Franz,

das hört sich ja vielversprechend an. Wichtig wäre mal ein Vergleich der Ergebnisse mit der heutigen Standard-Abfrage und der neuen Mittelung. Lohnt sich der Aufwand?

Insbesondere die Idee, die Auswertung gleich in der Datenbank richtig zu machen, finde ich gut. Dazu zwei Hinweise:

"count" ist in smartVISU die Anzahl der Punkte im Plot (je höher count, desto feiner die Auflösung). In Deiner ersten Mittelungsmethode hast Du count als Anzahl der Punkte interpretiert, über die gemittelt wird (je höher count, desto gröber die Auflösung). Ich plädiere dafür, den Standard aus smartVISU zu verwenden, wie dies andere Backends auch machen.

Ein gutes Beispiel für die Datenbankabfrage ist das Python-Skript für das database-Plugin von smarthomeNG: https://github.com/smarthomeNG/plugins/blob/master/database/__init__.py
Ab Zeile 813 wird die Abfrage zusammengebaut. Dabei werden die Daten jeweils in Gruppen der Breite step = (tmax-tmin)/count gruppiert:

Code Auswählen Erweitern

GROUP BY ROUND(time / :step)
und dann entsprechend dem "mode"-Parameter der Serie weiter verarbeitet. Die Selektionskriterien für die durations werden ab Zeile 896 zusammengestellt.

Gruß
Wolfram

[alkazaa]

Hallo Wolfram,

das hört sich ja vielversprechend an. Wichtig wäre mal ein Vergleich der Ergebnisse mit der heutigen Standard-Abfrage und der neuen Mittelung. Lohnt sich der Aufwand?

Vermutlich lohnt sich der Aufwand nicht, da die Zahl der SV-Plot-FHEM user im niedrigen einstelligen Bereich liegen dürfte...
Andrerseits: als nicht mehr berufstätiger Mensch gehe ich das ganze eher sportlich an, als Zeitvertreib ähnlich wie Kreuzworträtsel lösen. Von Perl, SQL etc. habe ich close-to-zero Ahnung, aber das machts gerade spannend.

Ich möchte dennoch jetzt gern mal eine Zusammenfassung dessen schreiben, was ich hier gelernt habe. Und das Thema damit zumindest für mich abschließen, da ich für das was evtl. noch zu tun wäre nicht mehr beitragen kann.

Zunächst einmal der Vergleich dreier Testszenarien. Ich habe einen drei Monate langen Datensatz mit ca. 47000 Daten dargestellt, und zwar einmal im 'raw' Modus ohne jede Mittelung, dann mit 'avg' und nicht-gewichteter Mittelung über jeweils 1 Woche, und zum Schluß eine gewichtete Mittelung mit dem von mir implementierten Algorithmus (so dass aus den 30 Monaten 13 Mittelwerte entstanden). Zum Messen des Timings habe ich mit einigen Debug-Befehlen Informationen in die FHEM-Logdatei geschrieben.

Szenario 1 (46785 raw Daten):

Code Auswählen Erweitern


{{ plot.period('', ['E_Verbrauch'], ['raw'], '0w 3m','','','',['14'],['A'],['#060','#d00','#880'],'',['Zeit', '°C', '%'],'',[2,1,1],[1,0])}}

2022.11.25 11:29:02 1: DEBUG>QUERY
2022.11.25 11:29:02 1: DEBUG>sql: SELECT TIMESTAMP, VALUE FROM history WHERE READING = 'power' AND DEVICE = 'E_Zaehler' AND TIMESTAMP Between '2022-08-27 12:29:02' AND '2022-11-25 11:29:02' ORDER BY TIMESTAMP;
2022.11.25 11:29:08 1: DEBUG>START averagig  duration: timerange
2022.11.25 11:29:08 1: DEBUG>imax: 46785
2022.11.25 11:29:14 1: DEBUG>DONE

Die erste Zeile ist die SV Definiton, dann kommt markiert mit 'QUERY' der Start der SQL Abfrage, dann mit 'START averaging ...' das Übertragen der Daten zu SmartVISU

Szenario 2 (46785 raw Daten, schon mit der SQL-Abfrage wochenweise gemittelt):

Code Auswählen Erweitern


{{ plot.period('', ['E_Verbrauch'], ['avg'], '0w 3m','','','',['14'],['A'],['#060','#d00','#880'],'',['Zeit', '°C', '%'],'',[2,1,1],[1,0])}}

2022.11.25 11:29:44 1: DEBUG>QUERY
2022.11.25 11:29:44 1: DEBUG>sql: SELECT date_format(timestamp, '%Y-%m-%d 00:00:00') AS TIMESTAMP, SUM(CAST(VALUE AS DECIMAL(12,4))) AS SUM, AVG(CAST(VALUE AS DECIMAL(12,4))) AS AVG, MIN(CAST(VALUE AS DECIMAL(12,4))) AS MIN, MAX(CAST(VALUE AS DECIMAL(12,4))) AS MAX, COUNT(VALUE) AS COUNT FROM history WHERE READING = 'power' AND DEVICE = 'E_Zaehler' AND TIMESTAMP Between '2022-08-27 12:29:44' AND '2022-11-25 11:29:44' GROUP BY date_format(timestamp, '%Y-%u 00:00:00') ORDER BY 1;
2022.11.25 11:29:48 1: DEBUG>START averagig  duration: weekstats
2022.11.25 11:29:48 1: DEBUG>imax: 14 noofavgs: 0
2022.11.25 11:29:48 1: DEBUG>DONE


Szenario 3 (46785 raw Daten, in 99_fronthemUtils.pm gewichtet gemittelt zu 13 Datenpunkten):

Code Auswählen Erweitern


{{ plot.period('', ['E_Verbrauch'], ['raw'], '0w 3m','','','',['-14'],['A'],['#060','#d00','#880'],'',['Zeit', '°C', '%'],'',[2,1,1],[1,0])}}

2022.11.25 11:30:50 1: DEBUG>QUERY
2022.11.25 11:30:50 1: DEBUG>sql: SELECT TIMESTAMP, VALUE FROM history WHERE READING = 'power' AND DEVICE = 'E_Zaehler' AND TIMESTAMP Between '2022-08-27 12:30:50' AND '2022-11-25 11:30:50' ORDER BY TIMESTAMP;
2022.11.25 11:30:55 1: DEBUG>START averagig  duration: timerange
2022.11.25 11:30:55 1: DEBUG>imax: 46784 noofavgs: 3341
2022.11.25 11:31:01 1: DEBUG>number of data: 46784; number of averaged data: 13
2022.11.25 11:31:01 1: DEBUG>DONE


Man sieht, dass die SQL Abfrage in allen 3 Fällen ca. 5 sec braucht. In Szenario 1 (wo gar nicht gemittelt wird) die sub Plot() in 99_fronthemUtils.pm dann nochmal ca. 6 sec! ABER: der SQL-Vorgang in 93_DbLog.pm wird non-blocking ausgeführt (und stört den FHEM Prozess nicht), der Vorgang in der sub Plot() dagegen ist blocking. Und das Umstellen auf non-blocking überfordert mich klar.

In Szenario 2 wieder die ca. 5 sec für SQL, aber dann quasi instantan die bereits auf 14 Punkte eingedampften Daten nach SV.

In Szenario 3 wieder 5 sec die SQL, und 6 sec in sub Plot().

Im Anhang sind die Ergebnisse gezeigt.

"count" ist in smartVISU die Anzahl der Punkte im Plot (je höher count, desto feiner die Auflösung). In Deiner ersten Mittelungsmethode hast Du count als Anzahl der Punkte interpretiert, über die gemittelt wird (je höher count, desto gröber die Auflösung).

Das habe ich korrigiert.

Ein gutes Beispiel für die Datenbankabfrage ist das Python-Skript für das database-Plugin von smarthomeNG: https://github.com/smarthomeNG/plugins/blob/master/database/__init__.py

Schau ich mir bei Gelegenheit an (Python kann ich auch nicht...)

Und hier zum Trick, wie man im SV plot.period statement angibt, welche Mittelungsperiode anzuwenden ist: Da in 99_fronthemUtils.pn für die Festlegung des Mittelungsintervalls der Anfang des SV-Parameters 'start' ausgewertet wird, und da mit einer der kürzlichen Änderungen auch strings wie '2w 3d 4h' als start-Parameter richtig gelesen werden, kann man z.B. mit '0d 2w' eine Tageweise Mittelung erreichen, oder mit '0m 2y' die Mittelwerte der Monate im 2 Jahreszeitraum berechnen lassen, oder wie im obigen Beispiel mit '0w 3m' die wochenweise-Mittelung für den 3-Monatszeitraum.

So, das war's erstmal von meiner Seite.

(Die angehängte 99_fronthemUtils.pm enthält noch die Debug statements. Das Debug in 93_DbLog.pm müsste man selber einfügen (Zeile 6599)

Beste Grüße
Franz

[wvhn]

Hallo Franz,

das hast Du super dokumentiert. Vielen Dank.

Die bisherige Version der fronthem Plots hat nur einen Term für die durations zugelassen. Die Filterung konnte man über diesen Term mit beeinflussen. Bei einer duration von ,,3m" bekam man nur 3 Werte. Gab man für die gleiche Zeitspanne ,,13w" ein, waren es 13 Werte und ,,90d" ergab 90 Werte für den gleichen Zeitraum. Bei der Erweiterung auf mehrere zulässige Terme haben wir das übersehen. Die Idee, die Filterung nur von der Gesamtdauer der Zeitspanne abhängig zu machen, war nicht so gut. Das hast Du ja wieder rückgängig gemacht, indem Du die Subroutine fronthem_duration wieder auf den alten Stand geändert hast.

Aus Kompatibilitätsgründen sollten wir das so lassen und den ,,Trick" gut dokumentieren. D.h. der Filter, den man verwenden will, muss immer im ersten Term stehen. Also z.B. ,,0h 3w", wenn man pro Stunde einen Wert bekommen will. ,,2184h" geht alternativ auch, nachdem wir die Beschränkung auf 2 Ziffern aufgehoben haben. Zusätzlich könnte man den Parameter count auswerten, um den Filter auszuwählen. Das schaue ich mir nochmal an.

Die Filter sind übrigens so realisiert, dass die Datumseinträge bei der SQL-Abfrage an entsprechender Stelle abgeschnitten und mit Nullen aufgefüllt werden. Dadurch entstehen z.B. beim Filter ,,daystats" innerhalb eines Tages viele Werte mit Zeitstempel ,,<Tagesdatum> 00:00:00", über die dann gemittelt wird. Das Ergebnis ist dann jeweils ein Punkt am Tagesdatum um 0:00 Uhr. Man muss sich also bewusst sein, dass bei Verwendung von avg, min und max eine duration, die feiner auflöst als der eingestellte Filter, keine Auswirkungen hat. Sprich: Terme mit Werten unter "120i" oder "7200s" machen nur im raw-Modus Sinn, da der feinste Filter die Werte auf Stundenbasis zusammenfasst.

Gruß
Wolfram

[wvhn]

Die Rückänderung auf die alte Version von "fronthem_duration" ist jetzt im develop branch. Auf mittlere Sicht werde ich dies in den Master übernehmen, wenn hier noch ein paar Teseter grünes Licht geben.
Dabei ist zu beachten, dass die Auswahl der Statistikfunktion aus Gründen der Rückwärtskompatibilität etwas hakelig ist. Mann kann zwar im ersten Term mit z.B. "0d" die Tagesstatistik (pro Tag ein Wert) auswählen, "1d" führt aber wie bisher zur Auswahl der Stundenstatistik (24 Werte pro Tag).  "0d 2y 6m" ergibt also über die letzten 2 1/2 Jahre pro Tag einen Wert, "1d 2y 6m" erhöht den Zeitraum um einen Tag und stellt die Statistik auf Stundenwerte um.

Wer die lokale Mittelung aus den raw-Daten testen will, muss sich weiter die letzte Version von alkazaa aus seinem letzten Post laden.

Gruß
Wolfram

[Johann.S]

Hallo Franz und Wolfram!

Ich bin mal davon ausgegangen, dass die zwei Plots

Code Auswählen Erweitern

{{ plot.period('', 'ws.windspeed.plot', 'avg', '0d 1y', '', '', '', '14', 'Windgeschwindigkeit', '#a00', 'spline', ['avg 0d 1y / 14', 'Geschwindigkeit in km/h']) }}

Code Auswählen Erweitern

{{ plot.period('', 'ws.windspeed.plot', 'raw', '0d 1y', '', '', '', '-14', 'Windgeschwindigkeit', '#a00', 'spline', ['raw 0d 1y / -14', 'Geschwindigkeit in km/h']) }} abgesehen von der Geschwindigkeit, das gleiche Ergebnis sein sollten!

Bei mir sehen sie aus wie im Screenshot 1!

Mache/Verstehe ich was falsch?

Gruß
Johann

Nachtrag: Developerversion und 99_fronthemUtils.pm von Franz!

[alkazaa]

Hallo Johann,
Danke fürs Weitertesten!

In meiner letzten fronthemUtils Version hatte ich (nach Hinweis von Wolfram) den SV-Parameter count so interpretiert, wie es in der SV Doku beschrieben ist, als Zahl der Daten pro Plot. (Vorher hatte ich es als Zahl der Daten pro Mittelung genommen).
Die 14 Werte scheinen also zu passen (lass den Spline weg, dann müsste man es auszählen können). Setz mal den count auf -365.

Im ersten Plot sind es auf den ersten Blick 365 Punkte, wie es dem '0d' entspricht.

Weitere Details:
ich bin beim Mitteln davon ausgegangen, dass in den Originaldaten zu den Zeitpunkten t0, t1, t2, ... die Werte y0, y1, y2, ... gemessen wurden. Für den Beispielfall einer Mittelung über nur 2 Punkte habe ich dann <y0> = (y0*(t1-t0) + y1*(t2-t1))(t2-t0) gerechnet.

Und diesen Mittelwert habe ich dann dem Zeitpunkt t0 zugeordnet. Dahinter stand die Überlegung, dass man mangels besseren Wissens davon ausgehen müsste, dass während des ganzen Zeitraums t0 bis t1 der Wert y0 vorliegt usw. Und somit wäre es konsistent, den Wert <y0> dem Zeitpunkt t0 zuzuordnen, und <y1> dem Zeitpunkt t2 usw.

Man könnte <y0> auch dem Zeitpunkt (t2-t0)/2 zuordnen, aber ich fand meine Wahl konsistenter. Was am sinnvollsten ist, müsste man diskutieren.

Jedenfalls  führt dieses Detail dazu, dass die 14 Werte des 2. Plots schon Mitte September enden.


Gruss
Franz

[Johann.S]

Hallo Franz,

ok, ich hatte es so vertstanden, dass er den Mittelwert aus 14 Punkten nimmt!

Code Auswählen Erweitern

{{ plot.period('', 'ws.windspeed.plot', 'avg', '0d 1y', '', '', '', '365', 'Windgeschwindigkeit', '#a00', '', ['avg 0d 1y / 365', 'Geschwindigkeit in km/h']) }}

Code Auswählen Erweitern

{{ plot.period('', 'ws.windspeed.plot', 'raw', '0d 1y', '', '', '', '-365', 'Windgeschwindigkeit', '#a00', '', ['raw 0d 1y / -365', 'Geschwindigkeit in km/h']) }}

Sieht gleich besser aus!
Der Zeitunterschied ist aber gewaltig!
Ich werde noch einige Test machen, Hut ab vor der Leistung!

Kann man deine Auswertung irgendwie aktivieren, ich find die Super!

Gruß
Johann

[alkazaa]

Hallo Johann,
Du schriebst:

Kann man deine Auswertung irgendwie aktivieren, ich find die Super!

Ich bin ncht sicher, was Du mit 'aktivieren' meinst. Aber ich würde von meiner Art des Mittelns abraten, und zwar wegen der Blockierung des FHEM Prozesses. Wobei: es ist nicht der Mittelungsalgorithmus, der die Zeitprobleme macht, die treten auch beim 'raw' ohne einen negativen count-Parameter auf. Es ist einfach die große Zahl der raw Daten die an SV weitergereiht werden.

Wie ich schon in einem der vorigen Beiträge sagte, ist die beste Mittelung die, die bereits beim SQL-Query vom DB-Server erledigt wird. Und da ist das benutzte FHEM Modul 93_DbLog.pm (ein ganz tolles Modul, nebenbei) für den Einsatz im fronthemUtils vielleicht nicht mal das beste. Es gibt nämlich noch das Modul DbRep (vom gleichen Entwickler glaub ich), dass laut Doku (https://fhem.de/commandref_DE.html#DbRepattr ) noch mehr Möglichkeiten bietet, z.B. auch gemittelte Averages.
Aber wie ich auch schon sagte: ich bin mangels Kenntnissen da raus, das in fronthemUtils einzubauen.

-Franz

[Johann.S]

Hallo Franz,

ja schon aber bei deiner Routine kann man auch auf Stunden oder 4 Werte pro Tag usw... einstellen.
Bei DbLog und DbRep geht das nur auf Tag oder Woche!
Den Unterschied siehst du im Screenshot!
So in der Art möchte ich das hinbekommen und ein Wert pro Tag ist einfach zuwenig!

Ich versuche gerade einen SQL-Query auf zu bauen der mehr kann!
Wenn ich fertig bin versuche ich in fhem beizubringen so das er mit DbLog oder DbRep funtkioniert!
Wobei DbLog währe mir lieber, den das muss auf jeden Fall vorhanden sein!

Ich melde mich wenn ich mehr weiss oder bei den Tests was auftritt!

-Johann

[alkazaa]

Hallo Johann,

ich hab's nicht ausprobiert, aber bei DbRep kann man anscheinend auch 'minute' auswählen.

Und ne alternative Idee: die Daten schon vor dem Speichern in die DB reduzieren (d.h. in FHEM)?

-Franz