OCPP Binding
This binding makes openHAB an OCPP 1.6-J central system, so EV chargers connect to it directly over WebSocket with no vendor cloud in between.
It reads connection state, connector status, transactions and the MeterValues measurand set, and it controls charging: current limit and pause via SetChargingProfile, remote start/stop, availability, unlock and reset.
Download: org.openhab.binding.ocpp-5.3.0-SNAPSHOT.jar
This is a beta, published with the intention of getting it in as an official binding — it is under review at openhab/openhab-addons#21265.
Supported Things
server— the WebSocket endpoint chargers dial in to. Bridge for everything below it.chargepoint— one physical charger, matched to a session by its OCPP charge point id (the last path segment of the URL it dials). Bridge for its connectors.connector— one outlet, carrying the status, metering and control channels.
Chargers point at ws://<openhab-host>:8887/<chargePointId>.
Discovery
Passive: a charger connecting with an id that has no thing appears in the inbox, and its connectors appear as they first report status. There is no active scan — chargers announce themselves.
Thing Configuration
server: port (8887), host, heartbeatInterval, plus advanced settings that are pushed to each charger after it boots — meterValuesData, meterValueSampleInterval, clockAlignedDataInterval, disableRemoteTxAuthorization, vendorConfig, and the tags / chargers allow-lists.
chargepoint: chargePointId (required), configSettleSeconds, meterless, heartbeat.
connector: connectorId, forceTxDefaultProfile, profileMinIntervalMs, hardwareMaxCurrentKey, remoteStartTag, meterValuesPollSeconds.
Full tables are in the README.
Channels
On the connector: charge-point-status, cable-connected, charging, charge-limit, pause, availability, lock, reset, hardware-max-current, per-phase current-import-l1..l3 and voltage-l1..l3, current-offered, power-active-import, power-offered, energy-active-import, and the transaction metadata (id-tag, transaction-id, meter-start, meter-stop, timestamps).
The rest of the OCPP measurand set — reactive and exported power and energy, frequency, power factor, and vehicle-reported SoC, RPM and temperature — is added to a connector only once a charger actually reports it, so an AC charge point does not end up with a dozen channels that stay empty.
Example
Bridge ocpp:server:main [ port=8887 ] {
Bridge chargepoint wallbox "Wallbox" [ chargePointId="wallbox" ] {
Thing connector c1 "Connector 1" [ connectorId=1 ]
}
}
String Wallbox_Status "Status [%s]" { channel="ocpp:connector:main:wallbox:c1:charge-point-status" }
Number:Power Wallbox_Power "Power [%.0f W]" { channel="ocpp:connector:main:wallbox:c1:power-active-import" }
Number:ElectricCurrent Wallbox_Limit "Limit [%.0f A]" { channel="ocpp:connector:main:wallbox:c1:charge-limit" }
Notes from running it
Configuration is pushed to a charger once it has accepted it, not on every reconnect. A charger that is busy — flushing an offline message queue, for instance — can leave a request unanswered, and an unanswered request times out and drops the session, so re-sending on every reconnect turns one reconnect into a loop.
Metering parsing is tolerant on purpose: a measurand a charger rejects is dropped and the rest retried, an omitted measurand defaults to the energy register, and a value that cannot be represented is skipped rather than failing the whole message.
Chargers that reject a TxProfile outside a transaction (Phoenix CHARX does) can send the charge limit as a TxDefaultProfile with forceTxDefaultProfile.
What has and has not been tested
Running continuously since 21 July 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, charger reboots including the configuration burst, discovery, reconnects, and an openHAB restart. Built against 5.3.0-SNAPSHOT and running on 5.2.0.
Not tested: any other vendor. The watchdogs that recover a silent or wedged connector have not been triggered on real hardware, since that means provoking a real fault. Vendor-specific DataTransfer is answered but unexercised — no charger here sends it.
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.