jens-maus / RaspberryMatic

:house: A feature-rich but lightweight, buildroot-based Linux operating system alternative for your CloudFree CCU3/ELV-Charly 'homematicIP CCU' IoT smarthome central. Running as a pure virtual appliance (ProxmoxVE, Home Assistant, LXC, Docker/OCI, Kubernetes/K8s, etc.) or on a dedicated embedded device (RaspberryPi, Tinkerboard, IntelNUC, etc.)
https://raspberrymatic.de
Apache License 2.0
1.5k stars 186 forks source link

HM-ES-TX-WM_CCU from jp112sdl gas values are increasing after CCU restart #2453

Open soosp opened 9 months ago

soosp commented 9 months ago

Describe the issue you are experiencing

If you do gas metering with HM-ES-TX-WM_CCU and RaspberryMatic, the "Energy Counter - Central" field is increased with value of "Energy Counter - device" field after a power outage, software update or a simple reboot of RaspberryMatic. Here are the values before reboot: 236945811-00afcb13-7451-49c5-bccf-38a20a625ebd After reboot: 236948008-84bdead6-7b17-47bd-8eef-90947a5fded7 And these are the values when device first appears: 236948126-f66dec88-2762-4690-bee9-979a8b2cd6a8 There was not any gas consumption under this test.

@jp112sdl wrote:

It's not a problem of the sketch. Maybe a problem in Raspberrymatic or so. "Energy Counter - Central" is calculated directly within the CCU

See: also: https://github.com/jp112sdl/Beispiel_AskSinPP/issues/51

Describe the behavior you expected

After reboot the counter is not increased.

Steps to reproduce the issue

  1. Check the counters.
  2. Reboot.
  3. Check the counter again. ...

What is the version this bug report is based on?

3.71.12.20230826

Which base platform are you running?

rpi3 (RaspberryPi3)

Which HomeMatic/homematicIP radio module are you using?

RPI-RF-MOD

Anything in the logs that might be useful for us?

-

Additional information

This behavior is not related with this version, it was experienced in earlier RaspberryMatic releases too.

jens-maus commented 9 months ago

Well, within a CCU an internal (hidden) program is usually automatically added for every energy counter device (incl. HM-ES-TX-WM). This program is called prgEnergyCounterGAS_<ISEID>_<SERIAL>:<CHANNEL>. And exactly that program takes care to increase the internal ccu device counter system variable which also is automatically added and named svEnergyCounterGas_<ISEID>_<SERIAL>:<CHANNEL>'. See here:

Bildschirmfoto 2023-09-29 um 11 01 21

So simply have a look if for your device there is such an internally hidden support program within the program list. And if so (must be) have a look inside the ReGa-Skript which is also automatically generated and then try to debug the issue yourself.

And these special internal energy counter scripts usually looks like the following example one:

object chn = dom.GetObject('<ISEID>');
object oBoot = chn.DPByControl('POWERMETER_IEC1.BOOT');
object oEnergyCounter = chn.DPByControl('POWERMETER_IEC1.GAS_ENERGY_COUNTER');
object oSysVarEnergyCounter = dom.GetObject('svEnergyCounterGas_<ISEID>_<SERIAL>:<CHANNEL>');
object oSysVarEnergyCounterOldVal = dom.GetObject('svEnergyCounterGasOldVal_<ISEID>');
object oSysVarEnergyCounterResetPressed = dom.GetObject('svEnergyCounterGas_<ISEID>_<SERIAL>:<CHANNEL>_RESET');
object oSysVarEnergyCounterTmpOldVal = dom.GetObject('svEnergyCounterGas_<ISEID>_<SERIAL>:<CHANNEL>_TMP_OLDVAL');
object oSysVarEnergyCounterDeviceReset = dom.GetObject('svEnergyCounterGas_<ISEID>_<SERIAL>:<CHANNEL>_DEVICE_RESET');
boolean bootFlag = oBoot.Value();
real devVal = oEnergyCounter.Value();
real devValMax = oEnergyCounter.ValueMax();
real oldDevVal = oSysVarEnergyCounterOldVal.Value();
real tmpOldDevVal = oSysVarEnergyCounterTmpOldVal.Value();
integer ioldDevVal = (tmpOldDevVal.ToString().ToFloat() * 100000).ToInteger();
real diffVal = 0.0;
real sysVarVal = oSysVarEnergyCounter.Value();
integer tmp_devVal = (devVal.ToString().ToFloat() * 100000).ToInteger();
integer tmp_oldDevVal = (oldDevVal.ToString().ToFloat() * 100000).ToInteger();
if ( oBoot.Value() == true ) {
   oSysVarEnergyCounterDeviceReset.State(true);
   if (ioldDevVal <= 0) {
     oSysVarEnergyCounter.State(0);
   }
} else {
   boolean resetPressed = oSysVarEnergyCounterResetPressed.Value();
   ! boolean devReset = oSysVarEnergyCounterDeviceReset.Value();
   if ( (resetPressed == true) && (oSysVarEnergyCounterDeviceReset.Value() == true) ) {
       oSysVarEnergyCounterTmpOldVal.State(0);
       tmpOldDevVal = 0;
   }
  !Normales Hochzaehlen. Geraetwert > vorheriger Wert
  if ((tmp_devVal >= tmp_oldDevVal) && (oSysVarEnergyCounterDeviceReset.Value() == false)) {
   if (resetPressed == false) {
      diffVal = oEnergyCounter.Value() - oldDevVal;
    } else {
      !Reset pressed
      diffVal = oEnergyCounter.Value() - tmpOldDevVal;
      if ((diffVal.ToString().ToFloat() * 100000).ToInteger() < 0 ) {
             diffVal = oEnergyCounter.Value();
      }
      oSysVarEnergyCounterResetPressed.State(0);
    }
  } else {
    !Geraetewert ist kleiner vorheriger Wert
   !Entweder Ueberlauf, oder Batterietausch
    if (oSysVarEnergyCounterDeviceReset.Value() == false) {
      !Normaler Geraeteueberlauf
      if(tmp_devVal > 0) {
         diffVal = (oEnergyCounter.Value() + devValMax) - oldDevVal;
      }
    } else {
         !Zaehle Geraetewert zum CCU-Zaehler
          diffVal = oEnergyCounter.Value();
          if ((diffVal.ToString().ToFloat() * 100000).ToInteger() == 0) {
                oSysVarEnergyCounterDeviceReset.State(true);
           } else {
            oSysVarEnergyCounterDeviceReset.State(false);
          }
    }
  }
  !Erhoehe den CCU-Zaehler
  oSysVarEnergyCounter.State(sysVarVal + diffVal);
  oSysVarEnergyCounterOldVal.State(oEnergyCounter.Value());
  oSysVarEnergyCounterTmpOldVal.State(oEnergyCounter.Value());
}

Thus, if you are keen, go and debug that helper script which I guess might run into the wrong if()else() branch for your case so that after each CCU boot the counter is increased by exactly the same amount currently stored in the device internal counter. Have phun!

soosp commented 9 months ago

My script is exactly same as that you presented above except the second and third lines:

object oBoot = chn.DPByControl('POWERMETER_IGL.BOOT');
object oEnergyCounter = chn.DPByControl('POWERMETER_IGL.GAS_ENERGY_COUNTER');

instead your

object oBoot = chn.DPByControl('POWERMETER_IEC1.BOOT');
object oEnergyCounter = chn.DPByControl('POWERMETER_IEC1.GAS_ENERGY_COUNTER');
soosp commented 9 months ago

I don't know too much about Re-Ga scripting, but it seems to me, that oldDevVal and tmpOldDevVal variables are 0 at boot (it was tested on my CCU), and diffVal will be set to oEnergyCounter.Value() at the first run, so the oSysVarEnergyCounter will be increased.

github-actions[bot] commented 6 months ago

There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest RaspberryMatic version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

soosp commented 6 months ago

This issue still exists.

soosp commented 5 months ago

This issue still exists and needs solution.

Baxxy13 commented 5 months ago

Bitte mal folgende Code-Zeile in das ZĂ€hlerscript als erste Zeile einfĂŒgen und testen. if (!dom.GetObject ("$src$")) {quit;}

wolwin commented 4 months ago

Auch ich hatte schon lÀnger genau das gleiche Problem, dass nach einem Booten der Raspberrymatic der 'Energie-ZÀhler - Zentrale' um den Wert des 'Energie-ZÀhler - GerÀt' zu hoch war. Ebenfalls war ich der Meinung, dass es sich dabei um ein 'Anpassungsproblem' in den versteckten Systemprogrammen handeln muss. Ich habe dann heute mein Testsystem mit vielen Debug-Ausgaben und einer Boot-Orgie gequÀlt ... ohne Erfolg. Bis dann die 'Erleuchtung' kam: es lag an dem 'ZÀhlerstand-Programm', in dem der Energie-Counter neu gesetzt wird!! Die entsprechenden Zeilen waren schnell auskommentiert ... und siehe da: alles lÀuft korrekt, wie es soll.

Es handelt sich also wahrscheinlich bei dem gemeldeten Fehler um ein Àhnliches Problem - der Systemcode ist m.E. ok !!

Baxxy13 commented 4 months ago

Was aber wenn, wie auf meinem Testsystem, kein 'ZĂ€hlerstand-Programm' vorhanden ist und das Problem trotzdem zu sehen ist? Dann bleibt ja nur das systeminterne 'EnergyCounter Programm' als potentieller Problemverursacher ĂŒbrig.

wolwin commented 4 months ago

OK - habe das ganze natĂŒrlich noch nicht als 'setup from the scratch' durchgefĂŒhrt. Dazu mĂŒĂŸte man tatsĂ€chlich einmal alles von Grund auf neu aufsetzen, um sicher zu sein, was da (scheinbar) nicht funktioniert ... mal sehen ... ist ja unter Proxmox nicht so zeitaufwĂ€ndig ...

wolwin commented 4 months ago

Ich habe die HM-ES-TX-WM Systemprogramme untersucht. Basis war 'RaspberryMatic-3.73.9.20240130-ova' unter Proxmox. Als HM-ES-TX-WM wurde die Asksin-Version von Jerome benutzt. Folgende Tests wurden durchgefĂŒhrt

0.) Installation: Der HM-ES-TX-WM wurde am System angelernt - dabei wurden die internen Systemprogramme 'prgEnergyCounter_xxxx_ESTXWMCyyy:1' und 'prgEnergyCounterGAS_xxxx_ESTXWMCyyy:1' mit den zugehörigen internen Systemvariablen korrekt angelegt.

1.) Boot-Test mit der Original-Konfiguration: Der von soosp gemeldete Fehler konnte nachgestellt werden: nach dem Booten der Raspberrymatic ist der 'Energie-ZÀhler - Zentrale' um den Wert des 'Energie-ZÀhler - GerÀt' zu hoch. grafik grafik grafik

2.) Fehler-Lösung: Änderung der Aktualisierungsabfragen von 'prgEnergyCounter_xxxx_ESTXWMCyyy:1' und 'prgEnergyCounterGAS_xxxx_ESTXWMCyyy:1' - statt Abfrage auf 'grĂ¶ĂŸer oder gleich 0.00' muß dort 'grĂ¶ĂŸer 0.00' stehen:

grafik grafik


3.) Boot-Test mit der Bugfix-Konfiguration (ohne Verbrauch wÀhrend des Bootvorgangs): Der 'Energie-ZÀhler - Zentrale' behÀlt bei der ersten Meldung des 'Energie-ZÀhler - GerÀt' nach dem Booten den Wert, wie vor dem Bootvorgang. grafik grafik grafik

4.) Boot-Test mit der Bugfix-Konfiguration (mit Verbrauch wÀhrend des Bootvorgangs): Der 'Energie-ZÀhler - Zentrale' wird bei der ersten Meldung des 'Energie-ZÀhler - GerÀt' nach dem Booten um den 'Verbrauch' erhöht. grafik grafik

@jens @Baxxy

5.) Zusammenfassung:

jp112sdl commented 4 months ago

Das entspricht ja der Lösung, die Baxxy bereits vorgeschlagen hatte? https://homematic-forum.de/forum/viewtopic.php?f=65&t=81657#p795795

soosp commented 4 months ago

Bitte mal folgende Code-Zeile in das ZĂ€hlerscript als erste Zeile einfĂŒgen und testen. if (!dom.GetObject ("$src$")) {quit;}

I tested it and experienced that the counter didn't increased at boot.

soosp commented 4 months ago

Changing "greater than or equal" to "greater" also eliminated the increasing of the counter at reboot.

wolwin commented 4 months ago

Das entspricht ja der Lösung, die Baxxy bereits vorgeschlagen hatte? https://homematic-forum.de/forum/viewtopic.php?f=65&t=81657#p795795

Ja, richtig - ich hatte nur die Lösung, nur nicht mehr im Kopf bzw. notiert, woher - habe deshalb den Test durchgefĂŒhrt - die 'Ehre' gehört natĂŒrlich Baxxy !!! Danke dafĂŒr !!!

Baxxy13 commented 4 months ago

Nicht dafĂŒr. Wie auch im Forum geschrieben, es gibt mehrere Problemlösungen.

Tendenziell wĂŒrde ich B bevorzugen, da die reine (von eQ-3 erdachte) "Trigger-Logik" erhalten bleibt.

Die Frage wÀre jetzt noch ob das wirklich alle (messenden) GerÀte betrifft. Oder gibt es Unterschiede Batterie/Netzversorgt | HM/HmIP ?

Auf jeden Fall mal Danke an @wolwin fĂŒr die ausfĂŒhrlichen Tests.

Getestet hatte ich natĂŒrlich auch, aber statt x-mal zu rebooten hatte ich einfach die Events gefaked. 😉

soosp commented 4 months ago

@Baxxy13 @wolwin Dies wurde von Deepl ins Deutsche ĂŒbersetzt. Vielen Dank fĂŒr die Lösungen und all die Fehlersuche Arbeit!

wolwin commented 4 months ago

@Baxxy13 Hmm - habe die B-Version ohne Erfolg getestet ... ich habe den Eindruck, dass die beiden Systemfunktionen beim Booten gar nicht ausgefĂŒhrt werden - mir fehlt jedoch die Motivation (und die interne Systemkenntnis) dies weiter zu verfolgen. 😉

Nur zur VollstĂ€ndigkeit an dieser Stelle: man kann auch - z.B. fĂŒr ZĂ€hlerscripts - bei HSSDP Devices auf das 'LastTimestampSeconds' Attribut ausweichen / abfragen - das wird erst beim zweiten Device Event nach dem Booten gesetzt ... damit kann man falsche ZĂ€hler Differenzbildungen ausschliessen ...

Baxxy13 commented 4 months ago

Wundert mich, normalerweise sollte das zum direkten Abbruch des "Counter-Scriptes" fĂŒhren wenn der Programm-Trigger ein "NULL-Objekt" ist. Das ist der Fall wenn das Programm beim Zentralenstart ausgefĂŒhrt wird.

Die diversen Timestamps zu nutzen ginge natĂŒrlich auch. Wobei ich da am ehesten auf einen validen Timestamp des Datenpunktes prĂŒfen wĂŒrde, um nicht eine Runde zu warten wie bei 'LastTimestampSeconds'.

Aber das einfachste ist wirklich den Trigger auf >0 zu Àndern, da kann nix schief gehen.

jp112sdl commented 4 months ago

Aber das einfachste ist wirklich den Trigger auf >0 zu Àndern, da kann nix schief gehen.

Und wer baut den Patch? 😎

WĂ€re noch zu klĂ€ren, fĂŒr welche internen ZĂ€hler-Programme das angepasst werden mĂŒsste. Momentan gibt es 8, die auf >= 0 (ConditionType(9)) prĂŒfen:

sowie fĂŒr die Sonnenscheindauer

und den RegenzÀhler:

Betrifft das Fehlverhalten auch die Wetter-Sensoren? Also wÀre es sinnvoll, an allen Stellen, die Bedingung auf > 0 (ConditionType(8)) zu Àndern?

wolwin commented 4 months ago

Betrifft das Fehlverhalten auch die Wetter-Sensoren? Also wÀre es sinnvoll, an allen Stellen, die Bedingung auf > 0 (ConditionType(8)) zu Àndern?

Nein - sicher ist das m.E. (erstmal) nur fĂŒr 'Standard EnergyCounter' und 'Current/Gas EnergyCounter' - dort ist der Code der System-Programme identisch - die Tests fĂŒr Änderung des Triggers auf '>0' sind verifiziert. Bei den anderen GerĂ€ten wĂŒrde ich das ohne Test nicht Ă€ndern, da dort der System-Code der GerĂ€te 'anders' ist ...

github-actions[bot] commented 1 month ago

There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest RaspberryMatic version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

wolwin commented 1 month ago

This issue still exists.