Energy Entity is getting truncated, after a power off.
The problem
I have a few Shelly PM mini gen3's on kitchen Appliances that I turn off at night, I get error each morning, It seem that the energy usage is getting truncated to 3 decimal places, and resulting the entity getting the state to go lower (3.333867 to 3.333).
Why is the state getting truncated ?, Can this be fixed?
Logger: homeassistant.components.sensor.recorder
Source: components/sensor/recorder.py:317
integration: Sensor (documentation, issues)
First occurred: 13 October 2024 at 16:25:10 (3 occurrences)
Last logged: 08:30:10
Entity sensor.kitchen_air_fryer_energy from integration shelly has state class total_increasing, but its state is not strictly increasing. Triggered by state 3.333 (3.333867) with last_updated set to 2024-10-13T15:24:16.963027+00:00. Please create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+shelly%22
Entity sensor.kitchen_water_heater_energy from integration shelly has state class total_increasing, but its state is not strictly increasing. Triggered by state 3.002 (3.002951) with last_updated set to 2024-10-14T06:44:57.850867+00:00. Please create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+shelly%22
Entity sensor.kitchen_microwave_energy from integration shelly has state class total_increasing, but its state is not strictly increasing. Triggered by state 1.971 (1.971325) with last_updated set to 2024-10-14T07:28:35.593547+00:00. Please create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+shelly%22
What version of Home Assistant Core has the issue?
core-2024.10.2
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
Shelly
Link to integration documentation on our website
https://www.home-assistant.io/integrations/shelly
Diagnostics information
home-assistant_shelly_2024-10-14T10-25-20.675Z.log
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
Hey there @balloob, @bieniu, @thecode, @chemelli74, @bdraco, mind taking a look at this issue as it has been labeled with an integration (shelly) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of shelly can trigger bot actions by commenting:
@home-assistant closeCloses the issue.@home-assistant rename Awesome new titleRenames the issue.@home-assistant reopenReopen the issue.@home-assistant unassign shellyRemoves the current integration label and assignees on the issue, add the integration domain after the command.@home-assistant add-label needs-more-informationAdd a label (needs-more-information, problem in dependency, problem in custom component) to the issue.@home-assistant remove-label needs-more-informationRemove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.
(message by CodeOwnersMention)
shelly documentation shelly source (message by IssueLinks)
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.
any update on this issue please, as the issue still exits in 2025.1.4, thanks
I checked this out and I discovered that it seems when the device comes back up after a power cycle it looses some precision.
before power cycle:
after power cycle:
this seems to be something that the device does. I imagine it limits the amount of times it stores its data to persistent memory to save on write cycles. this looses precision itself so even if stored the precision it would likely be behind. if it tried to keep up to date it would spam through write cycles like nobodies business.
as I see it, a solution would be to only use 3dp of precision from the sensor in the first place. which means loosing precision permanently which I do not see as an desirable option. for the most part these devices are designed to be left on permanently and that is how most people use them.
could the sensor type be change to only increasing ?, this way the entity in HA should not get updated if the device is power cycled. If the sensor is already this type, then why does the sensor get updated ?, is this a bug for HA core sensor type ?,
maybe force the sensor to always store 6 dp, i.e. if there is a power cycle and the shelly device only reports a 3dp data, then get HA to store x.xxx000, this would then tell HA that the sensor has decreased and the total_increasing should not get updated ??
the sensor only records what the device sends to it. in general total_increasing sensors should not go down. this is ultimately a quirk on how the shelly reports data and I don't think there is a simple solution that doesn't haven't other negative effects. state class information is here
total_increasing warning you when it goes down is doing what it is supposed to do. perhaps you could rewire them in such a way that they are ahead of your cut off switches? so they remain running when you disconnect your appliances overnight?
I think everything is working as intended and you are an edge case that it irritates, you could also look at the logger documentation and look at writing a log filter in your configuration.yaml file which suppresses the warnings. so you wont see them.
total_increasing warning you when it goes down is doing what it is supposed to do. perhaps you could rewire them in such a way that they are ahead of your cut off switches? so they remain running when you disconnect your appliances overnight?
unfortunately this not possible, as the devices plug into smart sockets with no power monitoring and the shelly pm gen3 is hardware inline between the smart socket and the device, so when the smart socket powers off the devicee the shelly also losses power.
surely total_increasing should never be allowed to store a value lower than it already has, this makes no sense sense, sure the error should be loggged, But NO value should be stored, else why have a total_increasing only.
could you not code the sensor NOT to store an updated value IF the value is lower than it already has?, or maybe add an option the device settings to only allow a 3dp value to be stored, as this should not be an issue for high powered devices like Microwave ovens, Air friers or Kettles, etc, as these device should not be using less than 1Wh, and I do not think the shelly PM gen3 power sensor can log less than 1w anyway.
unfortunately this not possible, as the devices plug into smart sockets with no power monitoring and the shelly pm gen3 is hardware inline between the smart socket and the device, so when the smart socket powers off the device the shelly also losses power.
can you put the shelly behind the socket instead of in line? this is how they are usually fitted.
why are you switching off the appliances overnight anyway? do they have some standby vampire usage or something?
each of your suggestions would cause more problems than they would solve.
e.g. a sensor totally resets from 100kWh to 0 because of a bug or something, currently home assistant pops and error and continues to track data. however under what you suggest it would spam errors and not log anything until it went over 100kWh.
processing the incoming data to remove precision permanently means that data is lost and in the majority of cases its probably not what people want. it may also still not work perfectly depending on how often the device writes to memory.
perhaps having an advanced option to reduce precision permanently and not just what is displayed might be something that could be done. but it would likely to do with entities in the recorder and not directly on the integration. but that is way above my level of understanding.
if you want more control over the data the device puts out when you could (although I don't recommend it) maybe flash it with ESPHome. it has some documentation here but this does require some hardware modification to access the pins to flash it.
realistically I think the best solution for you is to try is to write a logger filter as I mentioned above that way at least you wouldn't see it.
can you put the shelly behind the socket instead of in line? this is how they are usually fitted.
unfortunately no, as in the UK we have double sockets that are powered from a single line in, and I require the 2 sockets to have separate power monitoring, this is why I had to wire the shelly PM inline with the devices.
why are you switching off the appliances overnight anyway? do they have some standby vampire usage or something?
all my electrical devices get powered OFF over night, to reduce in electric bills (this does save a bit over the year, enough to warrant do it anyway)
each of your suggestions would cause more problems than they would solve.
e.g. a sensor totally resets from 100kWh to 0 because of a bug or something, currently home assistant pops and error and continues to track data. however under what you suggest it would spam errors and not log anything until it went over 100kWh.
could you not perform a check, that If the usage has gone down by only less the 1 watt (0.000999 kWh) do NOT update the sensor, or if the sensor has been reset to 0 then obviously update it to 0.
perhaps having an advanced option to reduce precision permanently and not just what is displayed might be something that could be done. but it would likely to do with entities in the recorder and not directly on the integration. but that is way above my level of understanding.
I was meaning could you not simply code a filter to reduce the data that is passed from the shelly to only use 3 floating positions, this should be fairly simple to do ?, this way HA only ever sees 3dp. (this should be an option in the device settings obviously)
atm you have these config options, add an additional inn here Use only 3 decimal places for energy monitoring or device is powered off, when not in use, something like that.
realistically I think the best solution for you is to try is to write a logger filter as I mentioned above that way at least you wouldn't see it.
This will not help the energy dashboard showing minus data for these devices.
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.
Just keeping this alive as it is still an issue
Hi, I don't know if it's the same problem. I noticed today that the refrigerator's kWh count isn't working correctly.
In HA, the count resets to 0 every so often, I think during blackouts or power surges. In the official Shelly app, however, the count is correct.
P.S. I have HA OS constantly updated in VM on Proxmox.
Hi. Similar problem with the Shelly PM Mini Gen3... The total energy entity is only updated once a day at 3 a.m. in Home Assistant.
It is similar but it is not the same issue and since we don't have a solution for the issue above if you want to progress with your issue please create a new issue and download the diagnostics from the device card in Home Assistant and attach it in a comment.
In addition please enable Debug for Shelly integration, wait until you see the energy updated on the device, disable debug and attach the log.
Note: it is better to drag the log into the comment (which will add it as an attachment) and not copy paste as it is hard to read logs in GitHub.
Thanks