utility meter calibrate unreliable

[friendlycrow]

The problem

`data: value: "0" target: entity_id:

• sensor.dishwasher_water_most_recent action: utility_meter.calibrate`

state_class: total_increasing status: collecting last_period: "0" last_valid_state: "0" last_reset: "2023-03-09T12:56:12.506082+00:00" unit_of_measurement: L device_class: water friendly_name: Dishwasher water - most recent This code sometimes zeroes the value and sometimes not. In this case, it did not:

Strangely, the accumulated 52L were recalibrated to 26L. Not to zero.

This has been acting up for the past year or so. Is it a bug, or am I making a mistake using the function? Utility_meter.reset did not work for me at all when I wrote this about three years ago. That's why I used utility_meter.calibrate instead.

/Fumble

What version of Home Assistant Core has the issue?

2024.10.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

utility meter

Link to integration documentation on our website

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

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[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)}}

[dgomes]

can you share the source sensor graphic for the same period of time ?

[friendlycrow]

Thanks for looking into this! This is the dishwasher's own sensor, that feeds into the helper. Is this what you mean?

[dgomes]

can you download the diagnostics of the utility_meter ?

[friendlycrow]

home-assistant_utility_meter_2024-10-23T08-01-43.584Z.log

[dgomes]

Thank you for sending your logs, but I actually asked for the the diagnostics files available from the integration webpage.

But looking at the logs I see issues: 2024-10-23 02:02:21.554 DEBUG (MainThread) [homeassistant.components.utility_meter.sensor] Calibrate Dishwasher energy = 0 type(<class 'str'>)

you must calibrate with a number 0 not a string "0"

It's very common to see the dishwasher unavailable:

2024-10-23 07:54:19.562 DEBUG (MainThread) [homeassistant.components.utility_meter.sensor] Dishwasher energy received an invalid state change coming from sensor.dishwasher_energiforbrukning (unavailable > 0)

[friendlycrow]

Apologies for my lack of understanding. Was it this file you asked for? config_entry-utility_meter-c3b00a164dd10593b5515801a391c0dd(1).json

This is the relevant section of the automation. I hope it's clear despite the localized language. Have I specified a string? It was not my intention. How do I change it?

I assume the unavailability thing is a z-wave issue? I have a dimmer in the mesh on the direct path to the dishwasher, acting up.

[dgomes]

The unavailability is what is triggering the strange values.

the error in the calibration is much more strange, as it should immediately show the calibrated value, are you calibrating the sensor entity of the utility_meter ?

[friendlycrow]

"The unavailability is what is triggering the strange values." What strange values?

"are you calibrating the sensor entity of the utility_meter ?" Does this answer the question? 2024-10-23 02:02:21.554 DEBUG (MainThread) [homeassistant.components.utility_meter.sensor] Calibrate Dishwasher energy = 0 type(<class 'str'>)

Looking at your previous post: "you must calibrate with a number 0 not a string "0"" As you can see in the visual editor dialog I quoted above, 0 is specified - not "0". However, looking in YAML, it says "0", so I made that change in YAML (bypassing the visual editor). Will see if that solves it.

"2024-10-23 07:54:19.562 DEBUG (MainThread) [homeassistant.components.utility_meter.sensor] Dishwasher energy received an invalid state change coming from sensor.dishwasher_energiforbrukning (unavailable > 0)" This refers to the source sensor that utility meter receives information from. It resets to zero at the end of the dishwasher program and probably goes off the air entirely when the dishwasher turns off. That's why utility meter is needed.

[dgomes]

that reset to 0 at the end is the issue... the utility_meter integration is made for utility meters that are always increasing

[friendlycrow]

"Dishwasher water - most recent" is the utility meter helper. I can't see how a source sensor reset at the end of the cycle can make it wrong from the start:

Instead, it remembers the total just as I had intended. I find it clear from the graph that the error happens when calibrating. Using the wrong type (string vs numeric) probably had something to do with it, but in this graph that issue had been corrected and it still comes out wrong.

Zooming in on the time when it goes wrong, I found this spike on the source sensor: It's difficult to see because of the colors, but looks like a short flash of the previous value. The utility meter picks that up and counts from there. I have now added a short delay to the calibration to see if it's possible to calibrate after that spike. That should make it work. We'll see tomorrow!

[friendlycrow]

It worked!

Conclusions: 1 There is nothing wrong with the utility meter - it behaves as expected. 2 There is something wrong with the visual editor - it passes a string to a numeric variable. 3 The cause of the error was a two second spike in the source sensor.

You can go ahead and close this issue. Thank you for your prompt support!

[dgomes]

Thank you for your explanation, might be useful to others :)