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.

Ausgangslage

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:

1. Laden, Phasen, Start/Stop durch den lokalen Regler
2. Die Box bleibt OCPP-online
3. Enlighten, EverHome und Monta sehen Live-Daten, ohne die Box zu übernehmen

Das widerspricht sich, sobald das „Monitor“-Backend ein volles CSMS ist.

Das Problem

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:

• Enphase IQ Energy Router sendet laufend 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.
• EverHome spricht WebSocket ohne Subprotokoll ocpp1.6. Ein Standard-OCPP-Proxy bricht mit Server sent no subprotocol ab.
• Monta braucht CallResults, optional 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.

Ein Splitter allein reicht nicht

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.

Die Lösung: ocpp-fanout

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:

1. dummy-csms als Primary. Die Box braucht irgendwohin einen Peer, der CallResults liefert ([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.
2. Shims zwischen Joulo und jedem knickrigen Secondary. Joulo sieht einen normalen OCPP-1.6-Peer. Der Shim spricht upstream so, wie der Vendor es wirklich tut. Standard: CSMS-Calls lokal beantworten, die Wallbox sieht sie nie. Allowlist in der Setup-UI: ausgewählte Calls werden auf der Primary-Leitung injiziert, Joulo leitet sie zur Box, CallResult kommt zurück zum Vendor.
3. Web-UI auf demselben Host: Live-Paketfluss, Setup für Backend-URLs und Allowlist, Dark/Light. Erlaubte Befehle gelten sofort. Den Stack neu starten muss man nur nach URL-Änderung.

Ein Image, drei Shim-Dienste (SHIM_NAME / SHIM_PORT): Enphase, EverHome, Monta.

Wer darf was

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>.

Was die Shims konkret tun

• Enphase: lokale Antworten auf 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.
• EverHome: WebSocket ohne Subprotokoll ocpp1.6, sonst kommt die Verbindung nicht zustande.
• Monta: CallResults, optionales 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.

Sichtbarkeit

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).

Betrieb

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.

Hinweis

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.

Fazit

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.

HP iLO 4 spricht ein TLS, das moderne Browser und aktuelle OpenSSL-Bibliotheken ablehnen. Ein Reverse Proxy mit gültigem Zertifikat davor ist der pragmatische Weg: GET /redfish/v1 funktioniert, aber POST auf die Reset-Action kommt mit HTTP 502 vom Proxy zurück.

Zwei unabhängige Ursachen, beide typisch für iLO 4 hinter Traefik 3.

Warum überhaupt ein Proxy?

iLO 4 (ProLiant Gen8) bringt ein BMC-Zertifikat und Cipher-Suiten mit, die heutige Clients nicht mehr akzeptieren. Traefik terminiert TLS nach außen — zum Beispiel mit Let’s Encrypt — und spricht nach innen HTTPS gegen iLO, mit insecureSkipVerify.

Lesezugriffe laufen oft ohne weiteres durch. Schreibende Redfish-Calls, insbesondere Power-On über ComputerSystem.Reset, nicht.

Ursache 1: HTTP/2 und wiederverwendete TLS-Verbindungen

Traefik 3 spricht Backends über HTTPS standardmäßig mit HTTP/2 und hält TLS-Verbindungen offen. iLO 4 kommt damit nicht zurecht. Der Proxy sieht einen kaputten Upstream und antwortet 502 Bad Gateway.

Fix am Service, mit eigenem serversTransport:

http:
  serversTransports:
    iloTransport:
      insecureSkipVerify: true
      disableHTTP2: true
      forwardingTimeouts:
        idleConnTimeout: 1s

  services:
    ilo:
      loadBalancer:
        serversTransport: iloTransport
        passHostHeader: false
        servers:
          - url: "https://ilo.example.internal"

• disableHTTP2: true — HTTP/1.1 zum BMC
• idleConnTimeout: 1s — keine langlebigen Keep-Alive-Verbindungen
• insecureSkipVerify: true — das BMC-eigene Zertifikat
• passHostHeader: false — Host-Header des Backends, nicht des öffentlichen Namens

Ursache 2: fehlender Slash und HTTP 308

Redfish-Actions bei iLO 4 erwarten den trailing slash:

POST /redfish/v1/Systems/1/Actions/ComputerSystem.Reset/

Ohne Slash antwortet iLO mit 308 und einer Location auf die interne BMC-Adresse, nicht auf den öffentlichen Proxy-Namen. Traefik folgt dem Redirect oder scheitert daran — in beiden Fällen oft wieder 502.

Clients müssen die Action-URL mit Slash posten:

POST /redfish/v1/Systems/1/Actions/ComputerSystem.Reset/
Content-Type: application/json

{"ResetType":"On"}

Diagnose

Wenn GET /redfish/v1/ durch den Proxy HTTP 200 liefert, das BMC also erreichbar ist, POST aber 502:

1. Slash an der Action-URL prüfen
2. Traefik-Logs: 308 auf eine interne IP?
3. HTTP/2 und Keep-Alive am serversTransport abschalten

Wenn auch GET 502 liefert, ist das BMC oder der Weg dorthin down — das ist ein anderes Problem.

Fazit

iLO 4 hinter einem modernen Reverse Proxy ist machbar, aber nicht „einfach durchreichen“. Traefik 3 und iLO 4 vertragen sich bei POST nicht von selbst: HTTP/2 und TLS-Keep-Alive müssen raus, und Redfish-Actions brauchen den abschließenden Slash. Danach funktioniert Power-On über Redfish zuverlässig.

Eine liquidierte österreichische GmbH hinterlässt Mail, OneDrive und SharePoint in Microsoft 365. Die Aufbewahrung soll zehn Jahre halten: lesbar, nachvollziehbar, möglichst unveränderlich. Es gibt kein Budget für ein zertifiziertes Archivprodukt, und der Tenant läuft nicht ewig weiter.

Dieser Beitrag beschreibt Ausgangslage, Anforderungen und die Umsetzung eines selbstgebauten Verfahrens — inklusive der Stelle, an der die Microsoft-Konsole und der Export scheinbar nicht zusammenpassen.

Ausgangslage

Nach der Liquidation bleiben die Daten in Microsoft 365, bis jemand sie abzieht. Typische Versuchung: ZIP vom OneDrive, PST aus Outlook, SharePoint-Bibliothek „herunterladen“. Das ist weder vollständig noch nachvollziehbar, und in zehn Jahren will niemand raten, welche ZIP-Datei die richtige war.

Rechtlich relevant sind in Österreich unter anderem Nachvollziehbarkeit, Lesbarkeit und Unveränderbarkeit (BAO, UGB). Das ersetzt kein zertifiziertes DMS und keine Freigabe durch den Steuerberater. Frist und Umfang muss der Steuerberater bestätigen. Die Projektvorgabe hier war bewusst 10 Jahre, nicht die oft zitierte 7-Jahres-Untergrenze.

Dieses Verfahren ist nicht GoBD-zertifiziert, nicht BAO-zertifiziert und kein WORM-Produkt. Was Technik und Betrieb leisten, steht unten; Lücken werden nicht verschwiegen.

Anforderungen

• Originalbytes, nicht nur PDF-Renderings. Mail als MIME (.eml).
• Jede Datei mit SHA-256; Katalog und Blob müssen zusammenpassen.
• Finden ohne den Tresor zu durchsuchen: Excel-Katalog (Filterkopf, keine Makros, keine Formeln).
• Ablage mit Object Lock (Compliance, 10 Jahre), Versioning an. Der Alltagsbenutzer darf holen und Nachträge ablegen, nicht löschen.
• Microsoft-Quelle nur lesen, nichts löschen.
• Dry-Run ist Default. Cloud-Kosten nur mit explizitem Flag.
• Nach der Übergabe arbeitet der Empfänger mit Katalog und eigenem AWS-Zugang. Keine Abhängigkeit von der Werkstatt-Maschine.

Umsetzung

Die Pipeline ist klein und bewusst zweigeteilt.

Steuerung vs. Worker. Ein Laptop orchestriert (Erreichbarkeit, Provisioning, Sync). Der Export lief auf einer Wegwerf-VM. Nach dem Upload in den Tresor ist die VM weg; lokal bleibt nichts, was man in zehn Jahren noch booten müsste.

Microsoft Graph, nur lesen. Berechtigungen: Mail.Read, Files.Read.All, Sites.Read.All, User.Read. Der Archiv-Admin liegt außerhalb der Firmendomäne (*.onmicrosoft.com), nicht im Benutzerstamm der GmbH. App-Registrierung plus Admin-Consent; Secrets nie ins Git.

Originalbytes, Hash, Resume. Dateien und Mails landen als Content-Addressed Store plus Pfadkopie. Daneben SHA-256-Sidecars und Manifeste. Eine SQLite-Job-DB erlaubt Resume nach Abbruch. Das Audit-Log enthält keine Tokens und keine Mail-Bodies.

Katalog, nicht Suche im Bucket. Jeder Lauf schreibt Excel (Katalog.xlsx): ursprünglicher Pfad, Dateiname, Betreff, SHA-256, S3-Schlüssel, Fehler, Laufinfo, eine Blatt-Anleitung. Dieselbe Datei liegt zusätzlich unter einem festen Schlüssel im Bucket. Glacier/S3 bleibt der Tresor.

S3 Object Lock. Bucket in eu-central-1, Versioning an, Object Lock Compliance, Default-Retention 10 Jahre. Compliance lässt sich nicht umgehen — auch nicht als Root. IAM für den Empfänger: Lesen und PutObject für Nachträge (etwa eine Abschlussbilanz), kein Delete.

Übergabe. Paket ohne Secrets: Katalog, kleines CLI, Anleitung. Der Empfänger richtet Access Key und Secret einmal lokal ein (nicht per Chat). Alltag: im Katalog filtern, per Schlüssel holen, SHA-256 prüfen. Nachträge denselben Weg, wieder mit Hash-Zeile im Katalog.

Die Falle: Konsole vs. Export

Die Microsoft-Konsole und der Export messen nicht dieselbe Menge. Eine Abweichung heißt nicht automatisch „es fehlen Dateien“.

Was man sieht	Was es oft ist	Was der Export nimmt
Speicher in GB (Berichte, aktive Sites)	Site plus OneDrive, inklusive Versionen, Papierkorb, Metadaten	nur aktuelle Dateibytes
Websiteinhalte / Kachel „Dokumente“	Dateien und Ordner, oft Cache	nur Graph-file
Nutzungsbericht „Dateien“	inkl. System/Papierkorb, zeitversetzt	Katalogzeilen

In diesem Lauf: rund 13 000 Mails als .eml, rund 3 400 aktuelle SharePoint-Dateien (etwa 11 GB Inhalt). Die Konsole zeigte in der Größenordnung 65 GB. Stichprobe: Office-Dateien mit mehreren Versionen (eine Präsentation 27 MB aktuell, über alle Versionen ein Vielfaches). Große Videos oft nur eine Version. Versionen erklären den Großteil der GB-Lücke; sie sind in dieser Version bewusst nicht mitarchiviert.

Websiteinhalte zählte Dateien plus Ordner und lag dazwischen — unbrauchbar als Soll-Zahl. Persönliches OneDrive war klein; der Speicher saß auf der Team-Site.

Regel: Soll-Zahl für „haben wir alle aktuellen Dateien?“ ist Graph-file bzw. Katalogzeilen, nicht Konsole-GB und nicht Websiteinhalte. Konsole-GB gegen Graph-Quota; Katalog-SHA-256 gegen lokale Blobs.

Was bewusst fehlt

• bereits gelöschte Nachrichten und Dateien (Recycling, Soft-Delete, je nach Tenant)
• alte Dateiversionen (Graph holt /content der aktuellen Version)
• vollständige ACL- und Sharing-Historie
• Teams/Chat, OneNote, Litigation-Hold-Änderungen

Ein Dateitransport (rclone o. ä.) ersetzt kein Archiv-Zertifikat. Metadaten und Berechtigungen hängen vom Backend ab; die Vollständigkeit ist nicht zugesichert. Fehler und Teilmengen müssen über Job-DB und Verify sichtbar bleiben.

Fazit

Für eine liquidierte Firma mit klarer Frist reicht ein selbstgebautes, dokumentiertes Verfahren: Originalbytes, Hash, Katalog, Object Lock, ehrliche Lücken. Es ersetzt kein zertifiziertes DMS und keinen Steuerberater. Wer die Microsoft-Konsole als Soll-Zahl nimmt, sucht Dateien, die der Export nie holen sollte — vor allem alte Versionen.

Viele Heizungsanlagen besitzen Umwälzpumpen, die außerhalb der Heizsaison oft über Monate hinweg stillstehen. Dieses lange Stillstehen kann zum Problem werden: Rotoren verkleben, Lager setzen sich fest und die Pumpe läuft bei Beginn der Heizsaison nicht mehr zuverlässig an.

In diesem Beitrag beschreibe ich kurz, was CrowdSec ist, welche Zertifizierungen ich abgeschlossen habe, wie ich CrowdSec auf der E.F.A. (Email Filter Appliance) integriert habe, welche Filter out-of-the-box funktionieren — und wie ich fehlende Unterstützung (z. B. für MailScanner) durch eigene Parser und Szenarios ergänze.

Was ist CrowdSec?

CrowdSec ist eine Open-Source-Plattform zur Erkennung und Abwehr von bösartigen Aktivitäten anhand von Log-Analysen. Der Kern besteht aus einem lokalen Agenten, der Logs einliest, Ereignisse korreliert und auf Basis von Signalen (sogenannte scenarios) Entscheidungen trifft. Erkenntnisse können lokal genutzt oder an die Community-Sharing-Plattform gesendet werden, um die Reputationen von IPs zu teilen.

Meine Zertifizierungen

Ich habe mehrere Zertifizierungen rund um CrowdSec durchlaufen, die mir geholfen haben:

• Verständnis der Architektur (agent, bouncer, hub)
• Erstellung eigener Parser und Szenarios
• Integration mit externen Diensten (z. B. Firewalls, API-basierte Bouncer)

When running a Linux server, which is accessible from the Internet, you will see a lot of failed SSH authentication attemtps.
This article is not about securing your server (ssh-port-change, fail2ban, private/public-key-auth only, ...) but about visualizing these attacks.

ISC BIND allows for export of statistics using a web UI. This artice can help you avoid a common pitfall on CentOS.

Mounting a NFS share should be an easy task, however you might fail to mount the NFS share.
The ESXi vmkernel.log might show this error:
WARNING: NFS41: NFS41ExidNFSProcess:2054: Server doesn't support the NFS 4.1 protocol