sensor.epcube_battery_power frozen state during standby / incorrect reporting

[vincenzocrupi]

The integration reports incorrect or "frozen" values for the battery power sensor when the system should be in a standby or idle state. Instead of showing 0W (or a minimal idle consumption), the sensor remains stuck on a specific last-read value for an extended period.
Technical Details:
• Affected Sensor: sensor.epcube_battery_power (and potentially related power entities).
• Observed Behavior: The sensor does not update its state to 0 when the battery is not charging or discharging. It retains a value (probably the last reported value ) until the battery will reports new real values, even when there is no actual power flow.

Can you please investigate?

[vincenzocrupi-gif]

This is an example of the bad value reported this morning at 6AM.
In the situation where I have a total consumption of 400W and 400W withdrawned from the grid, the battery actually is in standy-by also according to original EP Cube App.

[Bobsilvio]

Two separate things were going on here, and both are fixed in v1.6.1 — please update and let me know what you see.

1. The value staying stuck for a long time — this was not the battery sensor at all.

A TOU field (lowElectricityPriceTime) holds a string like "23:00_07:00_" but was published as an energy sensor in kWh. Home Assistant raised a ValueError while pushing its state, and since that happens inside async_update_listeners(), the exception aborted the whole notification cycle: every sensor kept the value it had at the last reload, even though the API data kept arriving correctly. Same root cause as #26, reported there with different words. If you use Time of Use mode, this is almost certainly what you were seeing — a value frozen until you reloaded the integration.

2. The battery never reading exactly 0 in standby — that one is real, and now fixed.

homeDeviceInfo does not expose a battery power field at all, so the sensor is estimated:

battery = solar + grid − backup − non-backup

Those fields are not sampled at the same instant, and the API sends them in units of 10 W. A one-unit mismatch (39 vs 40) is already 100 W of phantom battery flow. In your 6 AM screenshot — 400 W of consumption, 400 W from the grid, no sun — the terms should cancel exactly, and any residual is sampling noise, not a real flow. Values below 100 W are now reported as 0.

What I'd ask you to check after updating:

• does the sensor track changes continuously now, instead of sitting on one value until a reload?
• does it read 0 when the battery is idle and the app agrees it is idle?

If it still freezes after the update, tell me and send the entity's history over a few hours — that would mean something else is going on and I'll dig further.

One thing I want to be transparent about: at high power the estimate runs about 10% above the real figure, because it cannot account for conversion losses. The exact value exists in the API, but only in the 5-minute historical series — a sensor built on it would only refresh every 5 minutes, which is worse for live use. If you want that value for energy accounting I can add it as a separate, optional sensor.

Silvio

[vincenzocrupi-gif]

Hello I still see the version 1.4.3 so I canton upgrade my current Release. Do you know how can I upgrade to 1.6.1? Thanks Il giorno gio 6 ago 2026 alle 12:49 Bobsilvio ***@***.***> ha scritto:

…

*Bobsilvio* left a comment (Bobsilvio/epcube#20) <#20 (comment)> Two separate things were going on here, and both are fixed in v1.6.1 — please update and let me know what you see. *1. The value staying stuck for a long time — this was not the battery sensor at all.* A TOU field (lowElectricityPriceTime) holds a string like "23:00_07:00_" but was published as an energy sensor in kWh. Home Assistant raised a ValueError while pushing its state, and since that happens inside async_update_listeners(), the exception aborted the whole notification cycle: *every* sensor kept the value it had at the last reload, even though the API data kept arriving correctly. Same root cause as #26 <#26>, reported there with different words. If you use Time of Use mode, this is almost certainly what you were seeing — a value frozen until you reloaded the integration. *2. The battery never reading exactly 0 in standby — that one is real, and now fixed.* homeDeviceInfo does not expose a battery power field at all, so the sensor is estimated: battery = solar + grid − backup − non-backup Those fields are not sampled at the same instant, and the API sends them in units of 10 W. A one-unit mismatch (39 vs 40) is already 100 W of phantom battery flow. In your 6 AM screenshot — 400 W of consumption, 400 W from the grid, no sun — the terms should cancel exactly, and any residual is sampling noise, not a real flow. Values below 100 W are now reported as 0. What I'd ask you to check after updating: - does the sensor track changes continuously now, instead of sitting on one value until a reload? - does it read 0 when the battery is idle and the app agrees it is idle? If it still freezes after the update, tell me and send the entity's history over a few hours — that would mean something else is going on and I'll dig further. One thing I want to be transparent about: at high power the estimate runs about 10% above the real figure, because it cannot account for conversion losses. The exact value exists in the API, but only in the 5-minute historical series — a sensor built on it would only refresh every 5 minutes, which is worse for live use. If you want that value for energy accounting I can add it as a separate, optional sensor. Silvio — Reply to this email directly, view it on GitHub <#20?email_source=notifications&email_token=B6C5FY6CMXAYK7JIOWG2HZT5IRPELA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRQGM3DKNJQGA4KM4TFMFZW63VGNVQW45LBNSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5203655008>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B6C5FY4RGOHX2NK6NA6PYM35IRPELAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNRYGUZDMMJRHNEXG43VMU5TIMJTHAZTMMZQG442C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/B6C5FY3JV366WM4B6PWN2KD5IRPELA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRQGM3DKNJQGA4KM4TFMFZW63VGNVQW45LBNSSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/B6C5FY5UU42A7RMKTVK5EKD5IRPELA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRQGM3DKNJQGA4KM4TFMFZW63VGNVQW45LBNSSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Bobsilvio]

That was my fault, not yours: the fixes were on main but I had not published a release, and HACS only offers released versions — so you correctly saw 1.4.3.

v1.6.2 is now released. In HACS, open the EP Cube integration and hit the update (if it still shows 1.4.3, use the three-dot menu → "Redownload", or reload HACS). Then restart Home Assistant.

Please read the note at the top of the release before updating: sensor.epcube_systemstatus changes from a number to a text state, and entity identifiers change (transparently for a single EP Cube — your entity IDs and history are preserved).

Once you're on 1.6.2, the two things I'd like you to check on sensor.epcube_battery_power:

• does it follow changes continuously, instead of sitting on one value until you reload the integration?
• does it read 0 when the battery is idle and the official app agrees it is idle?

Silvio