OWL+USB-Energiemonitor in FHEM: 60_CM160.pm liefert falsche Daten

Begonnen von Raspi-Newbie, 14 November 2015, 11:40:40

Vorheriges Thema - Nächstes Thema

Raspi-Newbie

Hallo zusammen,

ich nutze seit einiger Zeit das Modul 60_CM160.pm (Version 1, 10/2012) von Dirk, um den OWL+USB-Energiemonitor mit dem Treibermodul cp210x.ko auszulesen, welches auch zuverlässig funktioniert. Der aktuelle Leistungswert wird korrekt in Watt ausgelesen. Leider stimmen die akkumulierten Werte nicht (siehe Anhang).

Gibt es hierfür bereits eine Lösung bzw. ein Workaround? Ich möchte gerne die Tages-, Monats- und Jahresverbrauchswerte in kWh zur Anzeige bringen. Leider bin ich auch nach Sichtung des Moduls 60_CM160.pm sowie mit einem Trial-and-Error-Ansatz nicht weiter gekommen.  ::)

ste87

Hallo

ich bin ebenfalls gerade dabei, das CM160 in Betrieb zu nehmen. Treiber und Anbindung funktionieren bei mir ebenfalls schon.

Mir ist auch aufgefallen, dass die Werte der aufaddierten Werte nicht stimmen. Nach der aktuellen Beobachtung gibt es bei mir aller paar Stunden einen sprunghaften Anstieg der berechneten kWh. Von normal unter 1 kWh sind es dann plötzlich 60 kWh. Aktuell ist das immer, wenn der Leistungswert (Reading "W") einmal auf 0.00 steht. Eine Erklärung was passiert habe ich aber dafür noch nicht.

Aus diesen Grund habe ich mir das Modul 60_CM160.pm mal genauer angesehen. Mir ist dabei Folgendes aufgefallen: Bei der Berechnung der kumulierten Werte wird der aktuelle Watt-Wert mit den letzten addiert, was ich schon komisch finde. Danach wird aus dieser Summe geteilt durch 60 und 1000 der kWh-Wert berechnet. Das ist aber meiner Ansicht nach falsch. Denn bei einer Teilung durch 60 und 1000 um auf kWh zu kommen, muss der Ausgangswert Wmin gewesen sein. Es wird aber mit der reinen Watt-Angabe gerechnet. Diese Addition findet dazu immer statt, wenn eine Aktualisierung der Werte durch das Gerät gesendet wird. Dies geschieht bei keiner Änderung aller 30 Sek (bei mir jedenfalls) und sonst öfter, wenn der Strom stärker schwankt. Bei der aktuellen Rechnung wird aber immer von einer Minute ausgegangen, somit sind die kWh Werte immer zu hoch!!! Das konnte ich beim Anschauen meiner Logs auch bestätigen, ich habe Nachts keinen Wert über 400W in einer Stunde, der Stundenverbrauch ist aber 0.6 kWh (das heißt die Durschnittsleistung muss 600 Watt gewesen sein).

Ich habe Heute Abend mal eine andere Rechnung bei mir implementiert, die die Zeitstempel der letzen Akkumulierung und des aktuellen Watt-Readings nimmt und damit die vergangene Zeit berechnet. Für diesen Zeitraum wird dann der aktuell vom C160 gesendeten Watt-Wert genommen und die verbrauchte Energie in kWh ausrechnet. Für die Übersicht, und weil es mich sowieso stört habe ich außer kWh alle anderen redundanten Angaben (EUR, CO2) aus den cum* Werten ausgebaut. Ich werde das jetzt mal ein paar Tage laufen lassen und schauen ob das jetzt besser passt.

Raspi-Newbie

Hallo ste87,

bei mir werden die Werte auch ohne eine einheitliche Zeitbasis ausgelesen. Insofern erscheint dein Ansatz richtig, eine Zeitdifferenz aus den Zeitstempeln zu ermitteln, um diese dann zu verwenden, die Leistung über die Zeit diskret zu integrieren. Könntest du deine Code-Änderung zur Verfügung stellen?  Dann würde ich es auch gleich bei mir erproben.

ste87

So ich habe die Änderungen bis heute mal laufen lassen und die Daten überprüft. Von den Werten her passt das jetzt, wenn ich händisch nachrechne. Ich habe jetzt auch keine Probleme mehr mit steigenden kWh bei einer enpfangenen 0 W vom CM160.

Wir sind dabei aber zwei Dinge aufgefallen: Es findet jetzt eine Quantisierung in den cum-Werten statt. Früher wurde immer über die Watt Angabe in den cum-Werten gerechnet, bei mir wird jetzt aber direkt mit den kWh gerechnet um richtig zu sein. Damit werden Kommastellen die nicht mit ausgegeben werden auch nicht beim nächsten mal aufaddiert. Um das in ein erträgliches Maß zu bringen habe ich die Ausgabe von 2 Kommastellen auf 4 erhöht. Damit liegt bei einen 30 Sek Zyklus der kleinste mögliche Wert bei 3 W, mit den auch eine Änderung in den cum-Werten erfolgt.

Ich hänge mal meine aktuelle Version der 60_CM160.pm an. Testen auf eigene Gefahr. Da die Formatierung der cum* geändert wurde, schlägt das erste Auslesen der letzten Werte fehl und es wird mit einer falschen Zahl gerechnet, danach klappt es aber. D.h. um saubere Daten zu erhalten am besten das CM160 Device noch mal neu anlegen.

Zur Zeit ist das Modul ja nicht im offiziellen FHEM, was evtl. ja auch an der doch aufwendigen Geschichte mit dem USB/serial - Treiber liegt. Ich hoffe aber der Ersteller des Modul (Dirk Hoffmann) könnte was zur Situation sagen, so das man vllt. mit noch anderen Verbesserungen/ Änderungen die bekannt sind, eine "offizielle" neue Version für das CM160 erstellen könnte.



Raspi-Newbie

Ok, besten Dank. Bei mir läuft es jetzt auch. Auf den ersten Blick scheint die akkumulierte Energie (kWh) plausibel zu sein. Ich lasse es jetzt mal eine Woche durchlaufen.  :o

Raspi-Newbie

Hallo zusammen,

nach knapp einer Woche (5 Tage) Dauerlauf des von ste87 angepassten Skripts, kann ich Folgendes zur Genauigkeit feststellen:

Summe aller cumHour-Einträge: 30,31 kWh
Summe alle cumDay-Einträge: 30,56 kWh
Kumulierte Energie an OWL-Station: 30,7 kWh

D.h., der Fehler liegt unter -1,3 % im Veregleich zur OWL-Station. Das passt soweit! Dabei hatte meine Station sogar mehrere Verbindungsabbrüche:
Opening CM160 device /dev/ttyUSB0
CM160 device opened


cumMonth und cumYear funktionieren leider nicht. Hier werden sogar negative Werte angezeigt.

ste87

Hallo Raspi-Newbie,

erst einmal Danke fürs Testen.

Also bei mir passen die Werte Stunde, und Tag auch. Habe aber aktuelle noch keinen Abgleich mit meinem "echten" Zähler gemacht.

Monat und Jahr sind auch bei mir fehlerhaft, ich habe mir das noch mal angeschaut und den Fehler gefunden, es liegt an der Art der Berechnung des Zeitintervalls zwischen zwei Messungen, dort habe ich nur mit der Zeit und nicht mit dem vollen Datum gerechnet, daher wird beim Tageswechsel eine negative Zeit ausgerechnet und das führt zu einer Subtraktion in den cum-Werten. Ich werde versuchen heute noch eine neue Version hochzuladen.

Raspi-Newbie


volschin

Aus meiner Sicht hast Du den Implementierungsfehler bei difftime. Du solltest mit str2time die kompletten Zeitstempel verarbeiten. dann gibt es keine Probleme mit negativem difftime.
my $diffTime = str2time($hash->{READINGS}{Leistung}{TIME}) - str2time($hash->{READINGS}{$cumKey}{TIME});
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

ste87

Ja richtig, es muss das volle Datum des Readings genommen werden. Hatte leider keine Zeit es noch ein zupflegen.
Im Anhang habe ich die geänderte Version, allerdings ungetestet, da mein OWL gerade Offline ist, sollte aber so funktionieren.


Raspi-Newbie

Super, das klingt plausibel. Ich habe es auch gerade geändert und lasse es jetzt mal zwei Wochen durchlaufen.

volschin

Ich habe übrigens bei mir auch ein last... eingebaut. Damit kann man immer sehen, was man in der vorigen Stunde, Tag, Monat oder Jahr verbraucht hat. Das finde ich praktisch. Falls jemand Interesse hat, kann ich das gern hier posten.
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

Raspi-Newbie

Ich schreibe bei mir die Werte direkt in Logdateien, die dann zur Anzeige gebracht werden. Mit dem Attribut "fixedrange" kann man beispielsweise eine komplette Monatsdarstellung mit den einzelnen Tagesumsätzen auf einen Blick darstellen. Das kann ich auch gerne mal posten, falls jemand Interesse hat.

volschin

Jepp, interessiert mich, wie man dabei auf die Tagesumsätze kommt.
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)