Liebe FHEM-Profis,
Ich kämpfe momentan mit den Problem, dass mehrere AT-Definitionen nach einen/mehreren MODIFYs in Subroutinen in Perl (99_myUtils.pm) und den notwendigen fhem("save"); verschwinden. Machmal schon beim ersten Durchlauf, machmal auch erst nach mehreren.
Leider habe ich im Forum hier noch keine Lösung meines Problems gefunden (aber auch schon andere User die wohl in die gleiche Falle getappt sind - und sich mit anderen Workarounds beholfen haben).
Hintergrund ist, dass ich z.B. einmal am Tag einen Messwert loggen möchte. Leider kann es aber sein, dass der Sensor dann gerade ein NAN-Reading liefert, was natürlich blöd ist, weil dann der Log-Wert für diesen Tag nutzlos ist.
Also habe ich das momentan wie folgt "gelöst":
define ErtragByTag at *23:10:00 { my $d= ReadingsVal("ESPEasy_ESP_SDM230_Gesamtverbrauch_kWh","Gesamtverbrauch_kWh",0);;;; {subPVErtragLog()}}
In der 99_myUtils.pm sieht das dann so aus:
sub subPVErtragLog(){
my $pv_x= ReadingsVal("ESPEasy_ESP_SDM230_Gesamtverbrauch_kWh","Gesamtverbrauch_kWh",0);
my $pv_delta;
if($pv_x ne "nan") {
$pv_delta= $pv_x - Value("ErtragPV");
fhem("set ErtragPV $pv_x");
fhem("set PV_ErzeugungProTag $pv_delta");
fhem("modify ErtragByTag *23:10:00");
fhem("save");
}
else{
fhem("modify ErtragByTag +00:02:00");
}
}
Dieser Code lief auch mal eine ganze Weile (mehrere Monate) stabil durch... als ich aber vor ein paar Wochen ein Update von FHEM machte und noch ein paar mehr Werte auf diese Art loggen wollte.... seit dem ist der Wurm drin. ???
Sieht jemand den Fehler? ;)
Danke!
Zitat von: _Niemand_ am 11 Februar 2019, 13:09:44
Sieht jemand den Fehler? ;)
überlege mal ganz genau was da passiert : fhem("modify ErtragByTag +00:02:00");
modify erzeugt doch in jedem Fall eine Änderung der Konfiguration aus der gespeicherten Konfiguration?
Fände ich unschön.
An der Idee, das at im Fehlerfall so lange auf 2 min folgend umzudefinieren bis die richtigen Daten empfangen wurden, hätte ich prinzipiell nur auszusetzen, dass in diesem Fall bis zum Emfang gültiger Daten kein save (edit: und/oder restart) ausgeführt werden darf, weil dann eben das at verlorengeht.
Ich würde stattdessen im Fehlerfall ein zusätzliches at definieren und das eigentliche unangetastet lassen.
ah.... danke!
Einfach und genial!
Auf die Idee in der Perl-Routine ein extra AT anzulegen, bin ich nicht gekommen.
Geht das (nebenwirkungsfrei) einfach so:
Im if-Zweig einfach das modify und das save streichen und den else-Zweig sowas wie:
fhem("define MachDasNochmal_PVErtragLog at +00:02:00 {subPVErtragLog()}");
Versuch macht kluch - aber ich würde es auch genau so versuchen.
Nachtrag.... so 100%ig war das noch nicht die Lösung und bevor andere "Anfänger" auch darüber stolpern hier ein Nachtrag:
Erst wenn man im "nan"-Fall, wenn also ein weitere Wiederholung anstellen soll, prüft, ob es sich dabei nicht schon um eine Wiederholung handelt und das schon vorhandene "define" deshalb erstmal löscht, bevor mans erneut "neu" defined - dann klappts ;)
sub subPVErtragLog(){
my $pv_x= ReadingsVal("ESPEasy_ESP_SDM230_Gesamtverbrauch_kWh","Gesamtverbrauch_kWh",0);
my $pv_delta;
fhem("set Dummy_Fehlerlog $pv_x");
if($pv_x ne "nan") {
$pv_delta= $pv_x - Value("ErtragPV");
fhem("set ErtragPV $pv_x");
fhem("set PV_ErzeugungProTag $pv_delta");
}
else{
if (Value("MachtDasNochmal_PVErtragLog") ne "") {
fhem("delete MachtDasNochmal_PVErtragLog");
}
fhem("define MachtDasNochmal_PVErtragLog at +00:02:00 {subPVErtragLog()}");
}
}
Versucht man ein Device (und ein at ist in weiterem Sinne auch eines)in FHEM zu definieren, wenn es schon existiert, dann gibt es eine Fehlermeldung.
Möchte man ein vorhandenes Device ändern, dann kann dafür "defmod" nutzen, es funktioniert ansonsten identisch zu define. "modify" ist wieder eine andere Baustelle.
Im Grunde müsste damit die Prüfung auf ein vorhandenes at obsolet sein, wenn Du stattdessen gleich
fhem("defmod MachtDasNochmal_PVErtragLog at +00:02:00 {subPVErtragLog()}");
verwendest.
Hallo Pfriemler,
danke für den Tipp! Klingt sehr gut... ich werde es mal ausprobieren.
Der Test mit "defmod" war leider nicht erfolgreich - die zweite Wiederholung (also nach den ersten defmod) blieb aus.. warum auch immer :o
Egal, ich habe jetzt wieder die Logik mit der Prüfung auf das vorhandene "at" und den ggf. vorherigen Löschen drin, damit läuft es stabil ;)
Danke für den Test, dann bin ich künftig gewarnt.
Bei mir läuft auch vieles codetechnisch suboptimal, dafür funktioniert es ... :)