Bug im EM-10000-GZ/WZ: Lösungsvorschlag im CUL_EM-Modul

[FhemPiUser]

Ich habe 2 Probleme mit meinem EM1000GZ und fhem und würde gerne wissen, ob das Bugs im CUL_EM-Modul oder in EM10000GZ-Software sind.

1) Immer wenn der EM1000GZ kurzzeitig vom Strom getrennt wird, stimmt der nächste cum_day-Wert nicht. Grund ist vermutlich, dass der cum-Wert vom ersten 5min-Logeintrag nach dem Stromausfall geringer ist als vom letzten 5min-Logeintrag vor dem Stromausfall.

2) Ich habe meinen Wasserzähler mit dem EM1000GZ angebunden und musste dafür corr1 und corr2 auf 0.001 setzen (statt 0.01), da eine Umdrehung 0.001m3 sind. Klappt auch alles bestens, nur dass die cum_month-Werte 0 sind. 5min-Werte und cum_day-Werte stimmen.

Jemand eine Idee?

Update: Für 1) habe ich unten eine Lösung vorgeschlagen, 2) tauchte nur im 1. Monat auf. Eine Erklärung dafür habe ich nicht...

[rudolfkoenig]

1. Ist normal, man trennt das EM1000GZ normalerweise nicht vom Strom. Nach der Trennung kann/muss man das dokumentierte basis Reading neu setzen.
2. cum_month wird nur beim Monatswechsel gesetzt. Es funktioniert fuer ein EMWZ seit Jahren problemlos, ich sehe im Code keinen Grund, warum es bei EMGZ anders sein sollte.
3. http://www.tty1.net/smart-questions_de.html#dontclaimbug

[FhemPiUser]

zu 1) "normal" im sinne von "das war schon immer so": ja. aber ich finde das als nutzer nicht normal und denke mal, dass es an der verarbeitung im em1000gz liegt und nicht im cul_em-modul. ich meine nicht das basis reading, ich synchronisiere meinen zählerstand garnicht mit fhem, da mich der absolute zählerstand nicht interessiert. mich interessiert nur der verbrauch pro tag/monat/jahr und der ist nach jedem stromausfall falsch. er merkt sich ja im prinzip den cum wert auch bei stromausfall, nur halt nicht ganz korrekt. der cum wert nach stomausfall ist um einige kwh niedriger als der cum wert vor dem stromausfall. aber ich denke der cum-wert kommt vom em1000gz und das modul rechnet diesen nur mit dem korrekturfaktor um, oder?

zu 2) die cum_month zeile taucht auch bei mir beim monatswechsel im log auf, aber eben mit dem wert 0, was ich mir nicht erklären kann. cum_day und die 5min werte sind aber während des monats >0. wird der cum_month wert vom em1000gz berechnet oder vom cum_em-modul? ich vermutet, dass der wert vom em1000gz kommt und das modul nur umrechnet mit dem korrektufaktoren? dann würde das cul_em-modul schon eine 0 vom em1000gz erhalten.....

bei meinem strom- und gaszählern funktioniert es ja auch, nur beim wasserzähler nicht und der einzige unterschied ist der korrekturfaktor mit 0.001...

zu 3) schon klar. Ich glaube auch wie gesagt nicht, dass Fehler im cul_em-Modul die Ursache sind...

[rudolfkoenig]

aber ich denke der cum-wert kommt vom em1000gz und das modul rechnet diesen nur mit dem korrekturfaktor um, oder?

Richtig.

die cum_month zeile taucht auch bei mir beim monatswechsel im log auf, aber eben mit dem wert 0, was ich mir nicht erklären kann.

Ich leider (selbst nach Code-Studium) auch nicht.

[FhemPiUser]

mal schauen wie es zum nächsten monatswechsel aussieht. vielen dank estmal fürs code studium...

update: problem ist nicht mehr aufgetreten.

gegen das problem bei stromausfall hilft wohl nur eine usv. man bräuchte für den em1000gz ja eigentlich nur ganz wenig leistung, vielleicht sowas wie ein ein pufferakku. hat das mal jemans probiert?

[duke-f]

Etwas spat, aber vielleicht nicht zu spat.

Prinzipiell ist eine Routine denkbar, die folgendermaßen das Rücksetzen des Absolutzählers bei Stromausfall ausgleicht:

- Es wird in einem Dummy immer der aktuelle Absolutzählerstand notiert
- Ist der aktuelle Wert kleiner als der letzte Wert, wird der letzte Wert erhalten.
- Dieser Dummy-Wert wird im Tageszähler addiert.

Ich habe mir einen solchen Tageszähler sinngemäß so realisiert:
- Um 00:00 wird der aktuelle CUM-Wert (Absolutzählerstand) in einen Dummy namens Puffer geschrieben.
- Ein weitererer Dummy gibt den aktuellen Tagesverbrauch an und wird als Differenz zwischen CUM (Absolutzähler) und Puffer.

[FhemPiUser]

Hallo,

das wird zumindest für mein Problem nicht reichen, denn ich werte cum_day, cum_month und cum_year aus. die müssen stimmen, den cum absolutwert werte ich nicht direkt aus.

Ich habe mal ein Beispiel von gestern, als es einen Stromausfall gegeben hat und es dadurch einen Sprung zurück im CUM-Wert gab (siehe Pfeile):

Code Auswählen Erweitern


...
2016-09-03_00:03:01 CUL_EM_1 CNT: 237 CUM: 7334.160  5MIN: 0.320  TOP: 0.270
...
2016-09-03_16:05:19 CUL_EM_1 CNT: 175 CUM: 7338.800  5MIN: 0.160  TOP: 0.160
2016-09-03_16:10:19 CUL_EM_1 CNT: 176 CUM: ->7338.827<-  5MIN: 0.320  TOP: 0.244
2016-09-03_15:22:03 CUL_EM_1 CNT: 2 CUM: ->7334.160<-  5MIN: 0.320  TOP: 0.240
2016-09-03_15:27:04 CUL_EM_1 CNT: 3 CUM: 7334.200  5MIN: 0.480  TOP: 2.124
...
2016-09-03_23:55:11 CUL_EM_1 CNT: 92 CUM: 7336.667  5MIN: 0.320  TOP: 0.244
2016-09-04_00:00:12 CUL_EM_1 CNT: 93 CUM: 7336.680  5MIN: 0.160  TOP: 0.160
...


Der CUM-Wert von gestern Tagesbeginn ist zwar niedriger als der CUM-Wert gestern Tagesende, aber der Tagesverbrauchswert (0.090) stimmt durch den Sprung zurück nicht und es gibt eine weitere Zeile mitten am Tag:

Code Auswählen Erweitern


2016-09-03_00:03:01 CUL_EM_1 cum_day: CUM_DAY: 8.400 CUM: 7334.160 COST: 2.10
->2016-09-03_15:22:03<- CUL_EM_1 cum_day: CUM_DAY: 8.400 CUM: 7334.160 COST: 2.10
2016-09-04_00:00:12 CUL_EM_1 cum_day: CUM_DAY: ->2.520<- CUM: 7336.680 COST: 0.63


Korrekt wäre:

Code Auswählen Erweitern


2016-09-03_00:03:01 CUL_EM_1 cum_day: CUM_DAY: 8.400 CUM: 7334.160 COST: 2.10
2016-09-04_00:00:12 CUL_EM_1 cum_day: CUM_DAY: ->7.187<- CUM: 7336.680 COST: 1.78


Lösungsvorschlag: Man müsste das automatisch korrigieren können, wenn das CUL_EM-Modul

• Keinen Tagesverbrauchswert (cum_day) mitten am Tag schreibt
• Am Ende des Tages die 5-min-Werte des Tages daraufhin überprüft, ob es einen Aussetzer des monotonen Anstieg des CUM-Wertes gab bzw. ob es einen Sprung zurück gab. Falls es einen Sprung zurück gab, muss die Höhe des Sprungs (in diesem Fall 7338.827-7334.160=4.667) auf den Tagesverbrauchswert (cum_day) addiert werden (2.520+4.667=7.187). entsprechend sollte auch der cum wert korrigiert werden. cum_month und cum_year werden offenbar auf basis cum_day und cum wertes berechnet und sollten daher dann auch korrigiert sein, oder?

Wäre das etwas, was ins Modul eingebaut werde könnte (um den "Fehler" der Hardware auszugeleichen)?

[rudolfkoenig]

Wäre das etwas, was ins Modul eingebaut werde könnte (um den "Fehler" der Hardware auszugeleichen)?

Diese Methode ist sehr aufwendig. Deutlich einfacher waere Folgende:
- wir nehmen das RAW Reading als Quelle
- Falls hier CUM kleiner ist, als in den aktuellen Telegramm, dann berechnet man ein neues basis Reading.

Ich habe das jetzt Programmiert, und eingecheckt, steht ab morgen um 8 per update zur Verfuegung.
Bin nicht sicher, ob mein Formel richtig ist, und bitte um Gegenpruefung. Die Aenderung ist mit Forum #55626 markiert

[FhemPiUser]

Hallo Rudolf,

vielen Dank, aber ich habe Deinen neuen Code noch nicht getestet, da das Problem im Moment bei mir nicht mehr auftritt. Ich nehme an es liegt daran, dass mein Raspberry mit fhem inzwischen an einer USV hängt. Wenn also der EM 1000 GZ vom Strom genommen wird, aber der Raspberry mit fhem aufgrund der USV nicht, dann gibt es bei mir aktuell keinen Sprung zurück mehr im cum-Wert:

Code Auswählen Erweitern


...
2016-10-05_18:06:52 CUL_EM_9 CNT: 245 CUM: 6501.930  5MIN: 0.000  TOP: 0.000
2016-10-05_18:11:53 CUL_EM_9 CNT: 246 CUM: 6501.990  5MIN: 0.060  TOP: 0.006
<-Stromausfall EM 1000 GZ->
2016-10-05_18:18:13 CUL_EM_9 CNT: 1 CUM: 6502.150  5MIN: 0.160  TOP: 1.875
2016-10-05_18:23:14 CUL_EM_9 CNT: 2 CUM: 6502.160  5MIN: 0.010  TOP: 1.765
...


Merkwürdig...

[FhemPiUser]

hallo rudolf,

es scheint probleme zu geben, die mit der codeänderung zusammenhängen könnten, siehe https://forum.fhem.de/index.php/topic,57087.0.html. kannst du das prüfen bzw rückgängig machen?

vielen dank!