Battery sensors stay 'unknown' when the integration starts before evcc is ready

[essendyx]

Problem

After an evcc restart (e.g. an add-on update) or an HA/host reboot, all battery sensors (sensor.evcc_battery_soc, battery_power, battery_capacity, …) can stay unknown permanently, while evcc itself (/api/state → battery.soc) reports correct values. Reloading the integration fixes it — same as reported in #244.

Cause

_battery_data_as_object is only evaluated once in read_evcc_config_on_startup(). When the integration starts while evcc is still starting up, the battery object is missing (or empty), so the flag stays False. The version fallback can never kick in (>= 999.209.8), so the integration creates the prefix sensors that read batterySoc, batteryPower, … — keys that evcc no longer publishes.

evcc dropped these keys in 0.301.0: core/site.go in 0.300.2 still has site.publish(keys.BatterySoc, …), since 0.301.0 only site.publish(keys.Battery, site.battery) is left.

Fix

• Use 0.301.0 as the version fallback instead of the placeholder 999.209.8.
• Apply the fallback whenever the object detection did not set the flag (not only when battery is missing/None), so an empty battery object at startup is covered too.

Observed with evcc 0.316.0 (HA add-on) and ha-evcc 2026.9.5: the add-on update restarted evcc, the integration reloaded one minute later and battery sensors stayed unknown until a manual reload.

🤖 Generated with Claude Code

[marq24]

Hi Claude - I have two questions for you...

1. If there could be the situation, that evcc instance is not fully started yet - and the integration has already a section actually waiting/checking if the configured evcc server is ready to adjust then this section of the integration??? Instead of 'simply' guessing that switching the default's would be the holy grail solution? There could be so many other stuff that might get broken (when the Integration init will be started, but evcc is not fully available yet.

   Then it would make IMHO way more sense to ask evcc for a server is ready signal (the integration could check) - instead "just2 trying to patch something which is in your opinion not correct

2. Please take the time and read the issue template here from this repository - if you can't find it easily I help you here with a link -> https://github.com/marq24/ha-evcc/blob/main/.github/ISSUE_TEMPLATE/1-report-an-issue.yaml So Claude, what dou you think about the first item of the available checklist?

[essendyx]

Hi marq24,

this is Dennis, the human behind the PR, answering myself now. You're right on both points, and sorry about that.

To be transparent: I used Claude Code to track this down, and it opened the PR on my behalf without either of us reading your contribution rules first. That's on me. I've now read the checklist, and I understand if you'd rather close this.

On your first point, I agree: a version-based guess is the wrong place to fix it. evcc already exposes a readiness signal: /api/state contains startupCompleted, which evcc sets to false at the start of startup and to true once it's fully up (cmd/root.go in 0.316.0). My idea: at setup the integration raises ConfigEntryNotReady as long as startupCompleted is false, so HA retries later. That way the format detection (battery, grid, …) always runs against a fully started evcc.

What I actually saw: evcc 0.316.0 as an HA add-on, ha-evcc 2026.9.5. The add-on auto-updated at 12:28, the integration reloaded at 12:29, and all sensor.evcc_battery_* stayed unknown until I reloaded it manually, same as in #244. I didn't have debug logging enabled at the time. I can enable it and reproduce with the add-on restart if that helps.

If you'd like me to rework the PR in that direction, I'm happy to do so. Otherwise feel free to close it.

Thanks for maintaining the integration :))
Dennis

[marq24]

Hi Dennis,

thanks for you kind reply - I hope you can understand, that it can be quite challenging for me as human to deal with "fíxes" & "suggested fixes" that IMHO are not coming close to fix anything...

So if there is really a startupCompleted in the states api, then indeed checking this would be the reasonable thing to do (to wait for this signal)... Before you going to spend more of your tokens with that, let me first check, if there is a simple hand crafted solution for that...

I'll be back!

[marq24]

looks like at the end Claude was also not so completely wrong with his suggestion... [even if I still want to keep the version check just as fallback]...

I will update the main branch shortly and It would be cool, if you would review the change if it's reasonable for you too

[essendyx]

Hi marq24,

thanks a lot, I really appreciate that you took the time to look into it yourself.

And yes, I can fully understand your point. Getting "fixes" that don't really fix anything must be pretty tiring, especially when you maintain a project like this in your spare time. Checking for startupCompleted and keeping the version check only as a fallback sounds like the right way to me.

Once your change is on main, I'll gladly have a look at it and also test it on my own setup. My plan: install the main branch version, temporarily disable the reload automation I set up as a workaround, then restart the evcc add-on a few times while HA is running and check that the battery sensors come up on their own. I'll enable debug logging for the integration during the test, so I can send you the relevant log lines if something doesn't look right.

I'll report back here with the results.

Thanks again,
Dennis

[marq24]

changes are in main now

[essendyx]

Hi marq24,

thanks! I just checked, but I think the push didn't make it to GitHub yet: main is still at d5b68ca from Sep 25 on my end. Could you have a quick look?

As soon as it's there, I'll test it and report back.

Dennis

[marq24]

sorry my bad - "now" the push is there

da026d9

[essendyx]

Hi marq24,

I installed da026d9 on my system and tested it. Works for me, thanks!

What I did: restarted the evcc add-on while HA was running and reloaded the integration at the exact moment evcc was answering again but didn't have all data yet. Result: the battery sensors came up right away, pv and grid as well.

One thing I noticed in the debug log that might be interesting for you: at that moment evcc already reported startupCompleted: true, but the battery object was still missing:

is_evcc_available(): 'http://localhost:7070' is AVAILABLE - evcc startupStatus: True
read_evcc_config_on_startup(): ... 'battery': None ...
read_evcc_config_on_startup(): ... GridAsObject: True, BatteryAsObject: True

So in my case it was the version fallback (0.301.0) that did the trick. Looking at evcc's cmd/root.go, startupCompleted is set to true right after the devices are created, but before the site loop has published its first values. So keeping the version check as a fallback was definitely the right call.

Thanks again for the quick fix!
Dennis :))

[marq24]

Mhhhh... when evcc report, that starup is completed... but at the end of the day there are still components that report no data... then IMHO its worth to let the evcc guys know, that the info the status is reporting might not be 100% correct.

[marq24]

I hope it's fine for you, when I close this one?