Error on adding Vaillant aroTHERM plus OHPCF

[CiNcH83]

Describe the bug

When adding the Vaillant aroTHERM plus as OHPCF device, a bad status is shown on verification:

After pressing "Save anyway", the config tile immediately shows a proper status:

After a restart, also the loadpoint is displayed on the main page.

evcc.log

[andig]

Tentatively closing as solved.

[CiNcH83]

Problem still exists, also see here.

evcc-20260728-140008-trace.log

"Save anyway" and restarting evcc brings the OHPCF loadpoint/charger to life.

[andig]

I can see what's happening: we're "connected" when SHIP connection is up, not necessarily when SPINE handshake has completed, much less when entities are setup and actual data has been received. Instead of trying to wait for any data on any entity, I'd just add a 100ms load now which may work or not.

[andig]

Timings from the trace log, for the record.

The device test (POST /api/config/test/charger) only waits for the SHIP connection and then probes values immediately, but the SPINE data arrives ~1 s later. In the failing window not a single Data* event had been received yet, so Status() reported not connected and power/temperature stayed empty. Pressing "Save anyway" keeps the device registered long enough for the data to land.

13:59:47  POST /api/config/test/charger → registering ski
13:59:47  delaying connection to 4bb4dd… by 2.686s
13:59:49  SHIP handshake → ski 4bb4dd… connected
13:59:50  ma-mpc / cem-ohpcf / eg-lpc / ma-mdt UseCaseSupportUpdate
13:59:50  ski 4bb4dd… disconnected      ← test handler returned, ctx cancel → UnregisterDevice
13:59:51  POST /api/config/devices/charger ("Save anyway")
13:59:52  ski 4bb4dd… connected
13:59:53  cem-ohpcf-DataUpdateConsumptionState, eg-lpc-DataUpdateLimit,
          ma-mpc-DataUpdatePower, ma-mdt-DataUpdateTemperature
13:59:54  loadpoint "aroTHERM plus" created

The log has 1 s resolution, so the numbers below are bracketed from the connect-delay arithmetic (evcc logs the delay it computed, and the dial has to land in the second where trying to connect appears), not measured directly:

Phase	Elapsed
dial → SHIP connected	~0.1–0.3 s
connected → first UseCaseSupportUpdate	~0.1–0.5 s
connected → first Data* payload	~0.3–1.0 s
connected → all use case data in (ohpcf state, lpc limit + failsafe, mpc power, mdt temperature)	~1.0–1.5 s

Traffic in that window: 68 SPINE messages — 28 read/reply pairs, 17 call/result pairs, 2 notify.

Not causal, but visible in the log: the certificate for the SKI is reported as expired (592 days), and the mDNS hostname vr921-….local does not resolve — the connection succeeds via the IP fallback in both cases.

Both samples come from one installation on a quiet LAN, so treat these as a floor rather than a distribution.

🤖 Generated with Claude Code

[andig]

Instead of waiting 1.5s for the device we should accept this as unfortunate:(