docs: add OCPP forwarder reference documentation

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
 

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.

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
 

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.