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

So habe ich es umgesetzt, um die Tagesumsätze (cumDay) aufzuzeichnen und darzustellen:

1) Logdatei erstellen und cumDay-Werte eintragen:

define FileLog_AktuellerVerbrauch_cumDay FileLog ./log/Akkumulierter_Verbrauch_cumDay-%Y.log CM160:cumDay.*
attr FileLog_AktuellerVerbrauch_cumDay logtype text


Die Logeinträge werden täglich kurz nach Mitternacht reingeschrieben. Hier sind ein paar Beispieleinträge:

2015-11-24_00:00:22 CM160 cumDay 7.5917 kWh
2015-11-25_00:00:14 CM160 cumDay 7.6698 kWh
2015-11-26_00:00:21 CM160 cumDay 8.5463 kWh
2015-11-27_00:00:21 CM160 cumDay 7.1037 kWh
2015-11-28_00:00:21 CM160 cumDay 4.5929 kWh
2015-11-29_00:00:20 CM160 cumDay 10.3205 kWh
2015-11-30_00:00:22 CM160 cumDay 9.1934 kWh
2015-12-01_00:00:19 CM160 cumDay 9.1829 kWh
2015-12-02_00:00:01 CM160 cumDay 7.4562 kWh
2015-12-03_00:00:19 CM160 cumDay 7.5005 kWh
2015-12-04_00:00:18 CM160 cumDay 8.4104 kWh


2) Plot erstellen und mit dem Attribut "fixedrange" versehen:

FileLog_AktuellerVerbrauch_cumDay:SVG_FileLog_AktuellerVerbrauch_cumDay:CURRENT
attr SVG_FileLog_AktuellerVerbrauch_cumDay fixedrange month


Das gleiche klappt übrigens auch mit den cumHour- und cumMonth-Werten.

Ein Screenshot vom Plot ist im Anhang.

Raspi-Newbie

Moin zusammen,

hier sind ein paar Angaben zur Genauigkeit über den Monat Dezember:

Energie gemäß Stromzähler: 234,2 kWh
Summe aller cumHour-Einträge: 230,5 kWh (-1,6 %)
Summe alle cumDay-Einträge: 236,7 kWh (+1,1 %)

Die Spannung ist bei mir derzeit auf 215 V (attr CM160 voltage 215).

Das passt!  :)

volschin

Zitat von: Raspi-Newbie am 02 Januar 2016, 13:06:03
Summe aller cumHour-Einträge: 230,5 kWh (-1,6 %)
Summe alle cumDay-Einträge: 236,7 kWh (+1,1 %)
Hier scheint es dann noch ein Logik-Problem im Code zu geben.
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

Hallo,

erst  einmal Danke Raspi-Newbie für deine Auswertung.
Die Abweichung von ca. +2,5%  der cumDay und cumHour Einträge ist noch ein Fehler. Ich habe noch einmal die Berechnung überdacht. Es gibt in der aktuellen Version noch ein paar Quellen für Abweichende Zahlen. Wenn z.B. die Stunde gewechselt hat wird der Wert cumHour wieder auf 0 gestellt, aber in den Moment wird der aktuelle Verbrauchswert des letzten Messintervalls verworfen, d.h. diese Energie geht komplett verloren und wird nicht in cumHour auftauchen. Jedoch in den "höheren" cum-Werten, daher sind diese Werte bei dir auch höher.

Weiterhin wird aktuell der gesendete Wert als Verbrauchswert für das letzte Zeitintervall verwendet. Das ist aber nur eine Schätzung. Geht man davon aus, dass das CM160 immer dann einen neuen Wert sendet, wenn sich der gemessene Strom ändert, bzw. zyklisch aller ca. 30 Sekunden (zumindest bei mir), dann ist der letzte gesendete Leistungswert der für das letzte Intervall richtige.

Ich habe aus diesen Grund bei mir das reading "lastW" eingeführt. Dieses wird jetzt zur Berechnung der cum-Werte herangezogen. Gleichzeitig habe ich die Berechnung vereinfacht, sodass nur noch einmal für das Intervall gerechnet wird (da die Zeitstempel der Readings sowieso gleich sind) Dann wird der Wert auf die einzelnen cum-Werte addiert. Um das oben beschriebene Problem mit den ungleichen Summen zu lösen wird beim Zeitübergang die aktuelle Summe auf ein "lastcumxxx" Reading geschrieben. So gehen erst mal keine Werte verloren und man hat genug Zeit die Werte in ein Log zu schreiben.  (ich denke mal so wie volschin das gemacht hat).

Ich habe die Version bei mir jetzt getestet und werde es morgen mit meinem Zähler vergleichen, wenn das passt, lade ich die Version hoch. Was ich allerdings entfernt habe sind alle anderen Readings (A, CO , cost), da die prinzipiell redundant sind, wer sie braucht kann sich das mittels Dummy noch errechnen.

ste87

Anbei die aktuelle Version mit der geänderten Berechnung (siehe letzten Post).

Beachte: Die Attributes: costPerKwh currency co2Factor sind nicht mehr enthalten.

Snuggle

Nach der Installation Deiner 60_CM160.pm hat's mir die Datenbank zerschossen, wenn ich direkt die Readings der CM160 abgreifen will. Eine Umleitung über einen Dummy funktioniert.

ste87

Welche Datenbank genau?

Mit direkt abgreifen der Readings, meinst du da über das Event, was vom CM160 generiert wird?

Edit: Habe gerade bei mir den Event-Monitor laufen gelassen, es wird beim Stundenumbruch nur ein Event für cumHour ausgelöst. Da fehlt das für lastcumHour, das werde ich noch einbauen

Snuggle

nachdem ich im frontend ein chart auf cm160 cumhour angelegt habe waren alle charts verschwunden und konnten auch nicht mehr angelegt werden.
Erst nachdem ich die DBLog neu eingerichtet habe (Datenverlust inkl.) lief DBLog wieder. Welche der Tabellen zerstört wurde ist mir nicht bekannt.

ste87

Hallo Snuggle,

erst ein mal Entschuldigung für den Datenverlust. Ich selber nutze kein DBLog, kann daher zu dem Fehler noch nichts sagen.

Wenn du noch was in deiner Log-Datei zu diesen Fehler / löschen stehen hast, wäre es nett wenn du das hier posten könntest.
Hattest du schon Diagramme mit einer alten Version der CM160 angelegt und ja dann schon mal mit einer aus diesem Thread?

Wernieman

Btw:
bei einem Backup auch immer die DB mit sichern .. dann hätte man jetzt eventuell noch etwas recovern können ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Gunther

Kann jemand bitte die letzte Version nochmal zur Verfügung stellen?

Ich bekomme meinen OWL derzeit nicht zum Laufen. Ist seit Ende October still. Habe seitdem keine Logeinträge mehr.
Steht auf opened.
Habt Ihr einen Tipp?
FHEM@Proxmox@Nuc: TabletUI als User-Interface (4 Wandtablets) / IOs per ser2net gekapselt
Homematic: Heizung, Fenster, Bewegung | Jeelink: Temperatur | Z-Wave: Bewegung, Temperatur | FS20: Temperatur, Fenster | Viessmann-Heizung eingebunden

volschin

Hast bestimmt deinen Kernel aktualisiert und den Treiber nicht eingebaut.
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)

Gunther

Bewusst nicht.
Wodurch aktualisiert sich der Kernel?
Kann ich das prüfen?
FHEM@Proxmox@Nuc: TabletUI als User-Interface (4 Wandtablets) / IOs per ser2net gekapselt
Homematic: Heizung, Fenster, Bewegung | Jeelink: Temperatur | Z-Wave: Bewegung, Temperatur | FS20: Temperatur, Fenster | Viessmann-Heizung eingebunden

volschin

#28
uname -a
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)

Gunther

pi@raspberrypi ~ $ uname -a
Linux raspberrypi 4.1.7-v7+ #817 SMP PREEMPT Sat Sep 19 15:32:00 BST 2015 armv7l GNU/Linux


Kannst Du daran etwas erkennen?
FHEM@Proxmox@Nuc: TabletUI als User-Interface (4 Wandtablets) / IOs per ser2net gekapselt
Homematic: Heizung, Fenster, Bewegung | Jeelink: Temperatur | Z-Wave: Bewegung, Temperatur | FS20: Temperatur, Fenster | Viessmann-Heizung eingebunden