From ae47a8b9e04665944e5a59b20062c4f658268dd3 Mon Sep 17 00:00:00 2001 From: Alexandre JARDON <28548335+webalexeu@users.noreply.github.com> Date: Tue, 21 Apr 2026 09:18:50 +0200 Subject: [PATCH] docs: add OCPP Forward reference documentation (en + de) --- .../docs/de/installation/configuration.mdx | 1 + .../reference/configuration/ocppforwarder.md | 66 +++++++++++++++++++ .../docs/en/installation/configuration.mdx | 1 + .../reference/configuration/ocppforwarder.md | 66 +++++++++++++++++++ 4 files changed, 134 insertions(+) create mode 100644 src/content/docs/de/reference/configuration/ocppforwarder.md create mode 100644 src/content/docs/en/reference/configuration/ocppforwarder.md diff --git a/src/content/docs/de/installation/configuration.mdx b/src/content/docs/de/installation/configuration.mdx index 6e6fd9c50..b01d0348c 100644 --- a/src/content/docs/de/installation/configuration.mdx +++ b/src/content/docs/de/installation/configuration.mdx @@ -49,6 +49,7 @@ Zusätzlich kannst du verschiedene Dienste und Protokolle einbinden: - **OCPP Server**: Verbindung mit OCPP-fähigen Wallboxen - **Lastmanagement**: Stromkreisüberwachung und -steuerung - **Modbus-Proxy**: Mehrfachzugriff auf Modbus-Geräte +- **OCPP-Weiterleitung**: Wallbox-Sitzungen an ein übergeordnetes OCPP-Backend spiegeln - **Sunny Home Manager**: Integration via SEMP-Protokoll - **Externe Begrenzung**: Leistungsbegrenzung durch Netzbetreiber (§ 14a EnWG, § 9 EEG) oder übergeordnete Energiemanagementsysteme diff --git a/src/content/docs/de/reference/configuration/ocppforwarder.md b/src/content/docs/de/reference/configuration/ocppforwarder.md new file mode 100644 index 000000000..5d06153b2 --- /dev/null +++ b/src/content/docs/de/reference/configuration/ocppforwarder.md @@ -0,0 +1,66 @@ +--- +title: "OCPP-Weiterleitung" +sidebar: + order: 18 +--- + +Die OCPP-Weiterleitung spiegelt die OCPP-Sitzung einer Wallbox zusätzlich zu evcc an ein übergeordnetes OCPP-Zentralsystem. + +Das ist nützlich, wenn evcc die Ladung steuern soll, während ein Drittanbieter-OCPP-Backend (Flottenmanagement, Abrechnungsplattform, CPO) ebenfalls die Telemetrie der Wallbox erhält und Befehle senden kann. + +Jede Wallbox verbindet sich normal mit dem eingebauten OCPP-Server. +Für jede Wallbox mit aktivierter Weiterleitung öffnet evcc eine zweite („Sidecar“-)WebSocket-Verbindung zum konfigurierten Upstream-Server und spiegelt die Sitzung: + +- **Wallbox zum Upstream**: alle OCPP-Nachrichten (Statusmeldungen, Zählerwerte usw.) werden in Echtzeit weitergeleitet. +- **Upstream zur Wallbox**: Befehle des Upstream-Servers (z. B. `UnlockConnector`, `ChangeConfiguration`) werden an die Wallbox durchgereicht, und die Antwort der Wallbox wird zurückgeleitet. + +evcc bleibt die primäre Steuerung und antwortet der Wallbox unabhängig vom Upstream-Server. + +## Konfiguration {#configuration} + +Die Weiterleitung wird pro Wallbox in der Oberfläche eingerichtet. +Öffne **Konfiguration → OCPP Server**, um die mit dem OCPP-Server verbundenen Wallboxen zu sehen. +Nutze neben jeder Wallbox die Schaltfläche **OCPP-Weiterleitung**, um die Weiterleitung für diese Wallbox zu aktivieren und einzurichten. + +### Upstream-Server-URL {#upstream-url} + +Die WebSocket-URL des übergeordneten OCPP-Zentralsystems. +Gib den vom Upstream-Server erwarteten Pfad-Präfix mit an. +Die Station-ID der Wallbox (oder die **Station-ID**-Überschreibung unten) wird automatisch angehängt, z. B. `wss://ocpp.example.com/ocpp/`. + +### Station-ID {#station-id} + +Die Wallbox-Kennung, die an den Upstream-Server gesendet wird. +Lass das Feld leer, um die eigene Station-ID der Wallbox zu verwenden. +Setze es, wenn das Upstream-System eine andere Kennung erwartet. + +### Benutzername {#username} + +Benutzername für HTTP-Basic-Auth am Upstream-Server. +Lass das Feld leer, wenn der Upstream-Server keine Authentifizierung benötigt. + +### Passwort {#password} + +Passwort für HTTP-Basic-Auth am Upstream-Server, wird zusammen mit dem **Benutzernamen** gesendet. +Der Basic-Auth-Header wird nur gesetzt, wenn ein Benutzername oder ein Passwort hinterlegt ist, bleibt also aus, solange keines von beiden gefüllt ist. + +### Upstream-Befehle {#upstream-commands} + +Standardmäßig kann der Upstream-Server über evcc Befehle an die Wallbox senden. +Aktiviere **Befehle vom Upstream-Server blockieren**, um die Weiterleitung schreibgeschützt zu machen: Der Upstream-Server erhält weiterhin jede Nachricht der Wallbox, kann sie aber nicht steuern, und evcc behält die alleinige Kontrolle. +Ein blockierter Befehl wird mit einem OCPP-`SecurityError` abgelehnt. + +### Zertifikatsprüfung {#certificate-validation} + +Bei `wss://`-Verbindungen wird das TLS-Zertifikat des Upstream-Servers standardmäßig geprüft. +Aktiviere **Selbstsignierte Zertifikate erlauben**, um diese Prüfung zu überspringen. + +:::caution +Erlaube selbstsignierte Zertifikate nur in Testumgebungen. +Das deaktiviert die Zertifikatsprüfung und macht die Verbindung anfällig für Man-in-the-Middle-Angriffe. +::: + +### Serverzertifikat (CA) {#server-certificate} + +Ein PEM-kodiertes CA-Zertifikat zur Prüfung des TLS-Zertifikats des Upstream-Servers. +Nutze es, wenn der Upstream-Server ein Zertifikat einer privaten oder internen CA verwendet, der das System standardmäßig nicht vertraut. diff --git a/src/content/docs/en/installation/configuration.mdx b/src/content/docs/en/installation/configuration.mdx index 06a1fc2d9..2f95a0169 100644 --- a/src/content/docs/en/installation/configuration.mdx +++ b/src/content/docs/en/installation/configuration.mdx @@ -49,6 +49,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 Forward**: Mirror charger sessions to an upstream OCPP backend - **Sunny Home Manager**: Integration via SEMP protocol - **External Limit**: Power limitation by grid operators (§ 14a EnWG, § 9 EEG) or higher-level energy management systems diff --git a/src/content/docs/en/reference/configuration/ocppforwarder.md b/src/content/docs/en/reference/configuration/ocppforwarder.md new file mode 100644 index 000000000..b51b9304d --- /dev/null +++ b/src/content/docs/en/reference/configuration/ocppforwarder.md @@ -0,0 +1,66 @@ +--- +title: "OCPP Forward" +sidebar: + order: 18 +--- + +OCPP Forward mirrors 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 the built-in OCPP server. +For every charger with forwarding enabled, evcc opens a second ("sidecar") WebSocket connection to the configured upstream server and mirrors the session: + +- **Charger to upstream**: all OCPP messages (status notifications, meter values, etc.) are forwarded in real time. +- **Upstream to charger**: commands sent by the upstream server (e.g. `UnlockConnector`, `ChangeConfiguration`) are injected into the charger, and the charger's reply is forwarded back. + +evcc remains the primary controller and responds to the charger independently of the upstream server. + +## Configuration {#configuration} + +Forwarding is set up per charger in the UI. +Open **Configuration → OCPP Server** to see the chargers connected to the OCPP server. +Next to each charger, use the **OCPP Forward** button to enable and configure forwarding for that charger. + +### Upstream server URL {#upstream-url} + +The WebSocket URL of the upstream OCPP central system. +Include the path prefix expected by the upstream server. +The charger's station ID (or the **Station ID** override below) is appended automatically, e.g. `wss://ocpp.example.com/ocpp/`. + +### Station ID {#station-id} + +The charger identifier sent to the upstream server. +Leave it empty to use the charger's own station ID. +Set it when the upstream system expects a different identifier. + +### Username {#username} + +Username for HTTP Basic Auth to the upstream server. +Leave it empty when the upstream server needs no authentication. + +### Password {#password} + +Password for HTTP Basic Auth to the upstream server, sent together with the **Username**. +The Basic Auth header is only added when a username or password is set, so it stays off unless you fill in at least one of the two. + +### Upstream commands {#upstream-commands} + +By default the upstream server can send commands to the charger through evcc. +Enable **Block commands from the upstream server** to make forwarding read-only: the upstream server still receives every charger message but cannot control the charger, and evcc keeps exclusive control. +A blocked command is rejected with an OCPP `SecurityError`. + +### Certificate validation {#certificate-validation} + +For `wss://` connections the upstream server's TLS certificate is validated by default. +Enable **Allow self-signed certificates** to skip this validation. + +:::caution +Only allow self-signed certificates in test environments. +This disables certificate validation and exposes the connection to man-in-the-middle attacks. +::: + +### Server certificate (CA) {#server-certificate} + +A PEM-encoded CA certificate used to validate the upstream server's TLS certificate. +Use it when the upstream server presents a certificate signed by a private or internal CA that the system does not trust by default.