Helper created Tariff Utility Meter incorrectly adjusting values from input source?

[zestysoft]

The problem

I've documented this out in the community forums here: https://community.home-assistant.io/t/negative-values-in-tariff-utility-meter-while-positive-in-parent-source/839130/2

At the daily reset of the input source dropping to zero, the tariff utility meter doesn't also drop to zero, but instead drops far into negative values.

What version of Home Assistant Core has the issue?

core-2025.1.0

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Utility Meter

Link to integration documentation on our website

https://www.home-assistant.io/integrations/utility_meter/

Diagnostics information

debug.log

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

I think this query shows the problem? -- last_period should be zero?

sqlite3 home-assistant_v2.db "SELECT m.entity_id, s.state, datetime(round(s.last_changed_ts), 'unixepoch') AS ts, json_extract(a.shared_attrs, '$.last_period') AS last_period FROM states s JOIN states_meta m ON s.metadata_id = m.metadata_id LEFT JOIN state_attributes a ON s.attributes_id = a.attributes_id WHERE m.entity_id='sensor.pg_e_off_peak' ORDER BY s.last_changed_ts DESC LIMIT 5;" sensor.pg_e_off_peak|-11197.0|2025-02-01 21:11:23|45420.0 sensor.pg_e_off_peak|-12059.0|2025-02-01 20:42:03|45420.0 sensor.pg_e_off_peak|unknown||0 sensor.pg_e_off_peak|-12059.0||45420.0 sensor.pg_e_off_peak|-11988.0||45420.0

Here's the parent data: sqlite3 home-assistant_v2.db "SELECT datetime(round(coalesce(s.last_changed_ts, s.last_updated_ts, s.last_reported_ts)), 'unixepoch') AS ts, m.entity_id AS sensor, s.state FROM states s JOIN states_meta m ON s.metadata_id = m.metadata_id WHERE m.entity_id='sensor.pg_e_daily_consumption' AND s.state != 'unknown' ORDER BY coalesce(s.last_changed_ts, s.last_updated_ts, s.last_reported_ts) DESC LIMIT 5;" 2025-02-01 22:02:21|sensor.pg_e_daily_consumption|47174.0 2025-02-01 22:00:16|sensor.pg_e_daily_consumption|47141.0 2025-02-01 21:59:11|sensor.pg_e_daily_consumption|47123.0 2025-02-01 21:58:06|sensor.pg_e_daily_consumption|47106.0 2025-02-01 21:57:01|sensor.pg_e_daily_consumption|47088.0

[home-assistant[bot]]

Hey there @dgomes, mind taking a look at this issue as it has been labeled with an integration (utility_meter) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of utility_meter can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign utility_meter Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

utility_meter documentation utility_meter source _{^{(message by IssueLinks)}}

[zestysoft]

Here are fresher graphs showing the issue:

Data in grafana of all three tariffs: Same data of just off-peak: Input source:

[dgomes]

Could you please download the utility_meter diagnostic (go to the device webpage, there you find it in the left pane)

I don't understand yours grafana graph... why is it negative and related to utility_meter ?

[zestysoft]

The only utility meter stuff I have anywhere is in the helpers tab and there is no choice to download diagnostics.

The grafana graph shows the data from each of the three tariff meters that were created when I created the PG&E Utility Meter. The negative stuff you see there should align with the PG&E Off-Peak Utility Meter.

If I go into Integrations and attempt to install "Utility Meter" my only choice is "Utility Meter (helper)" which redirects to the Helpers page if I attempt to add it:

[dgomes]

https://<YOUR IP>/config/integrations/integration/utility_meter

[zestysoft]

config_entry-utility_meter-01JK1XT3ZTTWRSV72CF48XADHE.json

[dgomes]

Can you provide the configuration of:

sensor.pg_e_daily_consumption

[zestysoft]

[dgomes]

I assume that's statistic integration

Can you provide history graph of sensor.pg_e_daily_consumption ?

[zestysoft]

It's a helper: "Combine the state of several sensors"

If you scroll up, look for the "input source" screenshot -- that should be this.

[dgomes]

turn off "net_consumption"

[zestysoft]

But I have net consumption. I have solar that can push back to the grid?

[dgomes]

The thing is your source sensor has that big drop, and since you have net consumption turned on, it is interpreted as a large export (therefore the negative value)

That big drop is not a "periodically_resetting" use case because it does not go to 0

So we have here a corner use case which I don't know how to address.

Strictly speaking, if you have net consumption, any drop (small or large) should be accounted as is today.

Any chance of disabling sensor.pg_e_daily_consumption reset ?

[zestysoft]

So it does go to zero, it's just that there is a LOT of usage once midnight hits and the resolution of the physical meter that reads the data probably isn't catching it at exactly zero.

The "combine the state sensor" pulls from the physical reading devices, and those reset to zero daily on their own.

[zestysoft]

If I tell the utility meter that it should reset to zero daily at midnight, it should expect a large drop, right? It should just set the last state to zero at midnight?

[zestysoft]

Otherwise, if the utility meter had another setting, say "export", I could give it a different sensor to read from so that it knows those numbers are pushing back to the grid vs the input sensor resetting itself?

[dgomes]

utility_meter at midnight sets the state to zero, regardless. It does not check or expects anything from the sensor. What happens in your case is the source sensor itself resets

Otherwise, if the utility meter had another setting, say "export", I could give it a different sensor to read from so that it knows those numbers are pushing back to the grid vs the input sensor resetting itself?

That would be a new feature and involves relevant changes in the code base

Since your source already resets daily, why don't you change the utility meter from a daily cycle to a "no cycle" ? I think it actually fits your use case. You don't need the utility_meter to reset, because you already reset on the source. The other option is to make the root sources not to reset.

[zestysoft]

Oh! I'll try that. Do you know where I can change that setting? It seems to only be an option upon creation?

Edit: I ended up just deleting the existing utility meters and re-creating. It is set to "no cycle" now, but I'm leaving the periodic zero setting since that will happen any time the physical meter resets. I'm also leaving on the net metering for now.

Not sure how to clear the current issue though where all of this is still negative. I think I'd need to do that at least once manually now that it's "no cycle"?

[dgomes]

you can calibrate (home assistant action) the values to whatever value you want

[zestysoft]

Nice! TIL. Lets see how tonight goes. One other thing I can try is delaying when the large loads hit to happen some time after midnight. Maybe the zero'd value will get properly read.

[zestysoft]

The results are the same, albeit not as drastic a drop as before - I did also add a delay so that the large loads won't immediately feed off the grid at midnight.

Unfortunately the physical sensors won't ever return exact zero because power is always flowing. This is the raw data being reported from the sub panel for my house:

and this one is for the garage which isn't currently pulling any electricity because it's dedicated for the EV that I currently have postponing charging:

So the combined input source that the utility meters uses will always report some kind of positive number after the drop at midnight.

I'm curious how others have this working with net metering.

One possible fix would be to see what's physically possible to export within the time given during the drop. Here the table is showing a drop of 28kWh of energy in one second. At 240 Volts, that would be 420,000 amps which far exceeds what a standard home is capable of delivering.

[dgomes]

well you can use a filter to remove that too:

https://www.home-assistant.io/integrations/filter/#outlier

[zestysoft]

Where would I apply that filter? To be clear, my input source data is fine -- it's the utility meter misinterpreting the drop as an export, right? Because net metering is enabled?

[dgomes]

you would apply the filter in between sensor.pg_e_daily_consumption and the utility meter in order to remove that reset, by setting the radius of the filter to a number large enough that would only account for the reset and not grid feed.

The issue here is that your reset is not truly a reset...

[zestysoft]

It is a true reset, it just doesn't deliver the data exactly at midnight when it's perfectly at zero. I can't believe I'm the first person to run into this.

I've created a workaround by creating an automation to force the calibration to zero at midnight: alias: Reset PG E Off Peak at Midnight trigger:

• platform: time at: "00:00:00" action:
• service: utility_meter.calibrate data: entity_id: sensor.pg_e_off_peak value: 0

Given that the Utility Meter already has an option to set a reset cycle duration, I don't understand why your code doesn't just calibrate to zero when that hits.

[dgomes]

midnight, 5 minutes past midnight, 10AM it's irrelevant for the utility_meter - we detect a reset through a state = 0

the reset in utility_meter is to calibrate all sensors to 0 and save the previous value... no magic involved

Besides the calibration action you also have a reset action that will do the reset "manually" (or through an automation)

[zestysoft]

The issue here is that the integration still can't tell if that zero is due to net metering or a reset.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant 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.