Fix evcc disappearing from the device list - #21
Conversation
|
Aren't volumes docker compose rather than docker? I don't know for sure. Not convinced by this change it seems to be targeting a sympton. If mDNS wasn't working we shouldn't see any announcement rather than "sometimes"? |
|
Volumes are Docker in general, either passed via CLI ( |
|
Looks like there are quite some open issues related to mDNS in ship-go, see here. |
|
Still experiencing the problem that evcc gets lost in the controlbox dropdown. It now seems to happen when restarting evcc (not sure whether this happens always or is a race-condition). Here is the controlbox log from the evcc restart: controlbox and evcc reconnect but evcc does not seem to appear in the mDNS results anymore. Restarting controlbox fixes it. |
|
The log actually rules out the Docker/avahi theory. The SHIP link is alive the whole time (heartbeats from Sequence is: evcc restarts → goodbye → Where that happens in ship-go:
Which provider controlbox uses decides the root cause:
Could you check, while it's broken, on the controlbox host: If evcc is listed there, avahi is fine and ship-go dropped it — that pins it on the avahi resolve path and it's an enbility/ship-go issue. If evcc is absent, it's the announcing side after all. Also useful: which provider controlbox picked at startup (avahi, or the zeroconf fallback). On the PR itself: I'd keep the change regardless. A device with a live connection should never disappear from the list — that's a UI invariant, not a workaround. But the real fix belongs upstream: ship-go should retry a failed resolve, and/or the hub should union the mDNS entries with the connected SKIs so no consumer can see this symptom (evcc's own device list has the same exposure). Unrelated, but visible in your log: the heat pump's certificate expired 608 days ago, and its disconnect/reconnect churn is a separate problem. 🤖 Generated with Claude Code |
|
Does not seem to happen always, like in: Can't reproduce right now. |
|
I probably fixed the bad situation when I previously restarted controlbox. So the stack probably needs to go in the bad state first... Does it make sense to update eebus-go in controlbox? |
|
Small addition... I am quite sure that controlbox uses avahi. At least it is installed on the Raspberry on which controlbox runs. I can execute |
|
Again in that state after restarting evcc: Only Vaillant heat pump is reported by controlbox. Output of Only restarting controlbox fixes it. |
|
Thanks, that What the output provesevcc is in avahi, fully resolved: Two things die here: the Docker/avahi-socket theory, and the "missing mandatory TXT element" branch I raised last time. ship-go dropped the entry, not the network. What I verified in ship-go v0.6.0 (the version this repo pins)The list is a verbatim projection of the mDNS map. Every failure branch in the avahi provider is terminal. Two tempting theories I had to discard after reading the code:
A version bump won't help. ship-go HEAD has byte-identical resolve-error handling. The blocker is in controlboxThree candidates remain, all terminal, all logged at Debug:
Could you uncomment those four bodies, reproduce, and look for On the PRI'd merge it. A device with a live connection disappearing from a discovery list is an invariant violation, not a cosmetic workaround — and per One note on the diff, not a blocker: it reads 🤖 Generated with Claude Code |
|
I actived the logs now. Did a restart of evcc yesterday after building and starting the changed controlbox. It worked. Did the same some minutes ago (at 05:41) and evcc disappeared from the dropdown. Attaching the link to the log. Had to put it on my GDrive due to its size... [LOG] |
|
Problem seems to start at: Claude believes that the problem is already fixed in latest master of ship-go as the mDNS architecture has substantially been rewritten. |
|
See #22. It doesn't seem to upgrade avahi or zeroconf though. |
|
Thanks for the log — it settles this completely, and it also corrects one of my own conclusions from the last round. What the log provescontrolbox exhausts avahi's per-client D-Bus object budget: 1024 is avahi-daemon's default The leak, in ship-go v0.6.0 (what this repo pins)
entryGroup, err := a.avServer.EntryGroupNew()
...
a.avEntryGroup = entryGroup // previous group overwritten, never EntryGroupFree'd
The amplifier is the heat pump. Why evcc specifically disappearsOnce the budget is gone, The remove is processed, both re-adds fail to resolve, and — as established last time — a failed resolve is terminal, so the entry is gone until the D-Bus client is recreated by a controlbox restart. Compare the same restart earlier the same evening, before exhaustion, at 19:17:04: Clean remove/re-add. That is exactly your "it worked yesterday, it failed this morning" — the difference is only whether the object budget was still available. Correcting myselfMy "a version bump won't help" was about the resolve-error handling, and in that narrow sense it holds. But the root cause is the announce leak, and that is fixed upstream: ship-go commit // no need to announce if it is already, can happen when call via hub
if m.isServiceAnnounced() {
return nil
}plus per-instance entry groups with proper What to do
🤖 Generated with Claude Code |
|
Restarting evcc made controlbox fail differently this time: No extended logging for controlbox unfortunately. Attaching the trace log of evcc. Refused to connect to controlbox (SKI: |
|
Restart worked this morning. So the original problem with evcc disappearing from the mDNS record seems fixed. There is still an occacional problem that evcc denies trust on a restart. See previous posting. |
|
I in fact executed a |
2 participants
Short Description
evcc keeps disappearing from the dropdown list of found devices even though the connection is still alive and exchanging heartbeats.
Analysis
The data structure feeding the dropdown is driven purely by mDNS discovery visibility. So for some reason, evcc seems to disappear from the mDNS record.
Workaround
Keep connected devices in the list like proposed in this PR. The dropdown list should never drop a device that's actively connected, regardless of what the latest mDNS record says.
Potential Docker Fix
Claude believes that the root cause is the incomplete pure-Go Zeroconf implementation used by eebus-go as avahi is not made available to the evcc Docker container. So I also applied the following fix to my
docker-compose.ymlto potentially stabilize mDNS:Maybe we should also add the
avahi/dbusvolumes to the default evcc EEBus Docker config? Requires avahi to be installed on the host.Ping @andig