Stundenmittelwerte ermitteln und in Log schreiben

Begonnen von tetzlav, 11 März 2013, 23:05:32

Vorheriges Thema - Nächstes Thema

holgerr

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

Bennemannc

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
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

holgerr

#32
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...

holgerr

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

ph1959de

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
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

holgerr

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:::"));;\
}


ph1959de

@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
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

SvenJust

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
FTUI, Raspberry PI/SSD, CUL CC1101, HMLAN, 10x HM-LC-Bl1PBU-FM, HM-LC-Sw4-WM (KWL Pluggit P300), HM-WDS30-OT2-SM (Sonnensensor), HM-Sec-SCo, LW-12 Wifi LED, CUL Selbstbau nanoCUL 433 (IT), Arduino (S0-Stromverbrauch), OW DS2480 (OWX_ASYNC) 8x DS18B20, MQTT (Fröling P4), MYSENSORS (Roto Rollläden)

DH1FR

Hallo, ich habe ebenfalls dieses Problem und suche eine Lösung.

Viele Grüße

Ralf

Pleitegeier

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.

Bennemannc

Hallo,

THRESHOLD mal ansehen das ist eine Schwellwertsteuerung mit Hysterese.

Gruß Christoph
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

freetz

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.
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

freetz

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;
}
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

PeterKramer

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 :-|
fhem auf RasPi3, FTUI auf Ipad mini, MAX Cube, 5 MAX Thermostate, EnOcean TCM, EnOcean Temperatursensor, ESP8266 Temp. und Feuchtesensor