Die meisten Wallboxen haben genau einen OCPP-WebSocket. Lokal soll trotzdem der eigene Regler Strom und Phasen setzen — MQTT, HTTP, Modbus, nicht das Backend in der Cloud. Gleichzeitig sollen Dienste wie ein Enphase IQ Energy Router, EverHome oder Monta live mitlesen. Wer den einen Slot an ein Vendor-CSMS hängt, gibt die Steuerung oft stillschweigend ab.
Dieser Beitrag beschreibt die Problemstellung und wie ein eigenes Open-Source-Projekt sie löst: ocpp-fanout.
OCPP 1.6-J ist der Kanal, den die Wallbox für die Backend-Kommunikation
hat. Ein Slot heißt: eine WebSocket-URL. Alles, was die Box als CSMS
ansieht, darf CallResults liefern — und in der Praxis auch Befehle
schicken: SetChargingProfile, RemoteStart,
ChangeConfiguration.
Ich will drei Dinge gleichzeitig:
Das widerspricht sich, sobald das „Monitor“-Backend ein volles CSMS ist.
Viele Monitor-Backends sind keine reinen Zuschauer. Sie schicken Calls zur Wallbox. Ohne CallResult gilt die Box in der App als tot. Mit unkontrollierter Weiterleitung übernimmt das Backend die Ampere. Beides ist falsch, wenn der lokale Regler die Ladeleistung setzt.
Konkret:
GetConfiguration und
TriggerMessage(StatusNotification). Ohne lokale Antwort bleibt
Enlighten leer, obwohl der WebSocket steht. Leitet man
SetChargingProfile durch, springen die Ampere — der Router
soll im Monitor-Modus zuschauen, nicht laden.ocpp1.6. Ein Standard-OCPP-Proxy bricht mit
Server sent no subprotocol ab.RemoteStart und stimmige StartTransaction /
transactionId. Ein Dummy, der andere IDs vergibt, füllt das
Ladeprotokoll nicht.Die Wallbox kann das nicht gleichzeitig erfüllen. Es gibt nur einen Slot.
joulo-ocpp-proxy macht genau den Split 1→N: eine eingehende Verbindung, ein Primary mit voller Kontrolle, beliebig viele Secondaries als Spiegel. Secondary zur Wallbox wird verworfen. Das ist gewollt: ein Secondary darf die Box nicht fernsteuern.
| Richtung | Primary | Secondary |
|---|---|---|
| Wallbox → CSMS | weitergeleitet | gespiegelt |
| CSMS → Wallbox | weitergeleitet | verworfen |
Genau dort kippt der Plan. Die Monitor-Backends schicken trotzdem Calls. Joulo wirft sie weg und antwortet nicht an ihrer Stelle. Es gibt kein CallResult, die Vendor-App bleibt ohne Live-Status (historische kWh können trotzdem erscheinen).

Joulo hat außerdem nur einen Schalter
SECONDARY_CSMS_APPEND_CHARGE_POINT_ID. Enphase will die
Charge-Point-ID in der URL, EverHome und Monta haben die Identität oft
schon im Pfad. Ein Flag für alle Secondaries passt nicht.
Ich habe Joulo nicht geforkt. Der Proxy bleibt das Image von
ghcr.io. Davor und dahinter sitzt eigener Code: ein Dummy-Primary,
kleine Antwort-Shims und eine Web-UI.

Drei Ergänzungen schließen die Lücken:
[3, id, payload]), sonst gilt sie
als offline. Der Dummy tut das. Eigene Steuerung sendet er nicht.
POST /inject ist der einzige Weg, über Joulo einen CSMS-Call
zur Box zu schicken — und der Endpunkt hängt nur am Compose-Netz,
nicht am Host.Ein Image, drei Shim-Dienste (SHIM_NAME /
SHIM_PORT): Enphase, EverHome, Monta.
| Ziel | Wer |
|---|---|
| Laden, Phasen, Start/Stop | lokaler Regler (MQTT / Enphase HTTP, nicht OCPP) |
| Box bleibt OCPP-online | Dummy-CSMS als Primary |
| Enlighten / EverHome / Monta sehen Live-Daten | Secondaries über Shims |
| Ausgewählte CSMS-Befehle dürfen zur Box | Setup-Allowlist → Dummy-Inject durch Joulo |
| Alles andere bleibt von der Box fern | Shim antwortet lokal, UI zeigt dropped |
Die Wallbox zeigt auf einen WebSocket:
ws://<host>:9100/<chargePointId>.
GetConfiguration und TriggerMessage. Wer Live-Status
in Enlighten will, erlaubt in Setup
TriggerMessage:StatusNotification.
SetChargingProfile bleibt von der Allowlist fern, solange der
Router nur beobachten soll.ocpp1.6, sonst kommt die Verbindung nicht zustande.RemoteStart
(nur wenn allowlisted), transactionId auf MeterValues /
StopTransaction auf die von Monta vergebene ID mappen,
StartTransaction nachspielen, wenn schon eine Session offen
ist.Spec-konforme lokale Antworten gibt es auch für RFID-Liste und Clear
Profile (Accepted), ohne die Box zu beschreiben.
Ohne UI rät man, welcher Call wo landet. Die Live-Ansicht zeigt den Paketfluss: Wallbox, Proxy, Dummy, Shims, Backends — und den Korb dropped für alles, was der Secondary nicht zur Box durchreicht.

Beim Laden zeigt die EV-Karte Phasen, Ampere je Phase und kW aus den
MeterValues (Current.Import L1/L2/L3 und
Power.Active.Import).
Zwei Compose-Dateien: voller Stack mit Healthchecks und rotierten Logs, oder
eine einfache Variante ohne Healthchecks, in der Charge-Point-ID, Backend-URLs
und Allowlist nur in der Setup-UI stehen. Compose baut Dummy, Shim und UI
lokal; Joulo kommt von ghcr.io.
git clone https://github.com/cbrandlehner/ocpp-fanout.git
cd ocpp-fanout
git checkout v1.0.0
cp .env.example .env
docker compose up -d --build
Web-UI: http://<host>:8088/. Den OCPP-WebSocket
(Standardport 9100) und die Setup-UI nicht ins öffentliche Internet
legen. Strom und Phasen gehören zum lokalen Regler, nicht zum Secondary,
es sei denn, ein Befehl steht bewusst auf der Allowlist.
Quellcode und Release 1.0: github.com/cbrandlehner/ocpp-fanout, Tag v1.0.0. Deutsche Bedienung: docs/ANLEITUNG.md.
ocpp-fanout ist ein unabhängiges Open-Source-Projekt ohne Herstellersupport. Es steht in keiner Verbindung zu go-e, Enphase, everHome, Monta, Joulo, Tesla oder anderen Anbietern, deren Produkte es ansprechen kann, und wird von diesen weder unterstützt noch empfohlen. Nutzung auf eigene Gefahr. Produktnamen dienen nur der Beschreibung der Anbindung.
Ein OCPP-Slot kann nicht gleichzeitig lokaler Regler und drei Vendor-CSMS sein. Joulo teilt 1→N und hält Secondary-Steuerung von der Box fern — das allein lässt Enlighten, EverHome und Monta aber tot aussehen, weil ihnen die CallResults fehlen. ocpp-fanout ergänzt Dummy, Shims und UI: die Secondaries bleiben am Leben, Antworten sind lokal, und nur eine explizite Allowlist darf einen Befehl zur Wallbox injizieren. Die Steuerung bleibt, wo sie hingehört.