Lernkurve und offene Fragen anhand der Anbindung eines Energiezählers

[perluser]

Ich möchte von meiner Lernkurve berichten und offene Fragen stellen.

Mein Ziel war es den Haus Energiezähler statistisch zu erfassen, um eine bessere Übersicht über den täglichen Verbrauch zu bekommen.
Ein Energieverbrauchszähler EMH ED300L wird per IR/Optokopler via USB an einem RPI ausgelesen. Es kommt FHEM 6.1 zum Einsatz.

FHEM war schnell installiert, das Aktivieren der Transportverschlüsselung TLSv1.3 und Passwortschutz der Oberfläche ging dank wiki auch flott.
Danach habe ich länger geknobelt, wie die config Struktur aufgebaut ist und nach welchen Namenskonventionen die einzelnen Objektnamen am Besten angelegt werden sollten.
Ich habe mich für das Unterstrich "_" als Trennzeichen entschieden, um ggf. ungewohlte Interpretation durch Regex bei Verwendung von Punkt,Leerzeichen,Semikolon,etc zu vermeiden.
Strukturiert/geordnet wird von links nach rechts,von abstrakt nach konkret.

a)  Als Erstes wurde der Optokopler als OBIS Gerät, welches SML spricht, konfiguriert, das ging dank wiki einfach.

Code Auswählen Erweitern


define device_ed300l OBIS /dev/ttyUSB0@9600,8,N,1 SML
attr device_ed300l alias EMH ED300L
attr device_ed300l event-aggregator power:10:linear:mean,total_consumption:10:none:v
attr device_ed300l event-min-interval usage:10
attr device_ed300l group Energiezähler
attr device_ed300l room Energiezähler
attr device_ed300l stateFormat {sprintf("%.0f W / %.0f kWh / %s",ReadingsVal($name,"power",0),(ReadingsVal($name,"total_consumption",0)/1000),ReadingsVal($name,"state",0))}
attr device_ed300l userReadings usage { sprintf("%.1f %.1f",ReadingsVal($name,"power",0),ReadingsVal($name,"total_consumption",0))}


Die Lernkurve begann mit dem Wunsch, dass im nächsten Schritt
1) nicht alle Werte
2) nicht alle einzeln
3) und auch nicht im Sekundentakt
gespeichert werden sollten.

zu 1)
Mit event-on-update-reading konnte ich die für mich interessanten Wert deduzieren (also keine Zählernummer oder Zähler public key)
zu 2)
Mit userReadings konnte ich mir einen eigenen (Meta)Wert zusammenbauen, der als Zeichenwert beide Einzelwerte ("power" und "total_consumption") zusammenfasst.
zu 3)
Nun wollte ich nicht einfach nur stumpf alle 10 Sekunken Werte abspeichern, sondern zumindest die in Sekundenauflösung vorliegenden Werte mitbenutzen, dies gelang mir mit der event-aggregator Funktion.
Auch wenn Wert power und total_consumption nun in der Oberfläche alle 10 Sekunden aktualisiert wurde, geschah dies für den userReadings Wert nicht.
Ich behalf mir mit event-min-interval Funktion.

Offene Frage: warum wird der userreadings Wert nicht bei aggr. Änderung des Grundwerte automatisch aktualisiert?
Ich bin mir auch unsicher ob der userReading Wert wirklich den event-aggregator Wert beinhaltet oder doch nur den zum jeweiligen Zeitpunkt abgefragten Grundwert


b) Als Nächstes galt es den auf 10 Sek. zusammengefassten (Meta)Wert lokal zu speichern, ich fand dazu die FileLog Funktion

Code Auswählen Erweitern


define filelog_ed300l FileLog ./log/ed300l.%Y.%m.log device_ed300l:usage.*
attr filelog_ed300l outputFormat { sprintf("%s %s\n",$TIMESTAMP,$EVENT =~ s/^\S+\s*//r ) }

Durch den (Meta)Wert habe ich bereits nur eine Logzeile, per Regex konnte ich noch den Devicename aus Event entfernen, welches weiteren Speicherplatz spart.
Über den default $TIMESTAMP bin ich unglücklich, da er im Rückblick nicht die Zeitzone erkennen lässt.

Offene Frage: gibt es eine einfache Möglichkeit den $TIMESTAMP im ISO8601 ausgeben zu lassen?


c) es soll nicht nur lokal gespeichert werden, sondern auch in die Ferne geschrieben werden, um Wertereihen nicht durch lokale Fehler zu verlieren.

Ich fand mit Log2Syslog eine mir zusagende Lösung, die Transportverschlüsselung beherrscht.

Code Auswählen Erweitern


define syslog_backup Log2Syslog 192.168.1.1 event:device_ed300l.usage.*
attr syslog_backup TLS 1
attr syslog_backup protocol TCP


Leider unterstützt das aktuelle Modul nur bis TLSv1.2 und beherrscht kein client ssl cert config.

Offene Frage: Das kann bestimmt gehoben und erweitert werden?


d) Zum Schluss sollten die Gerätewerte noch etwas statistische aufgewertet werden. Dazu half mit das "statistics" Modul.

Code Auswählen Erweitern


define stat_ed300l statistics device_ed300l
attr stat_ed300l deltaReadings total_consumption
attr stat_ed300l singularReadings device_ed300l:total_consumption:Delta:(Hour|Day|Month|Year)


welches ich dann per "readingsGroup" thematisch in der Oberfläche zusammenfassen konnte

Code Auswählen Erweitern


define rg_energieverbrauch readingsGroup device_ed300l:statTotal_consumptionHour device_ed300l:statTotal_consumption(Day|DayLast|Month|Year) device_ed300l:total_consumption
attr rg_energieverbrauch userattr Arbeitspreis_eur_kwh
attr rg_energieverbrauch Arbeitspreis_eur_kwh 0.275
attr rg_energieverbrauch group Energiezähler
attr rg_energieverbrauch mapping { 'statTotal_consumptionHour' => 'Verbrauch Stunde', 'statTotal_consumptionDay' => 'Verbrauch Heute', 'statTotal_consumptionDayLast' => 'Verbrauch Gestern','statTotal_consumptionMonth' => 'Verbrauch Month','statTotal_consumptionYear' => 'Verbrauch Jahr','total_consumption' => 'Verbrauch Gesamt' }
attr rg_energieverbrauch noheading 1
attr rg_energieverbrauch room Energiezähler
attr rg_energieverbrauch valueFormat { sprintf("%.2f kWh %.2f €",$VALUE / 1000, $VALUE / 1000 * AttrVal("rg_energieverbrauch","Arbeitspreis_eur_kwh",0)  ) }


Ich kann mir damit den Momentan-, Stunden-,Tages-,Monat- und Jahresverbrauch inkl. Arbeitspreis in einer Gruppierung zusammen und darstellen lassen.

HURRA mein Ziel war erreicht.

Beim längeren Betrachten dann doch nicht. In der Oberfläche wird nur den "device_ed300l:total_consumption" Wert aktualisiert, die anderen Werte nur nach Reload der Seite. Schade.

Offene Frage: Warum? Liegt es daran das "statistics" Modul Werte in einer readingsGroup Modul

edit: event-on-update-reading entfernt, Oberflächen Aktualisierung funktioniert jetzt durchgehend.

[Prof. Dr. Peter Henning]

Offene Frage: Das kann bestimmt gehoben und erweitert werden?

Klar. Wer es möchte, kann es gerne programmieren...

LG

pah

[perluser]

Ich weiß nicht wie bei FHEM der upstream Prozess verläuft.

Anbei ein Patch um Log2Syslog im client mode für TLSv1.3 zu erlauben.

Durch das explizite Setzen einer SSL Version wird verhindert, das zukünftig bessere/moderne TLS Versionen verwendet werden können.
Das zugrundeliegende openssl Frameware unterstützt kein Syntax "TLSv1_2+", daher ist es hier gute Praxis, nur die unerwünschten SSL Versionen zu verbieten.
Damit bleibt die Definition zukunftssicher, wenn modernere TLSv1.4,TLSv2 erscheinen sollten.

Code Auswählen Erweitern


--- a/FHEM/93_Log2Syslog.pm
+++ b/FHEM/93_Log2Syslog.pm
@@ -1994,7 +1994,7 @@
               $IO::Socket::SSL::DEBUG = $ssldbg;
               eval { IO::Socket::SSL->start_SSL($sock,
                                                 SSL_verify_mode          => 0,
-                                                SSL_version              => "TLSv1_2:!TLSv1_1:!SSLv3:!SSLv23:!SSLv2",
+                                                SSL_version              => "!TLSv1_1:!SSLv3:!SSLv23:!SSLv2",
                                                 SSL_hostname             => $host,
                                                 SSL_veriycn_scheme       => "rfc5425",
                                                 SSL_veriycn_publicsuffix => '',


[Thyraz]

Willkommens-Grummeln von einem der beiden Forums-Obergrummler beim zweiten Post schon gut pariert...

Insofern: Herzlich willkommen im Forum.

[KölnSolar]

Wer ist der Zweite ? Meinst Du B..... ? 

[Prof. Dr. Peter Henning]

Dann fehlt nur noch die Definition von "Grummeln"... 

LG

pah