Titel: Fehlgeschlagene EEBus-Verbindung zu einem Ladepunkt (Wolf CHA, eebus-ohpcf-wolfvaillant) verhindert kompletten evcc-Start – alle anderen Ladepunkte damit ebenfalls down

[dsrhash]

Describe the bug

Setup: evcc läuft nativ (systemd, Armbian) auf Raspberry Pi, Config-UI/Datenbank (kein evcc.yaml). Zwei Ladepunkte: Wallbox (Carport 2) und Wärmepumpe (Wolf CHA 16 über Wolf Link, Template eebus-ohpcf-wolfvaillant, EEBus-Kopplung bestätigt aktiv im Wolf-Link-Interface).

Beobachtetes Verhalten:
Nach mehreren evcc-Neustarts (im Rahmen einer Diagnose, siehe unten) konnte evcc die EEBus-Verbindung zum Wolf Link nicht mehr aufbauen:

[eebus] ERROR connection to 43dbc05f... at wolflink.local failed: dial tcp: lookup wolflink.local on 192.168.178.1:53: no such host
[eebus] ERROR connection to 43dbc05f... at 192.168.178.43 failed: read tcp 192.168.178.21:xxxxx->192.168.178.43:4711: read: connection reset by peer

Dieser Fehler wiederholte sich ca. 2,5 Minuten lang (alle ~15s), danach:

[main] FATAL charger [db:20] cannot create template 'db:20': cannot create charger type 'template:eebus-ohpcf': cannot create charger type 'eebus-ohpcf': timeout
loadpoint [db:21] missing charger instance
[main] FATAL will attempt restart in: 15m0s

Problem 1 (Kernproblem): Der Fehlschlag bei einem einzelnen (optionalen Heizungs-)Ladepunkt bringt den gesamten evcc-Dienst zum Absturz und blockiert ihn für 15 Minuten – inklusive aller anderen, funktionierenden Ladepunkte (in meinem Fall die Wallbox/Carport 2). Das erscheint unverhältnismäßig: Ein einzelner nicht erreichbarer Ladepunkt sollte m. E. nicht den kompletten Dienst (und damit die Steuerung aller anderen Ladepunkte) lahmlegen.

Problem 2 (separat, evtl. zusammenhängend): Auch als die EEBus-Kopplung laut Wolf-Link-Interface als "Verbunden" gemeldet wurde und der Ladepunkt lief, blieb die Wärmepumpe in evccs Session-Statistik dauerhaft ungelistet (Gruppierung "Ladepunkt" zeigte nur die Wallbox), obwohl der zugehörige Leistungssensor (charge_power, exportiert über ha-evcc) im Home-Assistant-Verlauf nachweislich reale Werte zeigte (z. B. 3,7-3,8 kW während des Kompressorbetriebs). Der Ladepunkt wurde im evcc-Webinterface durchgehend als "Nicht verbunden" angezeigt, und im systemd-Journal erschien wiederholt:

[lp-2] ERROR dimmed: not available

Frage an die Maintainer: Ist (a) das Fail-Fast-Verhalten bei nicht erreichbaren Ladepunkten beim Start beabsichtigt, und (b) hängt das "dimmed: not available" / fehlende Session-Tracking mit dem hier beobachteten Verbindungsproblem zusammen?

Nachtrag: Nach einem Stromreset des Wolf Link Moduls und Neuanlage des Ladepunkts in evcc verbindet sich die Wärmepumpe seit ca. [Uhrzeit] wieder stabil über EEBus (Status "verbunden" im Webinterface, keine Fehler mehr im Journal seit über 10 Minuten). Das bestätigt aber gerade das Kernproblem: Ein vorübergehender Netzwerk-/Geräte-Hänger auf Seiten des EEBus-Partners reicht aus, um den kompletten evcc-Dienst zum Absturz zu bringen (inkl. anderer, unabhängiger Ladepunkte) — ein einfacher Geräte-Reset behebt es zwar, ist aber im Alltag unpraktikabel, falls das öfter vorkommt
evcc-Version: V0.311.1
ha-evcc-Version: 2026.7.2

Steps to reproduce

1. Wärmepumpe (Wolf CHA 16 mit Wolf Link Modul) als Ladepunkt in evcc einrichten, Ladepunkt-Typ "EEBUS Wärmepumpe (OHPCF)" (eebus-ohpcf-wolfvaillant), SKI und IP-Adresse hinterlegen
2. Im Wolf-Link-Webinterface unter "EEBus" bestätigen, dass "EVCC HEMS" mit Status "Verbunden" gelistet ist
3. Warten, bis die Wärmepumpe einen normalen Heizzyklus durchläuft (Kompressor aktiv, z. B. sichtbar an "Compressor status: Betrieb" bzw. "Compressor frequency" > 0 Hz in der nativen Wolf-Integration)
4. Während dieses Zyklus im evcc-Webinterface den Ladepunkt "Wärmepumpe" ansehen → Status bleibt "Nicht verbunden", Leistung zeigt 0,0 kW
5. Parallel in Home Assistant den Sensor sensor.evcc_warmepumpe_charge_power im Verlauf prüfen → zeigt korrekt echte Leistungswerte (z. B. 3,7–3,8 kW) während desselben Zeitraums
6. In der evcc-Statistik/Session-Übersicht (bzw. in der "EVCC Custom Card" für Home Assistant, Modus "Statistik", Gruppierung "Ladepunkt") nach abgeschlossenem Zyklus nachsehen → die Wärmepumpe erscheint dort nicht als Ladepunkt, obwohl der zweite konfigurierte Ladepunkt (Wallbox) korrekt gelistet wird

Erwartetes Verhalten: Ladepunkt zeigt während des Betriebs "Verbunden"/aktive Leistung, und der abgeschlossene Zyklus erscheint als Session in der Statistik (analog zu anderen Ladepunkten).

Tatsächliches Verhalten: Ladepunkt bleibt dauerhaft "Nicht verbunden", trotz real messbarer Leistung über denselben EEBus-Kanal; keine Session wird für die Statistik

Configuration details

main  ] INFO 2026/07/24 20:38:57 using sqlite database: /var/lib/evcc/evcc.db?_pragma=busy_timeout(5000)&_pragma=foreign_keys(1)&_pragma=auto_vacuum(INCREMENTAL)
charger
---
db:8 {Type:template Title: Icon: Product:go-e Charger Gemini} map[host:192.168.178.38 template:go-e-v3]
db:15 {Type:template Title: Icon: Product:EEBUS Wärmepumpe (OHPCF)} map[ip:192.168.178.43 reboost:10m ski:***** template:eebus-ohpcf]
db:16 {Type:template Title: Icon: Product:EEBUS Wärmepumpe (OHPCF)} map[ip:192.168.178.43 reboost:10m ski:***** template:eebus-ohpcf]
db:17 {Type:template Title: Icon: Product:EEBUS Wärmepumpe (OHPCF)} map[ip:192.168.178.43 reboost:10m ski:***** template:eebus-ohpcf]
db:18 {Type:template Title: Icon: Product:EEBUS Wärmepumpe (OHPCF)} map[ip:192.168.178.43 reboost:10m ski:***** template:eebus-ohpcf]
db:19 {Type:template Title: Icon: Product:EEBUS Wärmepumpe (OHPCF)} map[ip:192.168.178.43 reboost:10m ski:***** template:eebus-ohpcf]
db:22 {Type:template Title: Icon: Product:Wolf CHA-Monoblock (07, 10, 16/20, 20/24 with EEBus)} map[ip:192.168.178.43 reboost:10m ski:***** template:eebus-ohpcf-wolfvaillant]

meter
---
db:4 {Type:template Title: Icon: Product:Huawei SUN2000 Hybrid-Wechselrichter} map[baudrate:9600 comset:8N1 forceaccharging:false host:192.168.178.41 id:1 maxacpower:0 modbus:tcpip port:502 storageunit:1 template:huawei-sun2000-hybrid timeout:15s usage:grid]
db:5 {Type:template Title:Sun2000 Icon: Product:Huawei SUN2000 Hybrid-Wechselrichter} map[baudrate:9600 comset:8N1 forceaccharging:false host:192.168.178.41 id:1 maxacpower:0 modbus:tcpip port:502 storageunit:1 template:huawei-sun2000-hybrid timeout:15s usage:pv]
db:11 {Type:template Title:Luna 2000 Icon: Product:Huawei SUN2000 Hybrid-Wechselrichter} map[baudrate:9600 capacity: comset:8N1 forceaccharging:false host:192.168.178.41 id:1 maxacpower:0 maxchargepower:5000 maxdischargepower:5000 maxsoc:95 minsoc:10 modbus:tcpip port:502 storageunit:1 template:huawei-sun2000-hybrid timeout:15s usage:battery]

vehicle
---
db:3 {Type:template Title: Icon: Product:Tesla} map[accessToken:***** cache:15m capacity:82 clientId:3371b3a5-a38f-4027-b64c-4ce5ed98009f commandProxy:https://api.myteslamate.com icon:car maxCurrent:16 minCurrent:6 mode:pv phases:3 priority:0 refreshToken:***** template:tesla title:Tesla 3]

loadpoint
---
db:7 {Type: Title: Icon: Product:} map[charger:db:8 circuit: defaultMode:minpv limitSoc:0 meter: mode:minpv phasesConfigured:3 planStrategy:map[continuous:false precondition:0] soc:map[estimate:true poll:map[interval:6e+10 mode:connected]] thresholds:map[disable:map[delay:1.8e+11 threshold:0] enable:map[delay:6e+10 threshold:0]] title:Carport 2 ui:map[maxTemp:0 minTemp:0] vehicle:]
db:23 {Type: Title: Icon: Product:} map[charger:db:22 circuit: meter: phasesConfigured:3 planStrategy:map[continuous:false precondition:0] soc:map[estimate:true poll:map[interval:3.6e+12 mode:charging]] thresholds:map[disable:map[delay:1.8e+11 threshold:0] enable:map[delay:6e+10 threshold:0]] title:Wärmepumpe ui:map[maxTemp:100 minTemp:0] vehicle:]

Log details

Jul 24 20:00:11 evcc evcc[19430]: [main  ] INFO evcc 0.311.1
Jul 24 20:00:11 evcc evcc[19430]: [main  ] INFO config file not found, database-only mode
Jul 24 20:00:11 evcc evcc[19430]: [eebus ] INFO Local SKI: 3689f35b300c56026ffe09082f435dab0d6ef080
Jul 24 20:00:13 evcc evcc[19430]: [eebus ] ERROR connection to 43dbc05f866a9743de87becc7716cee899d38b0d at wolflink.local failed: dial tcp: lookup wolflink.local on 192.168.178.1:53: no such host
Jul 24 20:00:13 evcc evcc[19430]: [eebus ] ERROR connection to 43dbc05f866a9743de87becc7716cee899d38b0d at 192.168.178.43 failed: read tcp 192.168.178.21:38624->192.168.178.43:4711: read: connection reset by peer
... (wiederholt sich alle ~15-20s für ca. 2,5 Minuten) ...
Jul 24 20:02:47 evcc evcc[19490]: [main  ] FATAL charger [db:20] cannot create template 'db:20': cannot create charger type 'template:eebus-ohpcf': cannot create charger type 'eebus-ohpcf': timeout
Jul 24 20:02:47 evcc evcc[19490]: loadpoint [db:21] missing charger instance
Jul 24 20:02:47 evcc evcc[19490]: [main  ] FATAL will attempt restart in: 15m0s

What type of operating system or environment does evcc run on?

Linux

External automation

• I have made sure that no external automation like HomeAssistant or Node-RED is active or accessing any of the mentioned devices when this issue occurs.

Nightly build

• I have verified that the issue is reproducible with the latest nightly build

Version

No response

[StefanSchoof]

See #14496

[github-actions]

Thanks for the detailed report and logs. I traced both problems in the code:

Problem 2 (session tracking / "Nicht verbunden"): confirmed root cause. charger/eebus-ohpcf.go's Dimmed() (used by both eebus-ohpcf and eebus-ohpcf-wolfvaillant) returns api.ErrNotAvailable whenever the §14a/LPC scenario isn't announced by the EEBus partner — this is the normal, expected case for a heat pump that isn't actively limited. However core/loadpoint.go's Update() treated any error from Dimmed() as fatal for the whole update cycle and returned immediately, before ever reaching charger-status/connected/session-tracking logic. That means every single update cycle bailed out early for your heat pump, which is exactly why the loadpoint stayed "Nicht verbunden" and no session was ever recorded, even though real power was flowing over EEBus. I opened a fix: #32126.

Problem 1 (single charger blocking all loadpoints for 15 min): also confirmed in the code — cmd/setup.go's configureChargers/configureDevices fails the whole startup if any single charger (including an unrelated, optional one) can't be instantiated in time, and cmd/root.go then treats that as fatal for the entire process with a 15-minute restart delay, blocking working loadpoints too. This is current, intentional-looking fail-fast startup behavior rather than a clear code defect, and changing it (e.g. isolating failures per loadpoint/charger) is a bigger design decision that needs maintainer input, so I did not attempt a fix for it here.

Given problem 2 is a confirmed code defect with a clear, low-risk fix, and problem 1 is more of a startup-design question, I'm labeling this bug.

🤖 Generated with Claude Code

[dsrhash]

Danke fürs schnelle Fixen! Das erklärt genau das Verhalten, das ich beobachtet hatte (dauerhaft "nicht verbunden" trotz echter Leistungsmessung). Freue mich auf den Release.

[andig]

Ich denke es gibt zwei Punkte hier: ErrNotAvailable is the general "this function is not available at this time".

• If an (expected) dimming becomes unavailable: should it be ignored? This "temporarily unavailable" in the PR is in line with other uses of this error code.
• From the current code its unclear to me why this error should happen at all. Issue is missing version. We need to understand if failsafe value wouldn't be the correct fallback here instead of ignoring the error.

Ein vorübergehender Netzwerk-/Geräte-Hänger auf Seiten des EEBus-Partners reicht aus, um den kompletten evcc-Dienst zum Absturz zu bringen (inkl. anderer, unabhängiger Ladepunkte) — ein einfacher Geräte-Reset behebt es zwar, ist aber im Alltag unpraktikabel, falls das öfter vorkommt

Das klingt sehr dramatisch. Was für ein Absturz?! Gibts dazu ein trace log?

Anyway, das braucht ein Logfile mit aktueller Version bevor hier etwas zu ändern wäre.

[andig]

See #32132 for general discussion.

[andig]

Closing this one in favor of the general issue. Specific EEBus error condition has been resolved.