Support for Wallbox chargers over OCPP

[stamateviorel]

Hi @splatch and @PRosenb,

Following up on https://community.openhab.org/t/charging-openhab-with-ocpp/135114, I've been running an eu.chargetime.ocpp:ocpp16j:2.0-based OCPP central system against two Wallbox chargers in production and would like to contribute back. This is a single tracking issue for what I found; I'd open the individual PRs against master after we agree on scope and cadence.

Environment

• Two Wallbox chargers, both firmware 6.7.38:
  • Wallbox Copper SB (CPB1-S-2-4, socketed Type 2)
  • Wallbox Pulsar Plus (PLP1-0-2-4)
• OCPP 1.6-J central system bound to 0.0.0.0:8887
• Both chargers also reachable over wallbox-mqtt-bridge for ground-truth comparison
• openHAB 5.x on Debian, Java 21

All findings below are empirically reproduced on those units. Happy to share full session captures (frames + logs) if useful.

Findings

1. WebSocket 1006 idle reconnect cycle — PING_INTERVAL mismatch

Out of the box the chargers cycled the WebSocket with close code 1006 (remote=true) every 30–45 s. Root cause is in OcppServer.java:

this.server = new JSONServer(new ServerCoreProfile(handler));

The single-arg JSONServer constructor uses JSONConfiguration.get() defaults, which set PING_INTERVAL_PARAMETER = 60. That's passed straight through to Java-WebSocket's setConnectionLostTimeout(60). Wallbox's internal idle timeout fires before our PING does. Setting PING_INTERVAL_PARAMETER = 20 and passing a JSONConfiguration to the 2-arg constructor makes the connection stay up for hours / indefinitely.

2. Wallbox drops the socket if it receives an outbound CALL before its BootNotification is acknowledged

Pete's #122 ("register in newSession() since BootNotification isn't always sent") fixes the inbound side — registration happens early and outbound send() resolves to a UUID. But the binding still happily sends outbound CALLs immediately on newSession. Wallbox firmware specifically closes the socket if it receives any CALL before its boot handshake has completed for that session. See lbbrhzn/ocpp#1510 — confirmed on FW 6.7.38.

What works: gate outbound CALLs until either (a) handleBootNotificationRequest has fired this session, or (b) the session has been stable for N seconds with ≥1 StatusNotification (trust fallback for the case Wallbox reuses an existing boot state on reconnect).

3. OcppMeasurementMapping.get() returns null for Wallbox's measurand names

Wallbox firmware emits the phase inside the measurand string, with an empty phase field on SampledValue. Live GetConfiguration output from FW 6.7.38 (excerpt):

MeterValuesAlignedData = Energy.Active.Import.Register,Power.Active.Import,
  Current.Import.L1,Current.Import.L2,Current.Import.L3,
  Voltage.L1-N,Voltage.L2-N,Voltage.L3-N,
  Current.Offered,Power.Offered,Temperature

OcppMeasurementMapping.MAPPING.get("Current.Import.L1") returns null → silently dropped in ConnectorThingHandler.handleMeterValues(). Fix: strip a trailing .L1/.L2/.L3/.L1-N from the measurand before lookup, then route to per-phase channels.

4. Persisted hardware max current on Wallbox is the vendor key chargingALimitConn1, not OCPP-standard MaxCurrent

ConnectorThingHandler.handleCommand() sends ChangeConfiguration[MaxCurrent=N] for the currentLimit channel. Wallbox firmware silently ignores MaxCurrent. ChangeConfiguration[chargingALimitConn1=N] is Accepted and the value mirrors instantly on the Wallbox MQTT bridge's max_charging_current topic — same underlying register. Suggested: a hardwareMaxCurrentKey thing parameter (default MaxCurrent to keep current behavior; chargingALimitConn1 for the Wallbox vendor preset).

5. SmartCharging and RemoteTrigger feature profiles aren't registered on JSONServer

new JSONServer(new ServerCoreProfile(handler)) only enables Core. SetChargingProfile, ClearChargingProfile, TriggerMessage then throw UnsupportedFeatureException on server.send(...). Adding server.addFeatureProfile(new ServerSmartChargingProfile()) and ... new ServerRemoteTriggerProfile() unblocks:

• dynamic current limit via TxDefaultProfile (the only chargingProfilePurpose Wallbox firmware accepts)
• pause via SetChargingProfile(limit=0) and resume via SetChargingProfile(limit=N)
• TriggerMessage(MeterValues) as a watchdog for stale telemetry

6. ClockAlignedDataInterval = 0 by default → no MeterValues outside a transaction

Without auto-config, telemetry only flows during an active charge session. Sending ChangeConfiguration[ClockAlignedDataInterval=30] plus setting MeterValuesAlignedData to the same measurand list makes the charger emit per-phase voltage/temperature even when idle. Worth doing once per session, post-boot.

7. Outbound CompletableFuture from Server.send() is never completed when the socket dies

ChargeTimeEU/Java-OCA-OCPP#121. The PromiseRepository retains the future indefinitely; on socket close it is silently orphaned. Wrapping every server.send(sid, req).toCompletableFuture().orTimeout(15, SECONDS) surfaces the failure as a TimeoutException in the log instead of silence.

Proposed PRs

Small, focused, easy to review independently:

1. Configurable pingInterval on the server bridge (default 60 to match current behavior, can be lowered for Wallbox)
2. Register ServerSmartChargingProfile + ServerRemoteTriggerProfile on the JSONServer
3. MeterValues parser: strip phase suffix from measurand; route to per-phase channels
4. .orTimeout() wrapper on outbound CALLs (and surface timeouts cleanly in the log)
5. Boot-gate / trust-fallback for outbound CALLs (the big one — happy to discuss design first)
6. New channels: pause, cableConnected (derived from StatusNotification), reset (Soft/Hard)
7. hardwareMaxCurrentKey thing parameter + hardwareMaxCurrent channel (defaults to MaxCurrent for backwards compatibility)
8. Auto-config ClockAlignedDataInterval + MeterValuesAlignedData post-boot
9. One-shot GetConfiguration diagnostic dump on session-ready (log every key=value)
10. Optional: chargerVendor dropdown (generic/wallbox/...) that presets sensible defaults for several of the above

PRs 1, 2, 4, 9 are tiny and low-risk. PR 5 is the meatiest and worth a design discussion before code.

Questions

1. Do you have a preferred PR cadence — one tracking discussion thread + 10 small PRs, or batched into 2-3 larger ones?
2. Are you open to adding a chargerVendor preset dropdown (PR 10), or would you prefer to keep the binding strictly OCPP-spec-level with vendor presets as a separate downstream binding?
3. Anything in the above already covered by work-in-progress on your side that I should know about before opening PRs?

Thanks for the binding — it's the only OCPP option in the openHAB ecosystem and a solid foundation.

— Stamate Viorel (@stamateviorel)

---

Disclosure: this analysis and the proposed fixes were developed and tested over a production deployment with assistance from Anthropic's Claude (Claude Code). The findings are reproduced empirically; the Claude-assisted parts are the writeup and code drafts that follow.

[stamateviorel]

Just noticed PR #129 from @PRosenb after I posted this — significant overlap with what I proposed:

My PR	Covered by #129?
2. Register SmartCharging profile	Yes — ServerSmartChargingHandler is in the diff
5. Boot-gate (touches registration logic)	Partial — #129 modifies BootRegistrationAdapter
6. charging channel (RemoteStart/Stop)	Yes — added by #129
7. Charge-limit channel	Same goal, different mechanism. #129 adds chargeLimit via SetChargingProfile. Mine would add hardwareMaxCurrent via ChangeConfiguration[chargingALimitConn1] (Wallbox vendor key — persisted hardware cap, not session profile). The two are complementary, not duplicates.
10. Vendor preset dropdown	#129 ships device-specific code (OcularSolarEcoMode) directly. Confirms the project accepts vendor-specific additions; suggests a generic preset dropdown could be a clean way to host them long-term.

Independent of #129 and safe to start in parallel:

• PR 1 (pingInterval config)
• PR 3 (per-phase MeterValues — measurand-suffix parsing)
• PR 4 (.orTimeout() on outbound CALLs)
• PR 8 (ClockAlignedDataInterval + MeterValuesAlignedData auto-config)
• PR 9 (GetConfiguration diagnostic dump on session-ready)

Proposed: I narrow scope to those 5 PRs and start with PR 1 now. Once #129 lands, I'll revisit my PRs 5/6/7 against the new baseline. @PRosenb — any objection, or anything in this list that's already in your roadmap?

[stamateviorel]

Opened the first one — small + low risk to start: #132 (pingInterval). The other 4 independent PRs (3, 4, 8, 9) will follow.

[PRosenb]

Hi @stamateviorel,
Thank you for testing the binding and for the effort you've put into improving it, it's really appreciated!

There's an active discussion about this binding in the OpenHAB forum, where @splatch (the maintainer) mentioned he’ll merge my PR soon. Once that’s done, I recommend building against the 5.0.x branch instead of master, as it targets the newest openHAB version.

I also need proper 3-phase support and would be more than happy to test it. I have an Ocular IQ Home Solar charger on a 3-phase connection and can provide logs and feedback.
Let me know if you plan to work on the 3-phase part or if there’s anything I can help with.

[stamateviorel]

Thanks @PRosenb — great to have an active 3-phase tester. Quick notes back:

• Branch: already on 5.0.x for all three open PRs ([ocpp] Allow configuring WebSocket PING interval on the server bridge #132, [ocpp] Surface dangling-future failures via .orTimeout() #133, [ocpp] Add diagnostic GetConfiguration dump on BootNotification #134). Will rebase if anything in Add Remote Charging Control, Charge Limit Management, and EcoMode for Ocular to OCPP Binding #129 collides once it lands.

• 3-phase support: happy to start PR 3 now. Before I write the channel layout I'd like your input on one design question:

  Wallbox firmware emits per-phase measurands two ways depending on configuration: either Current.Import with a phase field of L1/L2/L3 (OCPP-canonical), or as Current.Import.L1 / Current.Import.L2 / Current.Import.L3 with no phase field (vendor-specific but common). The parser in OcppMeasurementMapping.get(...) currently returns null for the second form, so those samples are silently dropped today.

  For the channel surface, two options that fit ConnectorIO's existing pattern:

  1. Three explicit channels per measurand (currentImportL1, currentImportL2, currentImportL3) alongside the existing aggregate currentImport. Verbose but mirrors how the rest of openHAB does per-phase telemetry (cf. solax, modbus, mybmw bindings). Simple item → channel mapping.
  2. One channel per measurand with a phase config, the channel state dynamically routed based on the SampledValue. More compact but unusual for openHAB; downstream rules/widgets see one channel updating with different phase contexts.

  I'd go with option 1 unless you prefer otherwise. It's also what your Ocular 3-phase telemetry would land on after the parser change.

• Testing: I'll attach a MeterValues JSON sample from a real Wallbox in the PR body, plus the log-side output after parsing. Happy to add an OcppMeasurementMappingTest.java covering the suffix-stripping cases (matching the style of your ChargeLimitCommandHandlerTest).

OK to go ahead with option 1?

[PRosenb]

Thanks for the detail @stamateviorel. I like your option 1 with three explicit channels to align with the rest of openHAB and also to allow rules based on individual phases. I measure grid and other devices on separate phases already and it would fit best to do the same here.
As I remember does the Ocular charger send the phases with a phase field which currently leads to overwrite one phase after the other as the field is ignored.
Let's also involve @splatch before dedicating too much time to implement these changes.

[splatch]

Hey @stamateviorel!
Thanks for stepping in and contributing to this repository. At the same time please cut amount of text produced by Claude, preferably always write your own description of the problem in the issue. Personally I do not want to follow a complete reasoning of model in each and every place. For PRs - the "WHY" part should be already clear from "summary". "What changes" part can be omitted entirely, as it just summarizes diff. There is no point in repeating this.

From admin point of view - I moved master to OH 5.0.x, so there should be less overhead moving things around, as there are fewer users for earlier releases than this. I think binding should be still compatible with OH 5.1 and 5.2. Please update merge requests to aim master. I will try to work on a better config for backport bot.

Finally, lets keep this issue open until Wallbox chargers are supported. :-)