I have a utility meter with a source sensor from an esphome device via MQTT.
I had this running for a few days and the utility meter and its source appeared in step sync.
I shut down the server (hosting HA and MQTT broker) for half an hour. The esp8266 device continue running and the total eventually made its way to MQTT and HA once server was started up. However, there is now a disparity of aroud 100W (consistent with the use over that half hour) between utility meter and the esphome source sensor.
I had expected the state to âcatch upâ since the source sensor was accumalating energy useage whilst the HA host was down. Why does the daily utility meter not catch up?
Itâs because the utility meter ignores state changes from unavailable. This is a good thing or your utility meter would double every time the source sensor became unavailable. Not tracking while shutdown is a known side effect / limitation of this.
Good news though. Looks like a fix for this will be included in a future release:
This relies on your source sensor being the type that always counts up and never resets though.
Thanks for pointing out those pages, much appreciated. Itâs a situation I had not foreseen.
I had previously used a currentcost enviR monitor with an HA integration. I recently switched to an MQTT, ESP & current clamp solution. I had assumed, with there being an MQTT intermediary, and the esp continuously recording, the totals would remain accurate in HA.
Since my source sensor is derived from esphome total_daily_energy (which resets daily) I presume the upcoming enhancement may not help in my case. I have daily, weekly and monthly utility meters all based on the same source.
With a daily, weekly and monthly utility_meter, all based on the same source sensor, would it be valid and ease corrections if I set the source of the weekly and monthly meters to be the daily meter?
Then, when I corrected the daily meter for unaccounted usage, that correction would feed through to the weekly and monthly meters?
EDIT: I tried this and the weekly (and presumably monthly) meters do not roll over as expected. I guess utility_meter cannot be used as a source.
I understand this logic, but itâs interesting to me that the Energy tracker doesnât have this limitation (thankfully). Given a state class total_increasing sensor, shouldnât it be straightforward enough to store the last known good value and get a delta from that whenever the new value is after the source comes back from unavailable? My understanding is that the Energy tracker has logic to treat a new value as having reset to 0 only if the it is more than 10% lower than the last known good value, which avoids the âyour utility meter would double every time the source sensor became unavailableâ problem. That solution potentially has a problem of breaking counts for integrations that reset to zero very often (i.e. more than once while it is unavailable), but supporting that behavior seems like a lower-priority feature than being able to handle consistently updating sources correctly.
It seems to me that the behavior of ignoring state change from unavailable has the effect of making utility_meter essentially useless if I want complete consistency with the source. I have a total_increasing energy sensor that resets once a day and a lifetime gas sensor that only counts up, and with either of these as a source for utility_meter I will end up with a discrepancy after any HA downtime or restarts when the utility is in use. Using the exact same source directly in the Energy integration works perfectly.
I started using utility_meter in order to make daily and monthly sensors that mirror what the Energy integration shows so that I can have access to the Energy values in templates/views/etc (which I canât access directly from the Energy integration because it doesnât provide entities AFAIK). However, given the inaccuracies caused by ignoring the first value after a reset to 0 or an unavailable state, I might have to find a different solution.