userreadings wird doppelt ausgeführt / Stromzähler mit statistics

[Adimarantis]

Hallo,

Zu dem Thema habe ich zwar ein paar sehr alte Postings gefunden, aber ganz scheinen die nicht zu passen.

Szenario:
Ich habe einen Homematic Strohmzähler für die Steckdose, und möchte dessen kWh protokollieren.
Der hat zwar einen fortlaufenden Zähler, aber bei Stromausfall, ausstecken etc. wird der zurückgesetzt.
Deswegen habe ich folgendes userreading definiert:

Code Auswählen Erweitern

kWh:6.ENERGY_COUNTER.* { my $current=ReadingsVal($name,"6.ENERGY_COUNTER",0)/1000;
      my $last=OldReadingsVal($name,"6.ENERGY_COUNTER",ReadingsVal($name,"6.ENERGY_COUNTER",0))/1000;
      my $kwh=ReadingsVal($name,"kWh",0);
      $kwh=sprintf("%.4f",$kwh+$current-$last) if ($current>$last);
      return $kwh;
 }Um doppelte Event zu vermeiden, habe ich event-on-change-reading auf 6.ENERGY_COUNTER gesetzt.

Im Event Monitor (auf 6.ENERGY_COUNTER.*) gibt es auch immer nur ein Event.
Das Userreading wird aber trotzdem immer doppelt - innerhalb von Millisekunden - ausgeführt (mit print im userreading validiert) wodurch mein reading kWh leider immer das doppelte anzeigt.

Was kann das sein? Generell bessere Lösungen?

Übrigens was ist der Beste Weg OldReadingsVal nach dem FHEM Neustart zu nutzen? Beim allerersten Event ist es ja nicht initialisert. Ich löse das ja jetzt so, als Default dann einfach den aktuellen Wert des Readings als OldReading zu verwenden.

Edit: Scheint mit der Verwendung des Statistics Modul zusammenzuhängen. Nachdem ich das ganze Device von Statistics ausgeschlossen habe (statt nur das Readings) passiert es nicht mehr. Da habe ich einen alten Post von Rudi gefunden, der mich vermuten liess, das dies behoben wäre. Passiert aber wohl weiterhin.

Jörg

[betateilchen]

Um doppelte Event zu vermeiden, habe ich event-on-change-reading auf 6.ENERGY_COUNTER gesetzt.

Im Event Monitor (auf 6.ENERGY_COUNTER.*) gibt es auch immer nur ein Event.

Hast Du mal testweise geprüft, welche events auftreten, wenn das Attribut event-on-change-reading nicht gesetzt ist?

[Adimarantis]

Hast Du mal testweise geprüft, welche events auftreten, wenn das Attribut event-on-change-reading nicht gesetzt ist?

Ok, das ist jetzt wirklich interessant. Wenn ich event-on-change-reading lösche, dann ist das Problem weg. In den Event sehe ich keinen Unterschied (allerdings hängt gerade ein Verbraucher dran, so dass jedes update auch immer ein change ist). event-on-update-reading führt übrigens zum selben Problem: Wieder nur einmal im Event Monitor, aber userreadings wird 2x getriggert.
Gibt es dafür eine Erklärung oder ist das ein Bug?

[betateilchen]

Gibt es dafür eine Erklärung oder ist das ein Bug?

Das soll Dir am besten Rudi erklären 

[TomLee]

Doofe Frage, bei der Suche nach dem Problem stell ich mir die Frage ob es ein Reading mit dem Namen 6.ENERGY_COUNTER_OVERFLOW gibt ?

Mag nicht ausschliessen das ich was nicht richtig verstanden habe, aber wenn, gehört dann nicht einfach das Suchmuster/trigger auf das Reading 6.ENERGY_COUNTER eingeschränkt ?

[rudolfkoenig]

Das soll Dir am besten Rudi erklären 

Ich kann das Problem nicht mal nachstellen:

Code Auswählen Erweitern

define t telnet 7072

define kWh dummy
attr kWh userReadings kWh:6.ENERGY_COUNTER.* {\
  my $current=ReadingsVal($name,"6.ENERGY_COUNTER",0)/1000;;\
  my $last=OldReadingsVal($name,"6.ENERGY_COUNTER",ReadingsVal($name,"6.ENERGY_COUNTER",0))/1000;;\
  my $kwh=ReadingsVal($name,"kWh",0);;\
  $kwh=sprintf("%.4f",$kwh+$current-$last) if ($current>$last);;\
  return $kwh;;\
}
attr kWh oldreadings 6.ENERGY_COUNTER
attr kWh event-on-change-reading 6.ENERGY_COUNTER,kWh

und

% telnet localhost 7072

Code Auswählen Erweitern

fhem> info timer
fhem> setreading kWh 6.ENERGY_COUNTER 1.234
2023-03-28 20:27:07 dummy kWh 6.ENERGY_COUNTER: 1.234
2023-03-28 20:27:07 dummy kWh kWh: 0

fhem> setreading kWh 6.ENERGY_COUNTER 2.234
2023-03-28 20:27:12 dummy kWh 6.ENERGY_COUNTER: 2.234
2023-03-28 20:27:12 dummy kWh kWh: 0.0010

fhem> setreading kWh 6.ENERGY_COUNTER 3.234
2023-03-28 20:27:18 dummy kWh 6.ENERGY_COUNTER: 3.234
2023-03-28 20:27:18 dummy kWh kWh: 0.0020

Immer diese Geschichten, wo man nur ein Teil erzaehlt bekommt, und den Rest raten muss.
Und wenn man falsch geraten hat, dann steht man wie der Dumme da.

[Adimarantis]

Ok. Hab nochmal weiter rumprobiert. Es hängt doch mit statistics zusammen.
Reproducer:

Code Auswählen Erweitern

define kwh dummy
attr kwh event-on-change-reading 6.ENERGY_COUNTER
attr kwh userReadings kWh:6.ENERGY_COUNTER.* { \
      my $current=ReadingsVal($name,"6.ENERGY_COUNTER",0)/1000;;\
      Log3($name,0,"$name $current");;\
      return $current;;\
 }
#   CFGFN     
#   FUUID      6423379c-f33f-b127-36ad-52f98221b7901eb6
#   NAME       kwh
#   NR         699178
#   STATE      ???
#   TYPE       dummy
#   eventCount 11
#   Helper:
#     DBLOG:
#       6.ENERGY_COUNTER:
#         logdb:
#           TIME       1680030192.36128
#           VALUE      123
#       kWh:
#         logdb:
#           TIME       1680030163.5962
#           VALUE      0.122
#       stat6.ENERGY_COUNTER:
#         logdb:
#           TIME       1680030163.5962
#           VALUE      Hour: 7 Day: 8 Month: 8 Year: 8 (since: 2023-03-28_20:58:56 )
#   OLDREADINGS:
#     2023-03-28 20:57:51   6.ENERGY_COUNTER 114
#   READINGS:
#     2023-03-28 21:03:12   6.ENERGY_COUNTER 123
#     2023-03-28 21:03:12   kWh             0.123
#     2023-03-28 21:03:12   stat6.ENERGY_COUNTER Hour: 8 Day: 9 Month: 9 Year: 9 (since: 2023-03-28_20:58:56 )
#     2023-03-28 20:59:55   stat6.ENERGY_COUNTERLast Hour: 1 Day: - Month: - Year: - (since: 2023-03-28_20:58:56 )
#     2023-03-28 21:03:12   statKWh         Hour: 0.008 Day: 0.009 Month: 0.009 Year: 0.009 (since: 2023-03-28_20:58:56 )
#     2023-03-28 20:59:55   statKWhLast     Hour: 0.001 Day: - Month: - Year: - (since: 2023-03-28_20:58:56 )
#   helper:
#     _98_statistics stat
#   hmccu:
#
setstate kwh 2023-03-28 21:03:12 6.ENERGY_COUNTER 123
setstate kwh 2023-03-28 21:03:12 kWh 0.123
setstate kwh 2023-03-28 21:03:12 stat6.ENERGY_COUNTER Hour: 8 Day: 9 Month: 9 Year: 9 (since: 2023-03-28_20:58:56 )
setstate kwh 2023-03-28 20:59:55 stat6.ENERGY_COUNTERLast Hour: 1 Day: - Month: - Year: - (since: 2023-03-28_20:58:56 )
setstate kwh 2023-03-28 21:03:12 statKWh Hour: 0.008 Day: 0.009 Month: 0.009 Year: 0.009 (since: 2023-03-28_20:58:56 )
setstate kwh 2023-03-28 20:59:55 statKWhLast Hour: 0.001 Day: - Month: - Year: - (since: 2023-03-28_20:58:56 )


Device ist in statistics definiert und 6.ENERGY_COUNTER als deltaReading.

Jetzt triggert auch ein

Code Auswählen Erweitern

setreading kwh 6.ENERGY_COUTNER 131zwei Ausgaben im logfile.
Wenn ich das event-on-update-reading löschen - dann passiert das nur noch einmal.
Wenn ich das device aus statistics nehme, dann auch nur einmal - trotz event-on-update-reading.

Scheint also das update für stat6.ENERGY_COUNTER zu sein, welches aber im Event Monitor nicht auftaucht.

Gruß
Jörg

[Jamo]

Hallo Adimarantis,
das wurde für einen HMIP-PSM (aus deinem reading 6.ENERGY_COUNTER nehme ich an es ist ein HM-IP Stromzähler) hier in https://forum.fhem.de/index.php?topic=107077.msg1182263#msg1182263 schon mal diskutiert.
So wie ich zap verstanden habe, schickt die CCU 2 events. Abhilfe dann auf einen anderen X.STATE zu triggern.

Siehe auch hier: https://forum.fhem.de/index.php?msg=1144181

[RalfRog]

...und möchte dessen kWh protokollieren.
Der hat zwar einen fortlaufenden Zähler, aber bei Stromausfall, ausstecken etc. wird der zurückgesetzt.

Mal unabhängig von den ganzen Tiefen hier, wenn ich die Ausgangsfrage richtig verstanden habe. Wäre eine einfaches Userreading nicht zielführend?
Meines ist:
    energyCum:energy.* monotonic {ReadingsVal("shelly_plug_s_df2674","energy",0)}    (oder vielleicht besser ReadingsNum)
dann arbeite ich statt mit event on change mit:
    event-min-interval   power.*:120,energy.*:900
    DbLogInclude  power:120,energyCum:900

Die statistics ist sauber.

[Adimarantis]

@Jamo:
Einen Zusammenhang mit HMCCU oder dem PSM Device hatte ich auch erst vermutet. Dagegen spricht aber
1. Reproduzierbar mit dummy Device
2. event-on-change-reading sollte ja eigentlich genau das verhindern, erzeugt aber im Gegenteil das Problem überhaupt erst
3. Passiert nur bei Verwendung von statistics
4. Kein zweites Event im Eventmonitor

@RalfRog:
Das monotonic kannte ich noch nicht. Mal schnell ausprobiert und es sollte tatsächlich so einfacher gehen.
Der doppelte Trigger passiert hier zwar immer noch, aber führt in einem Test mit dem dummy Beispiel zumindest nicht zur doppelten Aufsummierung.

[RalfRog]

Na schön freut mich.
Nimm am Besten ReadingsNum, da kannst du runden. Der monotonic macht sonst irgendwann viele Nachkommastellen.

Gruß Ralf