Erweiterung: 19_Revolt.pm

[mumpitzstuff]

Leider wird das Revolt Modul nicht weiter gepflegt und der Author ist nicht mehr wirklich erreichbar. Aus diesem Grund habe ich das Modul etwas erweitert und würde mich als Maintainer des Moduls zur Verfügung stellen, wenn es den Weg in die offiziellen Quellen sollte und dort das alte Modul ersetzen sollte.

Bei der Erweiterung geht es hauptsächlich um die Filterung von Fehlübertragungen, ich habe aber auch die Erweiterung von Icebear (Anpassung des Energy Wertes) übernommen. Folgende Dinge wurden geändert:

• Das Attribut EnergyAdjustValue wurde hinzugefügt (danke an Icebear für die Idee). Damit kann der Energy Wert korrigiert bzw. auf 0 gesetzt werden.
• Das state Reading wurde geändert und stattdessen das stateFormat Attribut verwendet. Das entlastet das Logfile erheblich.
• Readings werden plausibilisiert bevor sie angezeigt werden. Sehr große Sprünge in den Werten können dadurch abgefangen werden.
• Das Attribut event-aggregator wird automatisch gesetzt und sorgt für eine weitere Filterung der Werte, so dass hoffentlich auch die letzten Sprünge gefiltert werden.

Über Rückmeldungen würde ich mich freuen.

[mahowi]

Ich werde es mal testen. Am meisten stören momentan die großen Peaks mit unrealistisch hohen Werten.
Wäre schön, wenn das Modul mit Dir wieder einen Maintainer findet.

[rudolfkoenig]

@mumputzstuff: das uebliche Vorgehen bei verweisten Modulen ist, dass man den Autor anschreibt, und wenn man innerhalb von 3 Wochen keine (bzw. keine negative) Rueckmeldung bekommt, dann wird der Maintainerwechsel verkuendet.

Eingetragen sind martinppp und mehf als Autoren: martinppp ist im Forum nicht bekannt, also bitte mehf anschreiben.

[mahowi]

Ich wollte mal eine kurze Rückmeldung geben. 

Ich hab das Modul jetzt seit einer Woche laufen und seitdem keine unrealistischen Peaks mehr. Auch das Attribut EnergyAdjustValue tut was es soll. Damit spare ich mir die UserReadings, in denen ich den Startwert immer abgezogen habe.

Es wäre schön, wenn das Modul so in die offiziellen Quellen übernommen wird.

[sash.sc]

Hallo zusammen.

Habe das Modul auch ausprobiert und musste es wieder gegen das original austauschen.
Bei mir wurden nach ca. 1 Stunde ,nachdem das neue Modul in Betrieb war, keine Daten mehr verarbeitet. Habe dies an der Grafik gesehen. War wie eingefroren.
Mit dem normalen Modul läuft es wieder.


Gesendet von dem teuren ding in meiner hand

[mumpitzstuff]

Ein paar mehr Informationen wären hilfreich. Könnte ich dir vielleicht eine Version geben die ein paar Debuginformationen generiert? Wenn es dann noch einmal stehen bleibt, könnte man relativ schnell sehen woran es liegt. Bin leider am Wochenende unterwegs, wenn du einverstanden bist, würde ich mich nächste Woche bei dir melden.

[sash.sc]

Hört sich gut an.

Dann schönes Wochenende

Gesendet von dem teuren ding in meiner hand

[mumpitzstuff]

Anbei eine Version bei der man erweiterte Loginfos frei schalten kann. Dazu einfach das Verbose Level auf 5 setzen innerhalb des Moduls (funktioniert erst, wenn keine Readings mehr aktualisiert werden). Wenn also keine Daten mehr gelogt werden, dann kann man hiermit sehen woran es liegt. Wenn jemand Probleme hat, dann bitte installieren und mir das Log posten wenn die Readings nicht mehr aktualisiert werden sollten.

[sash.sc]

Danke

Gesendet von dem teuren ding in meiner hand

[sash.sc]

Hallo zusammen.

Habe die modifizierte Datei nicht benutzt.
Das einzige was ich benutzt habe war die Event-aggregator Funktion bzw Attribut.

Damit fallen die Peaks auch weg!

Gesendet von dem teuren ding in meiner hand

[yoda_gh]

Hallo mumpitzstuff!

Ich bin jetzt auch auf Deine Version umgestiegen, vielen Dank dafür! (Ich nutze übrigens einen SIGNALduino.)

Ich frage mich nur, ob man den event-aggregator wirklich in dem Modul setzen möchte? Da ich sehr wenige Werte empfange (je nach Steckdose nur alle paar Minuten), möchte ich eigentlich keine weitere Mittelung haben, damit ich wenigstens halbwegs aktuelle Werte habe.

Ich würde eher vorschlagen, das höchstens als Tipp in die cmdref zu schreiben.

Nebenbei: wenn Du als Maintainer einspringen würdest, fände ich das super - wäre schon schön, wenn das Modul wiederbelebt würde!!

[mumpitzstuff]

Du bekommst mit diesen Einstellungen immer einen Wert, wenn du ein Signal von der Dose bekommst. Der Event Aggregator ist genauso eingestellt, das immer einen Wert liefert, sobald ein neuer rein kommt, nur dass das dann der bemittelte Wert ist.
Du verlierst also nichts und gewinnst eine Menge. Das Modul läuft bei mir schon ewig ohne Probleme.

[yoda_gh]

Ja, das habe ich auch der Doku entnommen. Wenn man allerdings 10 Minuten wartet, um eine Reaktion vom Sensor zu bekommen und dann einen gemittelten Wert sieht, ist das vielleicht nicht, was der unbedarfte User erwartet.

Ich zum Beispiel wollte testen, ob eine der Steckdosen überhaupt was sinnvolles tut und habe dazu unseren Kühlschrank kurz ausgeschaltet. Nach 7 Minuten oder so kam dann endlich eine Messung rein - mit 25 Watt statt den erwarteten < 1 Watt.

Ich war schon kurz davor, die Dose wegzuwerfen, nachdem zu dem ganzen Ärger mit den Empfangsproblemen auch noch eine vermeintliche Falschmessung dazu kam - bis ich mich dunkel erinnerte, etwas über den event-aggregator gelesen zu haben...

(Wobei "Du gewinnst eine Menge" wirklich gestimmt hätte -- mit dem Wegwerfen der Dose hätte ich vermutlich eine Menge Lebenszeit gewonnen, die ich so wieder mit Empfangsproblemen verplempern werde... )

[mumpitzstuff]

Schau dir bitte bei deinen Untersuchungen nicht den Wert avgpower an, der ist totaler Schrott. Habe den nur drin gelassen, weil es bereits drin war, das Reading liefert aber Mondwerte. Nimm immer den direkten Wert power.

[misux]

HI! Ich komme nicht ganz weiter mit den Attributen... Was sollte man denn am besten bei event-aggregator als Wert eintragen?

Ich nutze die Steckdose bei einer Waschmaschine... die hat während des Waschvorgangs mindestens 16Watt Leistungswufnahme und wenn sie fertig ist geht sie auf ca 6Watt. Nun würde ich gerne eine Nachricht bekommen wenn der Wert unter 10Watt fällt, aber bitte nur einmal... Im Moment bekomme ich sogar Meldungen wenn die Waschmaschine aus ist....

Nutze zur Benachrichtigung ein DOIF:

Code Auswählen Erweitern

([Revolt_2125:power] < "10.0") (set Telegram message @xxxxxx Waschmaschine ist fertig!!!!)
DOELSE
()

[sash.sc]

Lasse erst einmal die Anführungszeichen bei der 10.0 weg.

DOELSE brauchst du auch nicht.

Dann probiere mal aus.

Hier meine einfache Definition

Code Auswählen Erweitern


defmod WaMa_fertig DOIF ([WaMa:power] < 5)


Habe noch das wait Attribut gesetzt mit 240:600

Heißt das das Reading Power für 4 Minuten unter 5 Watt sein muss, dann wird die Meldung ausgelöst. Und die 10 Minuten über 5 Watt wenn die Maschine läuft.

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk

[misux]

Lasse erst einmal die Anführungszeichen bei der 10.0 weg.

DOELSE brauchst du auch nicht.

Dann probiere mal aus.

Hier meine einfache Definition

Code Auswählen Erweitern


defmod WaMa_fertig DOIF ([WaMa:power] < 5)


Habe noch das wait Attribut gesetzt mit 240:600

Heißt das das Reading Power für 4 Minuten unter 5 Watt sein muss, dann wird die Meldung ausgelöst. Und die 10 Minuten über 5 Watt wenn die Maschine läuft.

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk

OKAY, vielen Dank erstmal! Bin gespannt!

[yoda_gh]

Hallo mumpitzstuff!

Ich hatte mit Deiner Version von 19_Revolt.pm aus dem initialen Post in der letzten Woche zweimal einen FHEM-Totalabsturz mit

Code Auswählen Erweitern

Illegal division by zero at ./FHEM/19_Revolt.pm line 115.

Die einzige Division, die ich in der Zeile (bzw. in der Fortsetzung in der nächsten Zeile) sehe, ist die hier:

Code Auswählen Erweitern

($power / $voltage / $pf) > 0.00999

Bei $pf stellst Du direkt drüber sicher, dass das nicht 0 ist, also wird wohl $voltage schuld sein. Mein Vorschlag:

Code Auswählen Erweitern


--- /root/19_Revolt.pm 2018-05-11 20:10:49.531467823 +0200
+++ /opt/fhem/FHEM/19_Revolt.pm 2018-05-17 20:36:58.388468523 +0200
@@ -112,7 +112,7 @@
   if (0 == $pf) {
     $pf = 0.0001;
   }
-  if (($freq > 55) || ($power > 3650) || ($current > 16) ||
+  if (($voltage < 80) || ($freq > 65) || ($power > 3650) || ($current > 16) ||
       ((($power / $voltage / $pf) > 0.00999) && (0 == $current)) ||
       ($energydiff > $maxenergy)) {
     $isInvalid = 1;


Laut Wikipedia ist in Japan die Netzspannung mit 100 V am Kleinsten, also sollten wir mit 80 V als Untergrenze auf der sicheren Seite sein. Bei der Gelegenheit habe ich die Obergrenze der Frequenz auf 65 angehoben (USA!).

Nebenbei: hast Du Dir schon überlegt, ob Du das Modul nun übernehmen möchtest? Falls Du in absehbarer Zeit kein Interesse hast, würde ich das machen, bevor es ganz anstaubt... Ich gebe auch gerne wieder ab, wenn Du später Interesse hast...

[mumpitzstuff]

Kannst du gern haben, ich habe keine Zeit dafür. Das mit der Division ist komisch und sollte ja unter normalen Umständen nicht auftreten. Deine Änderung sollte das dann aber zuverlässig abfangen.

[yoda_gh]

Kannst du gern haben, ich habe keine Zeit dafür. Das mit der Division ist komisch und sollte ja unter normalen Umständen nicht auftreten. Deine Änderung sollte das dann aber zuverlässig abfangen.

Wirklich Zeit für die Weiterentwicklung habe ich auch nicht - ich könnte halt zumindest Deine und ggf. weitere Patches einbringen, immer noch besser als der aktuelle Zustand, denke ich... Ich versuche mal nochmal die Original-Autoren zu erreichen und kündige die Übernahme an...

[yoda_gh]

Hallo!

Kannst du gern haben, ich habe keine Zeit dafür. Das mit der Division ist komisch und sollte ja unter normalen Umständen nicht auftreten. Deine Änderung sollte das dann aber zuverlässig abfangen.

Kannst Du mir bitte mal die magische Division erklären? Woher kommt die Konstante 0.00999?

Code Auswählen Erweitern

($power / $voltage / $pf) > 0.00999

Außerdem bin ich über folgendes Problem gestolpert:

Code Auswählen Erweitern

$maxenergy = 3.65 * ($timediff / 3600.0);
[...]
if ... ($energydiff > $maxenergy)) {
    $isInvalid = 1;


Bei mir ist wohl durch einen Übertragungsfehler einmalig ein viel zu kleiner Energy-Wert gespeichert worden. energydiff war wohl negativ und damit hat die Prüfung nicht zugeschlagen.  Ab dann hat sie aber jedesmal zugeschlagen und effektiv verhindert, dass weitere Werte angezeigt wurden. Ich habe schon Antenne und alles mögliche überprüft, bis ich dahinter gekommen bin, dass das Modul jetzt alle empfangenen Werte als ungültig verworfen hat, da ein zu kleiner Energy-Wert gespeichert war und damit energydiff immer zu groß war.

Ein naheliegender Fix wäre, mit Beträgen zu arbeiten und damit auch negative $energydiff-Werte abzufangen.

Ich fürchte aber, dass man durch Anpassen vom EnergyAdjustValue in ähnliche Situationen laufen kann. Generell ist das eine m.E. heikle Prüfung, da sie sich nicht auf "absolute" Wahrheiten bezieht, sondern gegen die lokal gespeicherte Historie prüft, die durch alles mögliche verfälscht werden könnte. Daher würde ich dazu tendieren, die energydiff-Prüfung ersatzlos zu streichen. Was meinst Du?

[mumpitzstuff]

Ich habe noch nicht ganz verstanden weshalb das dann dauerhaft zu einem Problem werden könnte. energydiff rechnet dir immer die Differenz von aktuellem Wert zum letzten Energy wert. Das kann ein positiver oder negativer wert sein. Da ich jetzt immer Ausschläge nach oben hatte, wurden diese Werte damit gefiltert. Mir ist unklar wie ein kleiner Energy Wert dazu führt, dass nichts mehr durch geht. Gib mir mal ein Beispiel in Zahlenwerten bitte.

Die Formel und die Prüfung der Konstante wusste ich mal bzw. habe mir dafür eine Erklärung hergeleitet gehabt, die ich ehrlich gesagt wieder vergessen habe. Diese Prüfung hatte ich aber von hier übernommen:

http://www.sknorrell.de/blog/energiemesssung-mit-revolt-nc-5462/

[yoda_gh]

Ich habe noch nicht ganz verstanden weshalb das dann dauerhaft zu einem Problem werden könnte. energydiff rechnet dir immer die Differenz von aktuellem Wert zum letzten Energy wert. Das kann ein positiver oder negativer wert sein. Da ich jetzt immer Ausschläge nach oben hatte, wurden diese Werte damit gefiltert. Mir ist unklar wie ein kleiner Energy Wert dazu führt, dass nichts mehr durch geht. Gib mir mal ein Beispiel in Zahlenwerten bitte.

Ich habe es noch nicht im Detail im Code nachvollzogen, aber bei mir ist das Energy-Reading vor drei Tagen von c.a.. 597 auf 100 gesprungen. (Wie es der Zufall wollte natürlich genau in einem Zeitraum, wo ich sowohl an der Hardware etwas geändert als auch mit dem event-aggregator gespielt hatte). Vermutlich ein einmaliger Fehler im Empfang, der aber wohl nicht abgefangen wurde, da der Code auf den ersten Blick nur Sprünge nach oben erkennt, richtig?

Und ab dann wurde scheinbar nichts mehr empfangen, weswegen ich alles mögliche überprüft hatte. Bis ich durch Zufall gesehen hab, dass der Zeitstempel der empfangenen Telegramme in den Internals sehr wohl aktualisiert wurde, nur nicht die readings. Nach kurzem Debugging war dann klar, dass jedes neue Telegramm für den Code ungültig war, da der neue Wert 597,x eben ein unzulässiger Sprung nach oben von dem letzten Energy-Reading 100 war. Und siehe da, nach einem "deletereading ... energy" kamen die Daten wieder...

Die Formel und die Prüfung der Konstante wusste ich mal bzw. habe mir dafür eine Erklärung hergeleitet gehabt, die ich ehrlich gesagt wieder vergessen habe. Diese Prüfung hatte ich aber von hier übernommen:

http://www.sknorrell.de/blog/energiemesssung-mit-revolt-nc-5462/

Ah, danke! Dann werde ich das mal als Kommentar hinterlegen. Weiß Michael Bescheid, dass Du seinen Code übernommen hast?

[mumpitzstuff]

Der Code ist nicht übernommen worden. Lediglich der eine Check dort. Ansonsten sollte sich der Code stark unterscheiden.

Das mit dem Energy Reading schau ich mir noch mal an, konnte aber gestern keinen Punkt erkennen, bei dem die Werte wegen einem Reading von 100 gefiltert werden könnten.

[yoda_gh]

Der Code ist nicht übernommen worden. Lediglich der eine Check dort. Ansonsten sollte sich der Code stark unterscheiden.

Ah, ok, gut.

Das mit dem Energy Reading schau ich mir noch mal an, konnte aber gestern keinen Punkt erkennen, bei dem die Werte wegen einem Reading von 100 gefiltert werden könnten.

Vielleicht habe ich auch einen Denkfehler?

Meine Theorie:

• Messwerte treffen ein mit langsam steigenden energy-Werten 597,0x Wh -> alles gut
• Übertragungsfehler: Messwert trifft ein mit energy-Wert 120. Der isInvalid-Check schlägt nicht zu, denn energydiff=120-597, also -477. Und die Bedingung prüft nur, ob  energydiff>maxenergy - und der negative Wert ist eben kleiner als die maxenergy-Grenze.
  
• Reading wird gespeichert, energy ist jetzt 120.
• korrekter Messwert trifft ein mit energy=597,0x Wh. Jetzt ergibt sich: energydiff=597-Reading, also 597-120, also 477. Und das ist größer als das maximal erlaubte Delta für die vergangene Zeitspanne seit dem Übertragungsfehler. isInvalid=1 und der Messwert wird stillschweigend verworfen.
• Dasselbe passiert ab jetzt für alle eintreffenden Messwerte.

Leider sieht man es im Log nicht ganz klar, weil ich zu dem Zeitpunkt mit einem "linear:mean"-event-aggregator für die Werte gespielt habe und damit die Events nur Mittelwerte waren:


2018-05-20_18:40:55 Revolt_Heizung energy: 597.02
2018-05-20_18:40:59 Revolt_Heizung power: 8.70769230769231
2018-05-20_18:40:59 Revolt_Heizung energy: 597.02
2018-05-20_18:41:06 Revolt_Heizung power: 18.05
2018-05-20_18:41:06 Revolt_Heizung energy: 581.332857142857
# Ich denke, hier ist der Wert von ca. 120 Wh reingekommen. Das ist nur einmal passiert, daher sieht man im Log nur
# die geringe Abweichung im Mittelwert nach unten, aber ich habe im Reading einen Wert irgendwas um 100 gesehen.
# Ab hier kommen keine Werte mehr rein.

# Am nächsten Abend bin ich dann draufgekommen und habe das energy-Reading gelöscht. Und sofort ging's weiter.
2018-05-21_20:51:53 Revolt_Heizung power: 8.6
2018-05-21_20:51:53 Revolt_Heizung energy: 597.68
2018-05-21_20:52:58 Revolt_Heizung power: 8.6
2018-05-21_20:52:58 Revolt_Heizung energy: 597.68


Zum Debuggen habe ich am 21.05. auch eine Log-Ausgabe eingebaut:


2018.05.21 20:51:05 5: Revolt_Heizung: received invalid sample: 228 V 50 Hz 8.7 W 597.68 Wh energydiff: 477.68 maxenergy: 1.51326887975468

[mumpitzstuff]

Okay verstanden. Gute Analyse.

Dann sollte man tatsächlich die Abfrage hinzufügen, ob $energydiff positiv also größer 0 ist. Tendenziell darf der Wert ja nur 0 sein oder größer sein als 0. Richtig? Ausbauen würde ich den Check nicht. Ohne diesen Check hatte ich immer recht große Sprünge in den Werten. Zwar immer im erlaubten Rahmen, aber sie haben mir trotzdem die Charts kaputt gemacht. An der Stelle muss man dann vielleicht auch noch aufpassen was passiert, wenn man den Wert mal auf 0 setzen sollte. Da hatte ich doch auch so ein Attribut mit drin...

[yoda_gh]

Ja, mir ist klar, warum Du den Check haben möchtest und die Prüfung auf negative Werte macht auf den ersten Blick Sinn. Aber was ist mit Änderungen vom EnergyAdjustValue? Oder vielleicht vergessen die Steckdosen doch ab und zu den gespeicherten Wert und zählen wieder ab 0? Das würde auch zu Sprüngen im energy-Readung und ggf. zu ähnlichen Fehlern führen, oder? Trauen wir uns zu, hier alle Fälle, die das Reading beeinflussen könnten, zu bedenken und korrekt abzufangen?

Ich finde es unglücklich, dass durch solche einmaligen Fehler, woher sie auch immer kommen mögen, dauerhaft und stillschweigend keine Werte mehr angezeigt werden und der User sich einen Ast sucht nach der Ursache. Ich habe in meiner Verzweiflung, weil plötzlich keine Werte mehr kamen, angefangen, Türen im Keller (dort ist die Revolt-Steckdose) systematisch auf und zu zu machen, weil das ja vielleicht Funk-Reflexionen verändert haben könnte... Dann doch lieber ab und zu ein kaputter Chart...

Wenn wir so einen Check haben, dann sollten wir wenigstens einen Error-Counter in den Internals haben, der dem User deutlich zeigt, dass zwar Nachrichten empfangen werden, aber diese verworfen werden - am besten mit einem String in einem weiteren Internal, der ihm erklärt, warum...

[mumpitzstuff]

Das mit dem Error gefällt mir gut. Allerdings würde ich da keinen Counter hinterlegen, sondern lediglich filtered oder so rein schreiben. An dem Zeitstempel sieht man dann sehr schnell das da ständig was gefiltert wird. Das ist dann aber lediglich ein Indikator das was schief läuft, die Ursache ist dadurch ja nicht behoben.

Ich muss gucken wann ich etwas Zeit finde mich da mal wieder genauer rein zu denken. Ist auf jeden Fall irgendwie alles Kacke mit dem filtern und rumrechnen. Da ich den Adjust Wert nie gesetzt hatte ist mir damals leider nicht aufgefallen, dass das gar nicht mehr richtig geht. Wenn nicht, dann wirf die Prüfung erst mal raus und guck was dann bei dir passiert. Vielleicht sind ja die Sprünge auch gar nicht mehr so groß bzw. werden durch den Event Aggregator bereits gefiltert. Ich habe damals die ganzen Filter schrittweise implementiert und der Eventfilter kam als letztes. Kann sein das der allein bereits ausreichend ist oder du einfach die Zeit etwas hoch setzen musst und damit alle Probleme erschlagen kannst.

[yoda_gh]

So, ich habe Deine Änderungen jetzt mal ins SVN übernommen, danke nochmal, mumpitzstuff! Nur den Plausi-Check für die Energy-Sprünge habe ich aus den hier diskutierten Gründen erstmal entfernt.

Nebenbei habe ich auch die avgpower-Readings entsorgt.

[mumpitzstuff]

Super. Das Attribut war eh der größte Müll.

[yoda_gh]

So, habe mir das nochmal durch den Kopf gehen lassen und mich entschieden, das automatische Setzen vom event-aggregator wieder rauszunehmen, damit niemand verwirrt wird, sorry. Stattdessen weise ich in der Doku aber deutlich darauf hin, dass das dringend empfohlen wird.

Zumal ich auch kein anderes FHEM-Modul gefunden habe, was das macht.

Damit bin ich erstmal mit meienn Überarbeitungen fertig - im Wesentlichen ist es Deine hier gepostete Version, mumpitzstuff (nochmal danke dafür an Dich und Icebear!!) mit folgenden Änderungen:

• avgpower entfernt
• Fix Plausi-Check, damit FHEM bei voltage=0 nicht abstürzt
• Plausi-Check für energy basierend auf der lokal gespeicherten Historie rausgenommen
• event-aggregator wird nicht automatisch gesetzt, dafür Problem deutlich dokumentiert

Nebenbei: wusstest Du, dass der Energy-Wert bei 655kWh auf 0 springt? Ich hatte mich über die komische Grenze gewundert, bis ich gesehen habe, dass es genau gesagt bei 655,35kWh passiert. Eigentlich sollte man das auch im Modul irgendwie behandeln - aber dafür fehlt mir aktuell die Zeit - aber in guter Open Source Tradition: Patches welcome.

[mumpitzstuff]

Wird ein Überlauf bei 65535 sein, also bei 16bit. Ist schon Lustig.