RaspberryMatic
RaspberryMatic copied to clipboard
jens-maus
HM-ES-TX-WM_CCU from jp112sdl gas values are increasing after CCU restart
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:
After reboot:
And these are the values when device first appears:
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
- Check the counters.
- Reboot.
- 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.
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:
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!
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');
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.
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Bitte mal folgende Code-Zeile in das Zählerscript als erste Zeile einfügen und testen.
if (!dom.GetObject ("$src$")) {quit;}
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 !!
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.
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 ...
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.
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:
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.
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.
@jens @Baxxy
5.) Zusammenfassung:
- Aus meiner Sicht müßte dieser Fehler bei 'allen HM-ES-TX-WM' Default - Installationen auftreten ... das habe ich nicht weiter untersucht. Die vorgeschlagene Korrektur könnte doch in die Raspberrymatic übernommen werden - wohl wissend, dass damit die Fehler in vorhandenen Installationen immer noch da sind.
- In dem Zusammenhang ist mir aufgefallen, dass obwohl das HM-ES-TX-WM ordnungsgemäß abgelernt wurde, die beiden internen Systemprogramme und alle zugehörigen internen Systemvariablen nicht gelöscht wurden - sie müssen manuell z.B. über die WebUI gelöscht werden ...
Das entspricht ja der Lösung, die Baxxy bereits vorgeschlagen hatte? https://homematic-forum.de/forum/viewtopic.php?f=65&t=81657#p795795
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.
Changing "greater than or equal" to "greater" also eliminated the increasing of the counter at reboot.
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 !!!
Nicht dafür. Wie auch im Forum geschrieben, es gibt mehrere Problemlösungen.
- A: den Trigger ändern auf >0
- B: die Scriptausführung verhindern wenn nicht der Datenpunkt sondern die Zentrale der Trigger ist (was nach einem Reboot der Fall ist)
if (!dom.GetObject ("$src$")) {quit;} - C: den beliebten "Programme beim Zentralenstart nicht ausführen" - Workaround
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. 😉
@Baxxy13 @wolwin Dies wurde von Deepl ins Deutsche übersetzt. Vielen Dank für die Lösungen und all die Fehlersuche Arbeit!
@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 ...
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.
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:
-
Standard EnergyCounter: /www/rega/pages/tabs/admin/views/newdevices.htm#L896
-
Current/Gas EnergyCounter: /www/rega/pages/tabs/admin/views/newdevices.htm#L1022
-
HmIP-PSM EnergyCounter: /www/rega/pages/tabs/admin/views/newdevices.htm#L1127
-
POWERMETER_IEC1: /www/rega/pages/tabs/admin/views/newdevices.htm#L1210
-
HmIP-ESI Counter ENERGY: /www/rega/pages/tabs/admin/views/newdevices.htm#L1317
-
HmIP-ESI Counter GAS: /www/rega/pages/tabs/admin/views/newdevices.htm#L1401
sowie für die Sonnenscheindauer
- HmIP-SWO-B -> (basic): /www/rega/pages/tabs/admin/views/newdevices.htm#L1523
und den Regenzähler:
- HmIP-SWO-PL/PR -> (plus/pro): /www/rega/pages/tabs/admin/views/newdevices.htm#L1637
Betrifft das Fehlverhalten auch die Wetter-Sensoren?
Also wäre es sinnvoll, an allen Stellen, die Bedingung auf > 0 (ConditionType(8)) zu ändern?
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 ...
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.