Meter Reading

logo

This is a simple rule that works with an accumulating sensor reading that can be reset unpredictably. For example, a sensor that keeps track of the total kWh used but resets back to zero when the sensor loses power.

The rule will add the delta from the previous reading to the current reading to the Item holding the total. However, when the sensor Item get’s reset the rule treats the current reading as the delta. Therefore this rule only works for an accumulating sensor where the reported reading is always increasing.

If the total Item is NULL or UNDEF, it’s initialized to 0 and the delta becomes the first value.

Managing the total Item (e.g. resetting it once a day, adding up the sum for the week or month, etc.) are not handled by this rule.

Language: JavaScript Scripting

Dependencies:
JavaScript Scripting add-on installed with the default configuration

Changelog

Version 0.1

  • initial release

Resources

https://raw.githubusercontent.com/rkoshak/openhab-rules-tools/main/rule-templates/counting/counting.yaml

2 Likes

Hi Rich

just wanted to say thank you. It works an is absolutly perfect for the shelly devices which lose the sum value all the time.

BR
Daniel

Hi Rick

Today I seem to have run into a problem with the rule. It will probably be my setup, but I would like to understand it.
I have the regular energy item from the meter and the sum item that I write the sum into. For some reason my system crashed yesterday and I rebooted today. Now the total counter value was added at startup. So it looks like the counter was reset, which didn’t happen.
Value meter about 2150kWh
Value sum yesterday about 2150kWh
Value meter after reboot 2160kWh
Value sum after reboot 4310kWh

Both items are saved on every change in rrd4j and restore on startup is enabled.

Thanks
Daniel

It’s possible that the restoreOnStartup failed so when the rule ran the sum Item was still NULL.

It’s also possible that the rule was triggered before the restoreOnStartup happened, though that’s less likely.

If it happens consistently, I’ll need some more logs, including the events.log. If it only occurred this one time after the crash, we probably won’t ever know exactly what happened.

There isn’t a whole lot that we can do inside the rule to deal with this. The rule can’t know the difference between the Item just not having been restored or just having been initialized.

If you happen to configure using openhabian, you may have ZRAM in use for your persistence services. In the event of an unexpected crash or power failure, persistence data since last controlled reboot may be lost forever. Restore-on-startup may then pull up data from long ago.

1 Like

thank you. Yes U use openhabian so this may be the reason.

If it happens again I’ll post the events log.

Thank you

BR