Add Webasto NEXT OCPP compatibility

[terrorobe]

Summary

A few independent changes were necessary to make Webasto/Ampure NEXT chargers work over OCPP with evcc. This adds a server-wide OCPP timestamp granularity setting, fixes BootNotification handling on websocket reconnects, and adds a dedicated Webasto/Ampure NEXT template documenting the required setup.

OCPP timestamp granularity

The Webasto NEXT fails immediately after BootNotificationResponse.currentTime is accepted if the timestamp does not include a fractional-second component. Its vendor-specific pyocppd clock synchronization parses backend timestamps with a mandatory .%f, so evcc's default whole-second output makes it raise a ValueError and drop the connection.

This adds an ocpp.dateTimeGranularity server setting controlling how evcc serializes OCPP dateTime values. The default seconds preserves the current output; milliseconds emits a fixed fractional-second component. The setting is server-wide because ocpp-go exposes dateTime serialization through a package-global formatter.

BootNotification on reconnect

evcc waits for a BootNotification before treating a websocket session as ready, and proactively triggers one if the charger stays silent. Previously this trigger was skipped whenever BootNotification metadata from an earlier session was already cached. The NEXT may not re-send BootNotification on a new websocket once it considers itself accepted by the backend, leaving the session stuck until the timeout fallback.

This refines the proactive BootNotification trigger added in #28540. That change fixed chargers that stay silent on initial connect, where no BootNotification metadata is cached yet. Its cached-metadata guard avoids duplicate triggers, but it also suppresses the trigger on later reconnects where the cached metadata is from a previous websocket connection rather than the current one.

BootNotification readiness is now tracked per websocket connection instead of using cached metadata as a proxy. evcc may trigger BootNotification for the current session even when metadata from a previous session exists. BootNotifications requested this way are treated as websocket-connection handshakes and are not forwarded to the reboot monitor, so they no longer cause unnecessary setup reinitialization.

Webasto/Ampure NEXT template

A new ocpp-webasto-next charger template documents the required setup: disable Modbus/HEMS on the charger (active Modbus/HEMS surfaces as OCPP errors CB26/CB27), point the charger at evcc's OCPP backend URL, and set ocpp.dateTimeGranularity: milliseconds.

[sourcery-ai]

Hey - I've found 2 security issues

Security issues:

• Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections. (link)
• Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections. (link)

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="templates/definition/charger/ocpp-webasto-next.yaml" line_range="23" />
<code_context>
      * Backend-URL (Central System) in der Wallbox: `ws://<evcc-host>:8887/`
</code_context>
<issue_to_address>
**security (javascript.lang.security.detect-insecure-websocket):** Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections.

*Source: opengrep*
</issue_to_address>

### Comment 2
<location path="templates/definition/charger/ocpp-webasto-next.yaml" line_range="35" />
<code_context>
      * Backend URL (Central System) in the charger: `ws://<evcc-host>:8887/`
</code_context>
<issue_to_address>
**security (javascript.lang.security.detect-insecure-websocket):** Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections.

*Source: opengrep*
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[terrorobe]

Some background on why this was needed, since the PR itself only covers the evcc-side changes.

Tested against a Webasto/Ampure NEXT on firmware 3.1.16.

The NEXT queues OCPP transaction and MeterValues messages locally whenever it has no working OCPP backend. The queue is bounded by MaximumQueueLimit (default 10000); once it fills, the charger starts discarding entries and can refuse to start new charging sessions. Without a working backend, this backlog builds up silently until charging simply stops working.

Typical symptoms in the Webasto logs:

pyocppd[...]: ocppd[WARNING] TransactionQueueFullError
pyocppd[...]: ocppd[WARNING] QueueFull discard: ('MeterValues', ...)

And in the charger status / error mapping (web UI or /api/sections/system):

CB03   OCPP backend unavailable
CB25   transaction queue is full

A telltale sign is that discarded payload timestamps are weeks or months old while the errors are current (e.g. March/April discards showing up in June). In our case this state was persistent and only fully cleared by reflashing the wallbox, not by reboots or reconnects.

Giving the NEXT a stable evcc OCPP backend (with the compatibility changes in this PR) lets it finally drain and acknowledge that queue instead of accumulating it.

[terrorobe]

@premultiply Any changes you'd be interested in for this PR?

Being able to modify the timestamp granularity is the hard blocker for this specific wallbox and is low complexity. Since the model is EoL/EoS upstream I don't expect any improvements on that front unless someone leaks the models image signing key 🙃

The changes to the bootnotification handling are mostly helpful when iterating on wallbox configurations for models that don't send a gratuitous bootnotification on connect but is not a dealbreaker; the current implementation just added extra confusion/convergence time whenever an already configured wallbox reconnects. But this can be easily spun out in a separate PR or be dropped altogether.