diff --git a/i18n/en/docusaurus-plugin-content-docs/current/installation/configuration.mdx b/i18n/en/docusaurus-plugin-content-docs/current/installation/configuration.mdx index 7755d74c1..492053c10 100644 --- a/i18n/en/docusaurus-plugin-content-docs/current/installation/configuration.mdx +++ b/i18n/en/docusaurus-plugin-content-docs/current/installation/configuration.mdx @@ -44,6 +44,7 @@ Additionally, you can integrate various services and protocols: - **OCPP Server**: Connection with OCPP-capable wallboxes - **Circuits**: Circuit monitoring and control - **Modbus Proxy**: Multiple access to Modbus devices +- **OCPP Forwarder**: Mirror charger sessions to an upstream OCPP backend - **Sunny Home Manager**: Integration via SEMP protocol - **HEMS**: External control and grid operator integration diff --git a/i18n/en/docusaurus-plugin-content-docs/current/reference/configuration/ocppforwarder.md b/i18n/en/docusaurus-plugin-content-docs/current/reference/configuration/ocppforwarder.md new file mode 100644 index 000000000..a44c19b86 --- /dev/null +++ b/i18n/en/docusaurus-plugin-content-docs/current/reference/configuration/ocppforwarder.md @@ -0,0 +1,125 @@ +--- +sidebar_position: 18 +--- + +# `ocppForwarder` + +The `ocppForwarder` setting is a list of rules that mirror a charger's OCPP session to an upstream OCPP central system in parallel to evcc. + +This is useful when you want evcc to manage charging while a third-party OCPP backend (fleet management, billing platform, CPO) also receives the charger's telemetry and can issue commands. + +Each charger connects normally to evcc's built-in OCPP server. For each matching rule, evcc opens a second ("sidecar") WebSocket connection to the configured upstream server and mirrors the session: + +- **Charger → upstream**: all OCPP Calls (status notifications, meter values, etc.) are forwarded in real time. +- **Upstream → charger**: OCPP Calls sent by the upstream server (e.g. `UnlockConnector`, `ChangeConfiguration`) are injected into the charger, and the charger's reply is forwarded back to upstream. The upstream server can also be configured as read-only (`readOnly: true`), in which case it receives telemetry but cannot issue commands to the charger. + +evcc remains the primary controller — it responds to the charger independently of the upstream server. + +**For example**: + +```yaml +ocppForwarder: + - stationId: "*" + upstreamUrl: wss://ocpp.example.com/ocpp/ + - stationId: CP-001 + upstreamUrl: wss://fleet.example.com/ocpp/ + password: s3cr3t + upstreamStationId: SITE-CP-001 + readOnly: true +``` + +:::tip Sponsortoken required + +For more information about evcc sponsorship, please visit [the sponsorship page](/docs/sponsorship). + +::: + +--- + +## Required Parameters + +### `stationId` + +The OCPP station identifier of the charger to forward. Use `*` as a wildcard to match all chargers that do not have a more specific rule. + +**For example**: + +```yaml +stationId: CP-001 +``` + +### `upstreamUrl` + +The WebSocket URL of the upstream OCPP central system. Must include the path prefix expected by the upstream server; the charger's station ID (or `upstreamStationId` if set) is appended automatically. + +**For example**: + +```yaml +upstreamUrl: wss://ocpp.example.com/ocpp/ +``` + +--- + +## Optional Parameters + +### `password` + +HTTP Basic Auth password used when connecting to the upstream server. The username is the charger's station ID (or `upstreamStationId` if set). + +**For example**: + +```yaml +password: s3cr3t +``` + +### `upstreamStationId` + +Override the station ID sent to the upstream server. Useful when the upstream system uses a different identifier than the one the charger presents to evcc. + +**For example**: + +```yaml +upstreamStationId: SITE-CP-001 +``` + +### `readOnly` + +When set to `true`, the upstream server can observe the session but cannot issue commands to the charger. Any `Call` received from upstream is rejected with an OCPP `SecurityError` and not forwarded. + +**Possible values**: + +- `true`: Upstream commands are blocked +- `false` (default): Upstream commands are forwarded to the charger + +**For example**: + +```yaml +readOnly: true +``` + +### `insecure` + +Skip TLS certificate validation when connecting to the upstream server over `wss://`. Useful for self-signed certificates in test environments. + +:::caution +Do not use `insecure: true` in production — it disables certificate validation and exposes the connection to man-in-the-middle attacks. +::: + +**For example**: + +```yaml +insecure: true +``` + +### `caCert` + +PEM-encoded CA certificate used to validate the upstream server's TLS certificate. Use this when the upstream server uses a certificate signed by a private or internal CA that is not trusted by the system. + +**For example**: + +```yaml +caCert: | + -----BEGIN CERTIFICATE----- + MIIDXTCCAkWgAwIBAgIJA... + -----END CERTIFICATE----- +```