Ich verzweifel an perl... :-/
Soweit habe ich verstanden, dass das average-Modul keine relativen Mittelwerte erzeugen kann. Es werden ab einem festen Wert die Readings aufsummiert und durch das Zeitintervall bis localtime() geteilt. Danach wird wird cum_XYZ wieder gelöscht und von neuem ausummiert. Dafür brauchtman keine Logs sondern immer nur die aktuellen Readings.
Möchte man aber den Mittelwert z.B. bezogen auf localtime(time-3600), also alle Werte der letzten Stunde, muss man an die Logs ran.
Das habe ich jetzt versucht und prinzipiell funktioniert das schon:
fhem> {my $period_start = strftime "%Y-%m-%d_%H:%M:%S", localtime(time-3600);;my $period_end = strftime "%Y-%m-%d_%H:%M:%S", localtime;; fhem("get FileLog_KS300 - - $period_start $period_end 8:::");;}
2013-03-11_21:48:24 2.7
2013-03-11_21:50:57 3.6
2013-03-11_21:53:29 0.2
2013-03-11_21:56:02 2.7
2013-03-11_21:58:34 1.9
2013-03-11_22:01:07 3.3
2013-03-11_22:06:12 0.8
2013-03-11_22:08:44 1.1
2013-03-11_22:11:17 0.0
2013-03-11_22:13:49 0.0
2013-03-11_22:16:22 0.0
2013-03-11_22:18:54 0.2
2013-03-11_22:21:27 1.6
2013-03-11_22:23:59 0.2
2013-03-11_22:26:32 2.5
2013-03-11_22:29:04 0.8
2013-03-11_22:31:37 1.3
2013-03-11_22:34:09 1.3
2013-03-11_22:36:42 0.8
2013-03-11_22:39:14 0.2
2013-03-11_22:41:47 0.0
2013-03-11_22:46:52 0.2
#8:::
fhem>
Jetzt scheiter ich nur noch daran die obige Ausgabe z.B. in dieser Art zu verarbeiten:
| grep ^[0-9] | perl -ane '$i += 1; $cum += $F[1]; printf ("Nr: %d: Wert: %0.1f Sum: %0.1f MW: %0.1f\n", $i, $F[1], $cum, $cum/$i)'
bzw. mir einfach nur den (letzten) Mittelwert ausgeben oder in eine Variable zu packen? Aber da hörts bei mir auf mit perl...
Wie könnte man das elegant lösen?
Beste Grüße
// tetzlav
Soooo... ;)
Ich habe noch ein bisschen weiter gefrickelt und nun bin ich in der Lage einen Mittelwert, hier z.B. der Windgeschwindigkeit der letzten Stunde, über einen dummy in ein Logfile zu schreiben.
So schauen meine Definition in der fhem.cfg aus:
define KS300_W dummy
define KS300_W_notify notify KS300:wind.* {\
my $period_s = strftime("%%Y-%%m-%%d\x5f%%H:%%M:%%S", localtime(time-3600));;\
my $period_e = strftime("%%Y-%%m-%%d\x5f%%H:%%M:%%S", localtime);;\
my @@logdata = split("\n", fhem("get FileLog_KS300 - - $period_s $period_e 8:::"));;\
my ($cnt,$cum,$avg) = (0)x3;;\
foreach (@@logdata){\
my @@line = split(" ", $_);;\
if("$line[1]" ne ""){\
$cnt += 1;;\
$cum += $line[1];;\
}\
}\
if("$cnt" > 0){$avg = sprintf("%%0.1f", $cum/$cnt)}\
Log 1, ("K300_W: von $period_s bis $period_e, Count: $cnt, Cum: $cum, Average: $avg");;\
fhem('trigger KS300_W Wc: '.ReadingsVal("KS300","wind","0").' Wlh: '.$avg);;\
}
define FileLog_KS300_W FileLog ./log/KS300_W-%Y.log KS300_W.*
attr FileLog_KS300_W logtype text
attr FileLog_KS300_W room Logs
Jetzt wollte ich das auch gerne für andere Logs verwenden und eine eigene Funktion in 99_MyUlils.pm ablegen.
Meine 99_MyUlils.pm schaut erstmal angelehnt an obigen Code wie folgt aus:
package main;
use strict;
use warnings;
use POSIX;
sub
MyUtils_Initialize($$)
{
my ($hash) = @_;
}
##########################################################
# myAverage
# berechnet den Mittelwert aus LogFiles über einen beliebigen Zeitraum
sub
myAverage($$$)
{
my ($offset,$logfile,$cspec) = @_;
my $period_s = strftime("%Y-%m-%d\x5f%H:%M:%S", localtime(time-$offset));
my $period_e = strftime("%Y-%m-%d\x5f%H:%M:%S", localtime);
my @logdata = split("\n", {fhem("get $logfile - - $period_s $period_e $cspec")});
open(DEBUG, ">>log/DEBUG.log");
printf DEBUG "Logdata: %s\n", @logdata;
close(DEBUG);
my ($cnt,$cum,$avg) = (0)x3;
foreach (@logdata){
my @line = split(" ", $_);
if("$line[1]" ne ""){
$cnt += 1;
$cum += $line[1];
}
}
if("$cnt" > 0){$avg = sprintf("%0.1f", $cum/$cnt)};
Log 1, ("myAverage: File: $logfile, Field: $cspec, Period: $period_s bis $period_e, Count: $cnt, Cum: $cum, Average: $avg");
return $avg;
}
1;
Jetzt habe ich nur das Problem, dass das Array @logdata leider leer bleibt. Das liegt vermutlich daran, dass ich den Aufruf von
fhem("get $logfile - - $period_s $period_e $cspec")
in {} packen muss und dann stimmt der Ausgabepfad nicht.
Generell würde ich ja lieber die Funktion FileLog_Get() aus 92_FileLog.pm direkt aufrufen, aber da scheitere ich an der hash-Tabelle und bin mit meinem perl am Ende...
Kann mir mal bitte jmd. auf die Sprünge helfen? :)
// tetzlav
Hallo tetzlav,
kannst Du noch mal posten wie Du die Routine aus FHEM aufrufst?
Viele Grüße
Niko
Hallo Nico,
Naja, vorerst zum testen vorerst über die fhem-telnet-Console. Z.B. so:
fhem> {myAverage("3600", "FileLog_KS300", "8:::")}
Odd number of elements in anonymous hash at ./FHEM/99_MyUtils.pm line 22.
1
fhem>
Als Rückgabewert würde ich den Durchschnittswert erwarten, wobei mir jetzt auch das erste mal diese Fehlermeldung untergekommen ist.
Kommt wohl darauf an, auf welcher Console der fhem-Server gestartet wurde...
Grüße
Hallo tetzlav,
zunächst einmal vorab, ich bin noch relativ neu hier, kenne mich also mit FHEM und Perl noch nicht so richtig gut aus. Gerade deshalb hat mich Deine Funktion aber interessiert, weil ich hier noch etwas lernen konnte.
Ich habe das Ganze über die FHEM Oberfläche probiert, also nicht wie Du über Telnet.
Hier gibt mir Dein Statement "my @logdata = split("\n", {fhem("get $logfile - - $period_s $period_e $cspec")});"
einen Wert / Verweis in der Art "HASH(0xbf7628)" zurück (Geprüft mit "foreach(@logdata) {Log 2, "$_";}.
Lasse ich die {} in Deinem Statement weg, also "my @logdata = split("\n", fhem("get $logfile - - $period_s $period_e $cspec"));"
bekomme ich die Werte und damit auch den Mittelwert.
Ich habe FHEM auf einer Fritzbox 7390 laufen.
Ich hoffe dies hilft Dir weiter.
Viele Grüße
Niko
Vielen Dank!
Die geschweiften Klammern waren das Problem. Ich dachte die sind notwendig und ich war der Meinung es auch ohne getestet zu haben.
Naja, wie auch immer, es funktioniert jetzt bestens.
Dokumentiert habe ich meine Funktion und Vorhaben im Wiki (//www.fhemwiki.de/wiki/Relative_Mittelwerte_berechnen_und_loggen).
Grüße
// tetzlav
Hallo tetzlav,
Es kommt vermutlich etwas spät, aber vielleicht hilft dir in Zukunft das hier weiter:
Link (http://forum.fhem.de/index.php?topic=10439.msg69157#msg69157)
Grüße,
Johannes
Hallo,
ich habe den Code myAverage() von tetzlav in die 99_myUtils.pm angelegt und bin soweit begeistert. Allerdings wird mir bei jeder Ausführung das Logfile mit allen Werten aus der Logdatei vollgeschrieben.
2013-06-02_17:59:36 14::: : 2013-06-02_17:00:03 23.5
2013.06.02 17:59:36 3: get A_WaermepumpeLog - - 2013-06-02_16:59:36
2013-06-02_17:00:33 23.5
2013-06-02_17:01:03 23.5
2013-06-02_17:01:33 23.5
2013-06-02_17:02:03 23.5
2013-06-02_17:02:33 23.5
2013-06-02_17:03:03 23.5
..............
package main;
use strict;
use warnings;
use POSIX;
sub
MyUtils_Initialize($$)
{
my ($hash) = @_;
}
##########################################################
# myAverage
# berechnet den Mittelwert aus LogFiles über einen beliebigen Zeitraum
sub
myAverage($$$)
{
my ($offset,$logfile,$cspec) = @_;
my $period_s = strftime "%Y-%m-%d\x5f%H:%M:%S", localtime(time-$offset);
my $period_e = strftime "%Y-%m-%d\x5f%H:%M:%S", localtime;
my @logdata = split("\n", fhem("get $logfile - - $period_s $period_e $cspec"));
my ($cnt, $cum, $avg) = (0)x3;
foreach (@logdata){
my @line = split(" ", $_);
if(defined $line[1] && "$line[1]" ne ""){
$cnt += 1;
$cum += $line[1];
}
}
if("$cnt" > 0){$avg = sprintf("%0.1f", $cum/$cnt)};
Log 4, ("myAverage: File: $logfile, Field: $cspec, Period: $period_s bis $period_e, Count: $cnt, Cum: $cum, Average: $avg");
return $avg;
}
##########################################################
1;
Jetzt dachte ich mir, wenn man diese Zeile entnimmt:
Log 4, ("myAverage: File: $logfile, Field: $cspec, Period: $period_s bis $period_e, Count: $cnt, Cum: $cum, Average: $avg");
bleiben die Einträge dann weg. Tut es aber nicht. Ich gehe jetzt davon aus, es kommt von der Zeile:
fhem("get $logfile - - $period_s $period_e $cspec")
Gibt es hier eine Möglichkeit, dass die Einträge im Logfile ausbleiben?
Danke
Gruß,
TinoB
Hallo,
für mich als Laien sieht das
fhem("get $logfile - - $period_s $period_e $cspec")
so aus das fhem nur aus der Datei liest.
Hast du nach dem auskommentieren des Log 4,"( ...
mal ein reload der 99_myUtils.pm durchgeführt?
Grüße
Hallo Puschel,
ja ein Reload hatte ich durchgeführt. Auch zur Vorsicht ein shutdown restart. Hat nichts gebracht. Habe dann auch mehrfach geprüft, dass der Eintrag auch wirklich entfernt ist, manchmal denkt man ja es hat nicht funktioniert ;-)
Für mich sieht es ebenfalls so aus, als werden die Daten nur mit
fhem("get $logfile - - $period_s $period_e $cspec")
gelesen. Und mit dem Log Eintrag in's Logfile geschrieben. Aber das Entfernen hat bisher nichts bewirkt.
Danke
Gruß,
TinoB
Hallo,
Auszug aus deinem Logfile-Post:
Zitat2013-06-02_17:59:36 14::: : 2013-06-02_17:00:03 23.5
2013.06.02 17:59:36 3: get A_WaermepumpeLog - - 2013-06-02_16:59:36
Wenn ich das richtig deute wird bei dir einmal ein Logeintrag mit
Log 14,(" ....") und einmal mit
Log 3,(" ....") erzeugt.
Bei ersterem kann ich mich täuschen da ich 14 noch nicht gesehen habe.
Bei zweiterem bin ich mir ziemlich sicher.
Poste mal bitte den Code mit dem du die Subroutine aufrufst.
Grüße
Hallo Puschel,
hier mein Code zum Aufruf. Jede Stunde wird ein Mittelwert aus den Einträgen der letzten Stunde im Logfile ermittelt:
define h_mittelwert_aufruf at +*01:00:00 {\
my $avg_h_at = myAverage("3600", "A_WaermepumpeLog", "4:::");;\
fhem("set A_H_AVG_AT $avg_h_at °C");;\
my $avg_h_rlt = myAverage("3600", "A_WaermepumpeLog", "6:::");;\
fhem("set A_H_AVG_RLT $avg_h_rlt °C");;\
my $avg_h_wwt = myAverage("3600", "A_WaermepumpeLog", "8:::");;\
fhem("set A_H_AVG_WWT $avg_h_wwt °C");;\
my $avg_h_vlt = myAverage("3600", "A_WaermepumpeLog", "10:::");;\
fhem("set A_H_AVG_VLT $avg_h_vlt °C");;\
my $avg_h_rt = myAverage("3600", "A_WaermepumpeLog", "12:::");;\
fhem("set A_H_AVG_RT $avg_h_rt °C");;\
my $avg_h_rls = myAverage("3600", "A_WaermepumpeLog", "14:::");;\
fhem("set A_H_AVG_RLS $avg_h_rls °C");;\
my $wert= "AT $avg_h_at RLT $avg_h_rlt WWT $avg_h_wwt VLT $avg_h_vlt RT $avg_h_rt RLS $avg_h_rls";;\
fhem("trigger A_H_AVG $wert");;\
}
Die ermittelten Werte werden dann wiederum in ein eigens Logfile geschrieben.
Die 14 wie auch die 4, 6, 8, 10, 12 ist die Spalte aus dem Logeintrag wo der Wert zur Berechnung entnommen wird.
Danke
Gruß,
TinoB
Hallo,
fast wär ich drauf rein gefallen ;-)
Zitat2013-06-02_17:59:36 14::: : 2013-06-02_17:00:03 23.5
2013.06.02 17:59:36 3: get A_WaermepumpeLog - - 2013-06-02_16:59:36
2013-06-02_17:00:33 23.5
2013-06-02_17:01:03 23.5
2013-06-02_17:01:33 23.5
2013-06-02_17:02:03 23.5
2013-06-02_17:02:33 23.5
2013-06-02_17:03:03 23.5
Also die Zeitpunkte der Einträge sehen ja sehr eigenartig aus.
Erst um 17:59 und dann ab 17:00 aufwärts.
Welche Logeinträge stören dich den jetzt genau (und warum stören die)?
Grüße
Hallo,
im Prinzip alle :-)
Also um 17:59:36 ist gerade eine Stunde um und da wird der Aufruf ausgeführt. Dann werden alle Einträge aus dem Logfile "A_WaermepumpeLog" der letzten Stunde (in diesem Beispiel von 16:59 bis 17:59) abgefragt und daraus der Mittelwert gebildet. Allerdings, und das ist das Problem, werden alle Werte aus dem gespeicherten Logfile "A_WaermepumpeLog" in das allgemeine fhem Logfile ebenfalls übernommen und aufgelistet. Was ja wiederum bedeutet, dass die Größe des Files bei jeder Abfrage zunimmt und das in diesem Fall jede Stunde. Das ist natürlich unschön und muss nicht sein.
Danke
Gruß,
TinoB
Hallo,
ZitatDas ist natürlich unschön und muss nicht sein.
Dem stimme ich dir zu - aber ich weiß dafür keine Lösung.
Versuch mal
attr global verbose 2zu setzen.
Evtl. ist ja dann Ruhe (wobei die Logeinträge ja keine Nummer haben und daher evtl. nicht unterdrückt werden können).
Sorry, aber da bin ich mal aufgrund Unwissenheit leider raus (aber ich les noch mit weil ich gerne dazu lerne).
Grüße
Hallo,
ZitatVersuch mal
attr global verbose 2
zu setzen.
Evtl. ist ja dann Ruhe (wobei die Logeinträge ja keine Nummer haben und daher evtl. nicht unterdrückt werden können).
Sorry, aber da bin ich mal aufgrund Unwissenheit leider raus (aber ich les noch mit weil ich gerne dazu lerne).
Grüße
attr global verbose 2Damit sind die Einträge zunächst weg. Das hilft zumindest erstmal um die Einträge zu verringern. Und ja genau das ist das Problem was ich ebenfalls sehe, die Logeinträge haben keine Nummer. Von daher nehme ich an, dass diese durch die fhem Dateiabfrage kommen.
Ja ich lese auch überall mit, da ich ebenfalls noch ziemlich unwissend bin. In diesem Fall hatte ich bereits eine andere Art der Mittelwertermittlung programmiert. Allerdings finde ich diese aus einem Logfile recht gut, da man hierüber mehr Möglichkeiten hat.
Danke
Gruß,
TinoB
Hallo,
wofür brauchst du die Mittelwerte?
Schreibst du die wieder in das Logfile?
Brauchst du die nur zur Anzeige?
Dann solltest du dir evtl. mal eine andere Möglichkeit der Plot-Darstellung anschauen - aber das kommt auf deine Hardware an auf der fhem läuft.
Grüße
Hallo Puschel,
ja richtig. Diese werden wieder in ein Logfile geschrieben.
Ich habe eine Fritzbox. Diese Entscheidung hatte ich getroffen um 1. zunächst erst einmal ein Gefühl für das System fhem zu bekommen und 2. der einfachere Einstieg gegenüber einem anderen System ist. Ob ein Raspi besser ist, kann ich nicht beurteilen. Nachteil der Fritzbox ist halt, der Prozessor stößt an seine Grenzen da dieser ja noch etwas anderes zu tun halt als fhem :-)
Einen Vorteil dieser Art der Speicherung der Logfiles, sehe ich in der Dateigröße. Das System mit einer Datenbank verbraucht einges mehr an Speicherplatz. Das wohl zu bevorzugenste System ist die RRD Datenbank. Diese benötigt wenig Speicherplatz und die Daten können schnell abgerufen werden. Allerdings kenne ich mich damit noch nicht aus.
Hier mal ein Auszug aus einer Grafik von der Heizung bisher. Mal sehen was man damit noch so auslesen kann.
Plotergebnis (//forum.fhem.de/index.php?t=getfile&id=3770&private=0)
Gruß,
TinoB
Hallo,
also ein RasPi ist gut angelegtes Geld (für das Geld) - wenn man das so bezeichnen kann (finde ich).
Ich hab sqlite3 am RasPi laufen der selbst die Daten von 3 I2C-Sensoren abfragt und per FHEM2FHEM mit meinem Main-FHEM-RasPi verbunden ist.
Obwohl das alles auf einem RasPi laufen könnte - aber wo bleibt der Spieltrieb^^
Von dort bekommet er alle Daten per FHEM2FHEM geliefert und schreibt die auf seine SD-Karte weg.
Per Chart-Frontend greife ich auf die Daten des 2. RasPi zu (der mit den I2C-Sensoren) und suche mir gemütlich aus was ich sehen will.
Tagesplot - hätte ich gerne die zeitnahen Werte der Sensoren (je nach Sensor auch der Hour-Sum bzw. -Avg).
Wochenplot - reicht mir bei Strom/Gas/Wasser der Day-Sum (also der täglich summierte) Wert oder Day-Avg (also Durchschnitt) bei Temperatur/Feuchte.
Monatsplot - reicht mir der Week-Sum/Week-Avg (oder auch mal Day-Sum/Day-Avg wenn ich Zeit habe) aber da sieht man dann (für mein Empfinden) zuviel (oder zuwenig - je nach Sichtweise).
Jahresplot - ... (the same)
Wenn du eine 7390 hast gibt es von Juri (glaube ich) eine Anleitung wie du das Chart-Frontend installiert bekommst.
Wenn du dir einen RasPi zulegen willst gibt es von mir eine "Anleitung" (so schwer ist das zum Glück nicht) wie du sqlite3 zum laufen bekommst.
Wenn die Daten mal gesammelt sind kommen erst die Wünsche die Erkenntnisse auch in die Steuerung einfliessen zu lassen.
Nur als Beispiel (nicht zur Nachahmung empfohlen ;-) ).
Ich war so frei und hab mir den Strombedarf unserer Laptops an einem CUL_EM geloggt.
Danach eine FS20-ST davor und seither habe ich eine Ladeschaltung programmiert die unsere Laptops aufladet.
Wenn kein Ladebedarf besteht schaltet die FS20-ST wieder aus und wenn Strom gezogen wird wird geladen bis ein programmierter Wert unterschritten wird.
Das sieht dann so aus:
(siehe Anhang / see attachement)
Ohne das Frontend wäre ich nie soweit gekommen weil ich einfach nur zu faul bin um mich in die Interna von den Fhem-Plots einzulesen (und weil ich auch zu faul war auf Jahreslogs umzustellen - diese hab ich aber mittlerweile in der DB ;-) ).
Nur ist die Auswahl an zu sehenden Daten im Frontend einfacher gelöst - finde ich (sorry Rudi - wobei da ja mittlerweise einiges gegangen ist).
Aber jeder sollte das machen was er für besser empfindet - bis er was anderes sieht ;-)
Grüße
Hi,
ja das mit dem Raspi habe ich mir auch schon für den kommenden Winter vorgenommen. Vorher wird das im Momoment nichts. Das Chart Frontend habe ich zum Testen auf einem Ubuntu PC laufen.
Hast Du das sqlite3 im Wiki? Sorry, ich habe jetzt nicht nachgesehen. Wie werden die Logfiles dann gespeichert? Also in welchem Format? Und damit kann man dann die Durchschnittswerte gleich komplett auslesen?
Von der Sache benötige ich das System nicht zum Spielen, sondern Endziel muss ein Energiemanagement sein. PV-Anlage, Beschattung, Wärmepumpe, Lüftung, Stromzähler einbinden und entprechend Verbraucher wenn möglich in eine andere Uhrzeit verschieben etc. ... Keine Spielerein mit Licht schalten. Bei der Lüftung und Wärmepumpe sieht es schon recht gut aus. An der PV-Anlage hängt es gerade.
Wenn ich dann immer einen Schritt weiter bin, muss das natürlich in's Wiki. Zumindest habe ich mir das so vorgenommen ;-)
Gruß,
TinoB
Hallo,
Johannes hat den Wiki-Eintrag gemacht.
Ich war nur so frei und hab meinen klitzekleinen Beitrag für den RasPi dazu geleistet:
http://www.fhemwiki.de/wiki/Neues_Charting_Frontend (//www.fhemwiki.de/wiki/Neues_Charting_Frontend)
Wenn du etwas nach unten scrollst hast du die Anleitung von Puschel ^^
Das sollte aber evtl. auch auf Ubuntu (Wheezy ist ja Debian) übertragbar sein wenn die Pfade nicht all zu sehr abweichen.
Sonst findest du sicher ne Installationsanleitung für sqlite3 im Netz für Ubuntu.
Grüße
Hallo,
ich nutze seit gestern ebenfalls die Funktion myAverage aus dem Wiki (http://www.fhemwiki.de/wiki/Relative_Mittelwerte_berechnen_und_loggen (//www.fhemwiki.de/wiki/Relative_Mittelwerte_berechnen_und_loggen)).
Hat jemand inzwischen eine Lösung gefunden, dass verhindert wird, dass die Einträge vom FileLog noch einmal ins FHEM-Log geschrieben werden?
Ich errechne alle 20 Minuten einen Mittelwert der letzten 3 Stunden und das füllt das FHEM-Log doch sehr.
global verbose auf 2 zu setzen ist keine wirklich Option, da ich damit auch andere Meldungen unterdrücke.
Komisch ist, dass nur in das FHEM-Log geschrieben wird, wenn die Funktion myAverage() aufgerufen wird. Führe ich zum testen den get-Befehle manuell aus, wird das nicht ins FHEM-Log geschrieben. Scheint also irgendwie an der Kombination zu liegen, dass der get-Befehle aus der Routing myAverage kommt, welche in der 99_myUtils.pm liegt.
Grüße, Tobias
Ich habe da auch mal etwas tiefer in den Perl-Untiefen von FHEM gestöbert, aber leider noch keine Lösung gefunden.
Ich verstehe auch nicht von welchem Codeteil genau das Schreiben ins Logfile getriqqert wird und warum es bei Loglevel 2 nicht mehr erfolgt. Vllt. liest hier jmd. mit der fhem besser kennt als ich...
Hallo,
Ich hatte das gleiche Problem und habe den Code wie folgt geändert:
Die Zeile
my @logdata = split("\n", fhem("get $logfile - - $period_s $period_e $cspec"));
habe ich durch
my $oll = $attr{global}{verbose};
$attr{global}{verbose} = 0;
my @logdata = split("\n", fhem("get $logfile - - $period_s $period_e $cspec"));
$attr{global}{verbose} = $oll;
ersetzt (aus 01_FHEMWEB.pm abgeschaut). Dadurch wird temporär Verbose auf 0 gesetzt und es erscheinen keine Einträge im Log. Der ursprüngliche Wert wird nach dem Aufruf des Get sofort wieder zurückgesetzt.
Grüße,
ChrisD
Zitat von: ChrisD schrieb am Mo, 12 August 2013 20:38 my $oll = $attr{global}{verbose};
$attr{global}{verbose} = 0;
my @logdata = split("\n", fhem("get $logfile - - $period_s $period_e $cspec"));
$attr{global}{verbose} = $oll;
Nicht wirklich schön, aber funktioniert. Vielen Dank! Habs gleich im Wiki angepasst...
Hallo,
ich versuche auch einen Mittelwert zu berechnen :D
Allerdings verstehe ich die Definition der $cspec nicht und habe auch nichts gefunden.
Mein Logfile sieht ca. so aus:
2014-04-08_20:45:47 KWL_Pdiff_KWL -0.03
2014-04-08_20:55:47 KWL_Pdiff_KWL 0.03
2014-04-08_21:05:48 KWL_Pdiff_KWL 0.04
2014-04-08_21:15:48 KWL_Pdiff_KWL 0.04
Ich hätte erwartet, dass mit:
{myAverage("7200", "KWL_Pdiff-2014.log", "KWL_Pdiff_KWL:")}
my average antwortet aber:
2014.04.08 21:32:12 3: myAverage: File: KWL_Pdiff-2014.log, Field: KWL_Pdiff_KWL:, Period: 2014-04-08_19:32:12 bis 2014-04-08_21:32:12, Count: 1, Cum: 0, Average: 0.0
weiß jemand, wie cspec funktioniert, oder was ich einstellen muss?
Jan
Hallo swifty,
wenn Du nur die Werte von einem Device im Logfile hast, funktioniert es so. Allerdings darfst Du nicht den Dateinamen (KWL_Pdiff-2014.log) vom Logfile, sondern nur den Namen eintragen.
{myAverage("7200", "KWL_Pdiff-2014.log", "3:::")}
Wenn es jedoch Werte von mehreren Device vorhanden sind (wie in dem anderen Thread), dann funktioniert es nicht. Dafür suche ich noch eine Lösung.
Gruß,
Tino
danke.
die Definition habe ich gerade doch noch gefunden, steht sogar in der command ref unter Filelog...
http://192.168.178.52:8083/fhem/docs/commandref.html#FileLog (http://192.168.178.52:8083/fhem/docs/commandref.html#FileLog)
Hallo,
bei mir funktioniert es nicht. Aber da ist irgendwo noch etwas anderes faul.
Um mit Logfiles mit verschiedenen devices klarzukommen sollte man glaub ich nur eine regexp einfügen denn die cspec im Filelog sagt:
Syntax: <col>:<regexp>:<default>:<fn>
Also z.B. (ungetestet)
{myAverage("7200", "KWL_Pdiff-2014.log", "3:DeviceName.*::")}
Jan
Hallo swifty,
also wenn Du nur den Eintrag von einem Device im Logfile hast, dann kannst Du den DeviceNamen weglassen.
{myAverage("7200", "KWL_Pdiff-2014.log", "3:::")}
Und dann darfst Du nicht den Namen vom Logfile (KWL_Pdiff-2014.log) eintragen, an der Stelle muss der "Define Namen" stehen.
Gruß,
Tino
Hallo,
nutze auch die Funktion - eigentlich alles sehr schön. Nun wollte ich wie im Wiki beschrieben einen notify anlegen, der bei jeder Temperaturmessung den average ins Logfile schreibt:
define outdoor_temperature_notify notify CUL_HM_HM_WDS10_TH_O_25F996:temperature.* {\
fhem('trigger CUL_HM_HM_WDS10_TH_O_25F996 average-temp: 'myAverage("86400", "FileLog_CUL_HM_HM_WDS10_TH_O_25F996", "4:temperature::"));;\
}
Leider kommt dann immer nur eine Fehlermeldung, wenn der notify aufgerufen wird: outdoor_temperature_notify return value: syntax error at (eval 506) line 2, near "'trigger CUL_HM_HM_WDS10_TH_O_25F996 average-temp: 'myAverage"
Sieht für mich eigentlich alles gut aus - hat jemand nen Tip? Trigger innerhalb eines notify aufzurufen, die noch dazu eine perl Funktion benutzen, scheint nicht soo gängig zu sein, jedenfalls hat meine Suche nix ergeben und ich bin nicht soo der Perl-Experte...
Thanks,
Holger
Hallo,
normalerweise geht das doch fhem(" doppelte Hochkomma. Ich mache auch so etwas, allerdings habe ich einen Dummy angelegt. Dazu eine Logdatei für diesen Dummy. Dann kann ich mit fhem("trigger Dummy Wert") den log schreiben und brauche den Rest nicht. Fand ich übersichtlicher.
Gruß Christoph
Hmm, Problem gelöst - im Wiki-Artikel ist ein kleiner, aber feiner Fehler: vor dem Aufruf der myAverage() Funktion im notify darf kein Leerzeichen stehen, sondern es muss ein Punkt hin, um die Ausgabe der Funktion mit dem Rest des Strings zu verketten...
Interessanter Nebeneffekt: average-temp taucht zwar bei den Events auf, wird aber nicht ins Log geschrieben. Wenn ich den gleichen Trigger von Hand laufen lasse, taucht er auch im Log auf. Falls jemand ne Idee hat, was ich falsch mache...
Könntest Du noch genauer beschreiben, welche Stelle im Wiki (ich nehme an, http://www.fhemwiki.de/wiki/Relative_Mittelwerte_berechnen_und_loggen ist gemeint) wie geändert werden muss? Ich würde dann die Korrektur einbauen.
Gruß, Peter
Gern - die Seite ist die richtige - das Beispiel sieht so aus:
define KS300_T_notify notify KS300:temperature.* {\
fhem('trigger KS300 average-temp: 'myAverage("86400", "FileLog_KS300", "4:::"));;\
}
Bei mir funktioniert es nur so:
define KS300_T_notify notify KS300:temperature.* {\
fhem('trigger KS300 average-temp: '.myAverage("86400", "FileLog_KS300", "4:::"));;\
}
@holgerr: danke ... ich hätte das prompt "falsch korrigiert" (ich hätte nach Deiner Beschreibung das Leerzeichen zwischen dem "...average-temp:" und dem "'myAverage" durch den Punkt ersetzt).
Wiki ist aktualisiert.
Gruß, Peter
Zitat von: holgerr am 20 Mai 2014, 14:16:09
Interessanter Nebeneffekt: average-temp taucht zwar bei den Events auf, wird aber nicht ins Log geschrieben. Wenn ich den gleichen Trigger von Hand laufen lasse, taucht er auch im Log auf. Falls jemand ne Idee hat, was ich falsch mache...
Das Problem exisitiert bei mir auch. Konntest Du es lösen?
VG
Sven
Hallo, ich habe ebenfalls dieses Problem und suche eine Lösung.
Viele Grüße
Ralf
Hallo an alle. Bin ein Einsteiger in FHEM und komme leider nicht weiter mit meiner Markisensteuerung.
Mit Hilfe dieses Thread konnte ich ein Logfile erstellen in dem mir die Windstärke geglättet wird.
2015-04-19_19:14:31 Windschnitt Wc: 2.7 Wlh: 5.3
Hier der Ausschnitt aus meiner .cfg:
Wetter_OC3:windSp.* {
my $period_s = strftime("%%Y-%%m-%%d\x5f%%H:%%M:%%S", localtime(time-600));
my $period_e = strftime("%%Y-%%m-%%d\x5f%%H:%%M:%%S", localtime);
my @@logdata = split("\n", fhem("get FileLog_Wetter_OC3 - - $period_s $period_e 8:::"));
my ($cnt,$cum,$avg) = (0)x3;
foreach (@@logdata){
my @@line = split(" ", $_);
if("$line[1]" ne ""){
$cnt += 1;
$cum += $line[1];
}
}
if("$cnt" > 0){$avg = sprintf("%%0.1f", $cum/$cnt)}
Log 1, ("Windschnitt: von $period_s bis $period_e, Count: $cnt, Cum: $cum, Average: $avg");
fhem('trigger Windschnitt Wc: '.ReadingsVal("Wetter_OC3","windSpeed","0").' Wlh: '.$avg);
}
Wie kann ich jetzt mit Hilfe von "Wlh" ein Device steuern? Ich komme mit Notify und DOIF nicht an den Wert im Logfile. Möchte einen Dummy auf on setzen wenn "Wlh" > x ist.
Hallo,
THRESHOLD mal ansehen das ist eine Schwellwertsteuerung mit Hysterese.
Gruß Christoph
Hallo zusammen,
zugegeben, dieser Thread ist schon relativ lange nicht mehr aktiv gewesen, aber ich bin auf folgendes Problem gestoßen:
MyAverage bildet den Mittelwert innerhalb eines bestimmten Zeitraums, aber berücksichtigt nicht, ob die Werte auch die gleichen zeitlichen Abstände haben. Wenn ich mit event-on-change die Readings nur dann aktualisiere, wenn sich ein Wert geändert hat, kann das zu diesem Problem führen:
Meine Heizung läuft 18 Stunden auf 100% Last und 6 Stunden auf 20% Last. Da die Werte nur zweimal innerhalb von 24h aktualisiert wurden, bildet MyAverage einen Durchschnittswert von ((100+20)/2) = 60%. Es müsste aber eigentlich (100/24*18)+(20/24*6) = 75 + 5 = 80% als Mittelwert angezeigt werden. Anders ausgedrückt müsste die Berechnung bei so lauten: Mittelwert = vorheriger_Mittelwert + (ReadingVal / Zeitraum_in_Sekunden * Zeitraum_in_Sekunden_seit_letzter_Änderung). Die Funktion müsste dazu den jeweils vorherigen Datums-String speichern und in Sekunden umwandeln, da fehlen mir momenten noch die Perl-Kenntnisse, ob das strftime auch andersherum genutzt werden kann.
Macht es Sinn, die Funktion generell entsprechend anzupassen, oder gibt es für die bisherige Mittelwertberechnung, die den Zeitabstand zwischen den Werten außen vor lässt, auch Einsatzbereiche? Wenn Letzteres der Fall ist, wäre es sicher gut, die Funktion mit einem weiteren Parameter entsprechend konfigurierbar zu machen.
Danke auf jeden Fall für dieses Script, das mir bei regelmäßig auftretenden Werten schon viel geholfen hat!
Gruß,
F.
Ok, ich habe selber schon eine Lösung gefunden und stelle das mal hier ein für die, die es interessiert. Wer mag, kann es auch gerne ins Wiki stellen. Als ein Problem blieb noch der Zeitraum zwischen Anfang des Durchschnittszeitraums bis zum ersten erfassten Wert. Das kann z.B. bei der Brenner-Aktivität nachts bzw. tagsüber ja ein längerer Zeitraum mit gleichbleibender Aktivität sein. Ich habe die Funktion daher dahingehend angepasst, dass immer noch ein ganzer Tag vor dem eigentlichen Analysezeitraum eingelesen wird und der letzte Wert vor Beginn der Analyse gespeichert wird, bis dann der erste Wert innerhalb des Analysezeitraums kommt. Für regelmäßig gepollte Werte macht das kaum einen Unterschied, aber bei meiner Auswertung der Brenner-Modulation gerade tagsüber (wenn ich arbeite) bzw. nachts (wenn alle schlafen und die Heizung aus ist) machte das schon einen Unterschied. Wenn auch innerhalb des vorherigen Tages kein Wert gesetzt wurde, dann wird der erste gesetzte Wert innerhalb des Analysezeitraums auf den Beginn des Zeitraums verlängert.
Hier also der Code:
package main;
use strict;
use warnings;
use POSIX;
use Date::Parse;
sub myAverage($$$) {
my ($offset,$logfile,$cspec) = @_;
my $period_s = strftime "%Y-%m-%d\x5f%H:%M:%S", localtime(time-$offset-86400);
my $period_e = strftime "%Y-%m-%d\x5f%H:%M:%S", localtime;
my $oll = $attr{global}{verbose};
$attr{global}{verbose} = 0;
my @logdata = split("\n", fhem("get $logfile - - $period_s $period_e $cspec"));
$attr{global}{verbose} = $oll;
my ($start_time, $end_time, $value, $avg) = (0)x4;
$start_time = time-$offset;
$value = "not___set";
foreach (@logdata){
my @line = split(" ", $_);
if(defined $line[1] && "$line[1]" ne ""){
$end_time = $line[0];
$end_time =~ s/_/T/;
$end_time = str2time($end_time);
if ($end_time >= time-$offset) {
if ($value eq "not___set") { $value = $line[1] }
$avg = $avg + ($value * ($end_time - $start_time) / $offset);
$start_time = $end_time;
}
$value = $line[1];
}
}
$end_time = time;
$avg = $avg + ($value * ($end_time - $start_time) / $offset);
$avg = sprintf("%0.2f", $avg);
Log 4, ("myAverage: File: $logfile, Field: $cspec, Period: $period_s bis $period_e, Average: $avg");
return $avg;
}
Moin,
ich möchte dieses Thema nochmals aufgreifen, da ich an einem Problem schier verzweifle.
Ich habe die myaverage Subroutine aus
https://wiki.fhem.de/wiki/Gleitende_Mittelwerte_berechnen_und_loggen
installiert und sie funktioniert hervorragend.
Das notify habe ich auch aus dem Wiki Beitrag übernommen - und jetzt wird es komisch:
Bei einem Temperatursensor klappt es wunderbar, bei jedem Temperaturreading triggert der notify und schreibt den average Wert in das entsprechende Logfile.
Bei einem weiteren Sensor klappt es ums Verplatzen nicht: der notify triggert bei einem reading, ein average Wert wird berechnet, aber nicht in das Logfile geschrieben.
Ich habe den notify um ein Suchmuster erweitert, um ihn per dummy zu triggern:
define MQTT_notify notify (TempHum:temp.*|enodummy:.*) {fhem('trigger TempHum averagetemp: '.myAverage("86400","TempLog","4:::"))}
Wenn ich ihn mit dem dummy triggere, schreibt er den average in das Logfile, bei trigger durch das Sensorreading nicht...
Hat jemand eine Idee woran das liegen könnte?
Ich bin am Verzweifeln :-|