Build of the openhab-addons distribution branch — commit d27058b8ac (the review-PR head plus follow-up features not yet in the PR), built against openHAB 5.3.0-SNAPSHOT, runs on 5.2.x.
The lean review PR stays focused for merge; this download folds in the extra features below so testers can run them now.
openHAB acts as an OCPP 1.6-J central system: chargers connect over WebSocket, no vendor cloud in between.
Three-tier model: server → chargepoint → connector.
It reads connection state, connector status, the MeterValues measurand set and transactions, and controls charging — current limit and pause via SetChargingProfile, remote start/stop, availability, unlock and reset.
Under review at openhab/openhab-addons#21265.
The maintainer's latest re-review found no remaining blocking issues and considers the binding functionally sound; it is waiting on a human maintainer's manual pass before merge.
Changed since the previous (round-5) asset: every outbound request for a session is serialized to one CALL at a time and stays correct across a reconnect — the request in flight is abandoned on the session change rather than stalling the new session; transactions are persisted the moment they are accepted and cleared symmetrically, even before the Thing exists; the post-boot status refresh is held behind the BootNotification response; MeterValues polling is coalesced and the outbound queue is bounded; plus a batch of documentation and review-checklist fixes. And a BootNotification whose model or vendor exceeds the OCPP 20-character limit (or omits one) is now accepted rather than rejected, so such a charger can come online instead of being refused — reported with an Alfen Eve Single Pro. Two more field fixes since: a paused connector now resumes by clearing its charging profile instead of re-sending 0 A — an un-pause with no current limit set otherwise left the charger stuck at SuspendedEVSE (Alfen Eve Single Pro + BMW i4); and a charger that connects with no charge point id in its URL path is now logged with a warning naming the connection and the URL it must dial, instead of being ignored silently (V2C Trydan).
Latest batch: the embedded ChargeTime OCPP library is bumped to its current release (still OCPP 1.6-J — the 2.0 is the library version, artifact ocpp16; Java-WebSocket to 1.6.0). On the back of that, two additions. A charger that always sends an HTTP Basic-auth header with a password outside the OCPP 16–20 character rule — a V2C Trydan sends a one-character password on every connection — is now accepted when no authPassword is configured, instead of being rejected by the library during the handshake before the binding sees it. And the server endpoint can now run over TLS: set tlsKeystorePath (a PKCS12 keystore with the server's cert and key) and tlsKeystorePassword, and chargers dial wss:// — OCPP security profile 2 with an authPassword, an encrypted profile 0 without. 109 unit tests.
Newest additions (not yet in the review PR, folded into this download): every connector of a multi-connector charger is asked to announce itself on boot, so all connectors surface in the inbox without waiting for each to change state; the charge limit can also be given in watts (power-limit) and charging phases requested (number-phases, 1/2/3) on a charger that supports switching; the control channels now reflect the charger's confirmed state instead of an optimistic command echo, so a rejected limit/pause/phase shows what the charger actually did; and offline RFID authorization — a charger that supports LocalAuthListManagement keeps a local card list that still starts a charge while openHAB is offline. The list is managed entirely in openHAB: it lives on the local-auth-list channel (persisted on the thing, pushed via SendLocalList), and a learn-card switch adds a card by reading its idTag from the charger's Authorize when you present it — no id to look up. Upgrading in place migrates an existing charge point Thing to the new channels automatically (no recreate needed). 145 unit tests.
The whole RFID path is now hardware-validated on a first-generation CHARGESTORM Connected: learn a card, start on tap, and the full offline fallback — server disabled, tag authorized and charged locally, then on reconnect the binding discovers the running transaction and stops it remotely.
Two more charger-integration aids (both additive/opt-in): a session-energy connector channel — the whole-session energy (meter-stop minus meter-start), published once at session end, so a session total logs cleanly under everyChange with no rule; and a remoteStartRetries connector config (default 0) that retries a RemoteStart the charger does not answer, a few seconds apart, stopping as soon as a transaction starts so it never double-starts. Off by default, so a charger that answers first time is unaffected. 147 unit tests.
Tested. Running continuously against a Phoenix Contact CHARX SEC-3xxx (two connectors, no internal meter) and two Wallbox units (Copper SB and Pulsar Plus): metering and status, every control channel, transactions through complete sessions — including recovery across a charger reconnect mid-transaction and across an openHAB restart — charger reboots with the configuration burst, discovery, reconnects, and startup verification.
Not tested. Any other vendor. The watchdogs that recover a silent or wedged connector have not been triggered on real hardware. Vendor-specific DataTransfer is answered but unexercised.
Finding your charge point id. A chargepoint Thing stays UNKNOWN until a charger connects with a matching charge point id. The id is the WebSocket URL path the charger dials, with the leading slash removed — ws://<host>:8887/ALF-123 means the id is ALF-123. You do not have to guess it: if the charger reaches the server it is offered in the Inbox with its real id, or set log:set DEBUG org.openhab.binding.ocpp and reconnect and look for Charger connected: id=….
If you run a different brand I would like to hear how it goes — particularly whether your charger accepts the measurand list and what it does on a reboot.