Skip to content

Daheimladen: fix hardware check - #32079

Merged
andig merged 4 commits into
masterfrom
fix/dl
Jul 23, 2026
Merged

Daheimladen: fix hardware check#32079
andig merged 4 commits into
masterfrom
fix/dl

Conversation

@premultiply

@premultiply premultiply commented Jul 23, 2026

Copy link
Copy Markdown
Member

@premultiply premultiply added the devices Specific device support label Jul 23, 2026
@github-actions github-actions Bot added the bug Something isn't working label Jul 23, 2026
sourcery-ai[bot]

This comment was marked as resolved.

This comment was marked as resolved.

@andig

andig commented Jul 23, 2026

Copy link
Copy Markdown
Member

Has been fixed on master already.

# Conflicts:
#	charger/daheimladen.go
@premultiply

Copy link
Copy Markdown
Member Author

This fixes the master.

@andig
andig merged commit f7af0bb into master Jul 23, 2026
10 checks passed
@andig
andig deleted the fix/dl branch July 23, 2026 11:19
VolkerK62 added a commit to VolkerK62/evcc that referenced this pull request Aug 19, 2026
fix evcc-io#32907 

## Daheimladen: fix misleading sponsorship error on station id communication failure

### Problem

`checkStation()` calls `wb.conn.ReadHoldingRegisters(...)` to read the
station id and decide whether the connected DaheimLaden model requires a
sponsor token. Any error from this read - including plain network/Modbus
communication failures such as `connection refused`, `i/o timeout`, or
`EOF` when the wallbox is temporarily unreachable at evcc startup - was
unconditionally mapped to `api.ErrSponsorRequired`.

This produces a misleading `sponsorship required` error whenever the
wallbox simply isn't reachable yet (e.g. still booting, brief network
hiccup), even though all DaheimLaden models are sponsor-free. Users have
reported that once this happens, restarting evcc does not resolve it -
only an external Modbus request to the wallbox (from another tool)
appears to reset the connection into a state where evcc's own check
succeeds again.

Related history: evcc-io#31956 attempted a fix for this, but was reverted
(834c062). evcc-io#32079 addressed a related hardware-check issue. The
underlying error-masking in `checkStation()` itself was not changed by
either.

### Fix

Distinguish between:
- a **communication error** while reading the station id block (timeout,
  connection refused, EOF, decode error) -> now returned as a wrapped
  `station id: %w` error, exposing the real cause instead of
  `sponsorship required`
- a **successfully read but empty/invalid/blocked station id** -> still
  correctly returns `api.ErrSponsorRequired`, unchanged behavior

No other logic changes. The sponsorship determination for genuinely
unsupported/rebranded hardware (empty id, non-printable characters,
"heidelbridge" marker) is untouched.

### Testing

- [ ] Verified that a wallbox unreachable at startup now surfaces
      `cannot create charger ...: station id: dial tcp ...: connect:
      connection refused` instead of `sponsorship required`
- [ ] Verified that a reachable wallbox still initializes without a
      sponsor token (as all DaheimLaden models are sponsor-free)

### Note

⚠️ This does not necessarily fix the reported "stuck until an external
Modbus request is sent" behavior, which may be caused by a separate
issue in connection handling further down in `util/modbus`
(`TcpSettings.Connection(ctx)`). This PR only fixes the error message
being wrong/misleading.


Created with the help of Claude AI
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working devices Specific device support

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Please stop disguising

3 participants