BootNotification, Heartbeat, StartTransaction / StopTransaction, MeterValues, ChangeConfiguration, and the rest — bridging that session to handlers on the device. It is native to Omega (not a deprecated module), but it is opt-in: you compile it in only for devices that need it.
1. Build with the feature
ocpp pulls a tokio runtime and a ZeroMQ transport (the bridge talks to its session handler over ZeroMQ). See Build Omega for the feature model.
2. Enable the module
Add the module to the profile and grant its capability. The module id isocpp-bridge:
3. Configure the bridge
The bridge reads anocpp_bridge: section (note the underscore). The minimum is where to connect and how to identify the charge point:
Config reference — ocpp_bridge
TLS — ocpp_bridge.tls
For a CPMS that needs a custom CA or mutual TLS:
Omit
tls to use the system trust store with no client certificate.
Internal transport (advanced)
The bridge communicates with its session handler over ZeroMQ. These default to loopback endpoints and rarely need changing:Notes
- This is a WebSocket-to-CPMS path, separate from Omega’s MQTT connection to the Golain platform — a device can run both: managed by Golain over MQTT, and speaking OCPP to a CPMS over its own WebSocket.
charge_point_idmust match what the CPMS expects for this device; it’s part of the WebSocket URL and the sub-protocol handshake.
See also
- Build Omega — the
ocppfeature in the build model. - Configure Omega — the profile the
ocpp_bridgesection lives in.