Mehrere Shelly-Geräte der Generation 3 und ein Pro 4PM standen auf Firmware 2.0.0. Die stabile Version 2.0.1 vom 23. September 2026 war sichtbar, aber weder der automatische Job noch die Weboberfläche haben sie installiert. Drei Ursachen. Danach liefen die Geräte auf 2.0.1.

Das Auto-Update um Mitternacht

Shelly legt für Geräte ab Generation 2 einen täglichen Job an, Methode Shelly.Update, Stufe stable, um 00:00 Uhr. Unter Version 2.0.0 installiert genau diese Uhrzeit das Update nicht. Jede andere Uhrzeit funktioniert. Das ist im Shelly-Forum beschrieben. Die Jobs hier liegen jetzt nach 04:00 Uhr, jedes Gerät ein paar Minuten versetzt, Zeitzone Europe/Vienna. Ein Neustart ist für die neue Uhrzeit nicht nötig.

Die Weboberfläche bricht das Archiv ab

Der manuelle Weg über die Geräteoberfläche endet bei diesem Sprung oft mit Update failed: DATA_LOSS: ZIP flush error : premature end of data. Dieselbe Meldung kommt, wenn man die ZIP-Datei selbst hochlädt. Das Archiv ist dann abgeschnitten. Ein Neustart vor dem Versuch hat das hier nicht geheilt. Dieser Abbruch hängt nicht am BLE-Scanner: der Upload aus dem Browser läuft ohne das Skript.

Der BLE-Scanner nimmt den Speicher

Das Shelly-Plugin in Home Assistant kann auf dem Gerät das Skript aioshelly_ble_integration anlegen, solange der BLE-Scanner auf Auto steht. Das Skript startet wieder, auch wenn man es auf dem Gerät abschaltet. Die Scan-Ereignisse drücken den freien Speicher zusammen. Beim ersten Update-Versuch fiel er auf rund 27 KB, der Lauf blieb bei drei bis fünf Prozent stehen. Bluetooth-Zubehör hängt hier keines. Zuerst den Scanner im Plugin auf disabled stellen, danach das Skript stoppen und löschen. Steht der Scanner beim Neustart noch auf Auto, legt das Plugin das Skript wieder an. Unter Version 2.0.0 kann das Löschen eines Skripts das Gerät neu starten. Die Ausgänge sollten dabei aus sein.

So ist das Update hier durchgelaufen

1. Den BLE-Scanner im Shelly-Plugin von Home Assistant abschalten, das Skript auf dem Gerät stoppen und löschen.
2. Den täglichen Shelly.Update-Job von Mitternacht auf eine Zeit nach 04:00 Uhr legen, die Geräte versetzt, Stufe stable.
3. Die stabile Datei für genau dieses Modell laden und die Prüfsumme prüfen. Die Liste steht unter https://updates.shelly.cloud/update/ plus dem Firmware-Typ. Für den 23. September 2026, Version 2.0.1, sind das diese drei Dateien. fwcdn.shelly.cloud zeigt ein Zertifikat der eigenen Stelle Allterco, kein öffentliches. curl braucht deshalb --insecure. Die Prüfung ist der SHA-256 im letzten Pfadbestandteil, nicht die TLS-Kette. Die Prüfzeile ist das Format von sha256sum. Unter macOS heißt derselbe Aufruf shasum -a 256 -c.

curl --fail --location --insecure --output S1PMG3.zip \
  "https://fwcdn.shelly.cloud/gen2-ntest/S1PMG3/fe946f8c11e95cc43fa529a2350aeade32ad51229a75150926fd4a103e83b4ba"
printf '%s  S1PMG3.zip\n' \
  fe946f8c11e95cc43fa529a2350aeade32ad51229a75150926fd4a103e83b4ba | sha256sum -c

curl --fail --location --insecure --output S2PMG3.zip \
  "https://fwcdn.shelly.cloud/gen2-ntest/S2PMG3/db13df263b6aaf8f8b6ea00d9bfa426750af9345143d89275b6dce0ab1dd9a11"
printf '%s  S2PMG3.zip\n' \
  db13df263b6aaf8f8b6ea00d9bfa426750af9345143d89275b6dce0ab1dd9a11 | sha256sum -c

curl --fail --location --insecure --output Pro4PM.zip \
  "https://fwcdn.shelly.cloud/gen2-ntest/Pro4PM/541dac8d9dd53fd702413f8364527cfdd22d71148aa7e343bac14576a2e7cf64"
printf '%s  Pro4PM.zip\n' \
  541dac8d9dd53fd702413f8364527cfdd22d71148aa7e343bac14576a2e7cf64 | sha256sum -c

Die Dateien sind 3610278, 3496390 und 2553623 Byte. Eine Datei eines anderen Modells gehört nicht auf das Gerät.

4. Shelly.Update nimmt entweder stage oder url, nicht beides. Mit der CDN-Adresse in url reißt der Download auf Version 2.0.0 ab. Die geprüfte Datei liefert deshalb ein Rechner im selben Netz per HTTP aus. Im Beispiel ist das 192.168.1.10, Port 8765. Das Shelly-Gerät ist 192.168.1.33. Der Aufruf gilt für ein Gerät ohne RPC-Passwort. Die Weboberfläche wurde nach dem Abschalten des BLE-Scanners nicht noch einmal benutzt. Ob sie dann durchgelaufen wäre, ist offen.

python3 -m http.server 8765 --bind 192.168.1.10 --directory .

curl --fail --silent --show-error --request POST \
  --header "Content-Type: application/json" \
  --data '{"id":1,"method":"Shelly.Update","params":{"url":"http://192.168.1.10:8765/S1PMG3.zip"}}' \
  "http://192.168.1.33/rpc"

curl --fail --silent --show-error --request POST \
  --header "Content-Type: application/json" \
  --data '{"id":1,"method":"Shelly.Update","params":{"url":"http://192.168.1.10:8765/S2PMG3.zip"}}' \
  "http://192.168.1.33/rpc"

curl --fail --silent --show-error --request POST \
  --header "Content-Type: application/json" \
  --data '{"id":1,"method":"Shelly.Update","params":{"url":"http://192.168.1.10:8765/Pro4PM.zip"}}' \
  "http://192.168.1.33/rpc"

Der Eco-Modus blieb an. Der Download wurde dadurch langsamer, er lief aber durch. Am verkabelten Pro 4PM bleibt WLAN aus. Unter Version 2.0.1 verliert Ethernet sonst die Adresse, wenn WLAN zusätzlich aktiv ist. WLAN abzuschalten braucht keinen Neustart.

Quellen

• Shelly-Forum: automatisches Firmware-Update um Mitternacht
• ZIP-Flush-Fehler beim Sprung von 2.0.0 auf 2.0.1
• Changelog Gen2+, Version 2.0.1 vom 23. September 2026
• Shelly-Community: Firmware 2.0.1
• Pro 4PM auf 2.0.1: Ethernet verliert die Adresse, wenn WLAN an ist

Die App bietet für eine Venus E 3.0 (Firmware-Code VNSE3-0) das Control-Update auf V150 an, meldet Erfolg, und die Version bleibt V148.116.115. Dieselbe Version wird danach wieder angeboten. Das ist kein Anzeigefehler der App. Die Steuerung auf V148 bekommt das HTTP-Update über Ethernet nicht zu Ende, und V150 ist genau die Version, die diesen Weg reparieren soll.

Die Versionsanzeige hat drei Teile: Steuerung (EMS), Kommunikationsmodul und BMS. V148.116.115 heißt EMS 148, Kommunikationsmodul 116, BMS 115. Das verteilt angebotene Bündel V150.119.115 wäre EMS 150, Kommunikationsmodul 119 und BMS 115. Das Paket, das die Cloud für die Steuerung ausliefert, enthält nur die Control-Firmware 150. BMS und Kommunikationsmodul sind darin leer.

Was Control v150 ändert

Im Changelog von Control v150 vom 6. August 2026 stehen fünf Punkte: die Local API über Ethernet sendet wieder zuverlässig, das HTTP-Update im Ethernet-Modus schlägt nicht mehr fehl, Peak Shaving kommt dazu, zu lange HTTP-Daten gehen nicht mehr verloren, und der Zähler wird über CT_TYPE angebunden. Quelle ist die Firmware-Einreichung VNSE3-0 Control v150.

Zwei weitere Ursachen

Zwei weitere Ursachen tragen zum Problem bei. Die Venus nimmt auf Modbus-TCP nur eine Verbindung an. Ein Plugin in Home Assistant nutzt genau dieses Modbus-TCP, deshalb bleibt der Port belegt, solange das Plugin verbunden ist. Außerdem bestätigt die Cloud der App den Erfolg, auch wenn auf dem Gerät noch die alte Steuerung liegt. Im Photovoltaikforum ist der Ausweg beschrieben: dem Speicher im Router das Internet nehmen und das Update mit dem Telefon über Bluetooth anstoßen. Nur die WLAN-Client-Isolation abzuschalten reicht dort nicht.

So ist das Update hier durchgelaufen

1. Das Home-Assistant-Plugin anhalten, das Modbus-TCP zur Venus nutzt. Der TCP-Port wird frei.
2. In der Firewall nur den Weg dieses Geräts ins Internet sperren. Das lokale Netz, inklusive Modbus, bleibt offen. Eine Komplettsperre des Clients würde auch das Hausnetz kappen. Hängt der Speicher gleichzeitig an Ethernet und WLAN, gelten beide Schnittstellen. Sonst bleibt der Cloud-Weg über WLAN offen. Die WLAN-Isolation zwischen Clients blieb hier unverändert; der Speicher wurde über Bluetooth aktualisiert, nicht über WLAN.
3. Das Telefon neben das Gerät legen, die App im Vordergrund lassen und das Update über Bluetooth starten. Die App sollte mindestens 1.6.2 sein. Bei 100 Prozent drei bis fünf Minuten warten, die App offen lassen. Das steht so in der Marstek-FAQ zur Venus-Serie. Bietet die App keinen Update-Knopf, das Gerät in der App entfernen und das Update im Einrichtungsdialog starten. Vor dem Start die angezeigte Alt- und Neu-Version fotografieren, einschließlich BMS. Diesen Stand zeigt die App nur in diesem Dialog.
4. Danach die Version lesen. Hier steht jetzt V150.116.115: EMS 150, Kommunikationsmodul weiter 116 mit dem Build 202512040647, BMS weiter 115. Die Steuerung ist die neue. Das Kommunikationsmodul 119 aus dem genannten Bündel kam mit diesem Paket nicht mit.
5. Die Internet-Sperre wieder aufheben und das Home-Assistant-Plugin wieder starten. Der bisherige Betriebsmodus blieb unverändert. Die neue Spitzenlastkappung (in der App unter den Modi bei der Ausgabebeschränkung) wurde nicht eingeschaltet.

Ein BMS-Paket war nicht dabei. Die FAQ sagt zusätzlich: während eines BMS-Updates die RS485-Verbindung trennen. Wer nur die Steuerung aktualisiert, lässt die Akkuleitung in Ruhe.

Hinweise aus dem Umfeld

Zwei Hinweise aus dem Umfeld, die an diesem Gerät nicht nachgestellt wurden. In Forenberichten verlieren manche Speicher nach dem Sprung von 148 auf 150 den Zähler, bis man ihn neu anmeldet. Und in Control v150 einer Venus D setzt ein Watchdog den Netzwerkchip zurück, wenn der Cloud-Upload der Telemetrie nicht abfließt: etwa alle 30 Minuten bei Ethernet, etwa alle 15 Minuten bei WLAN. Ob dieselbe Schleife in der Venus-E-Version steckt, ist hier offen. Kurze Modbus-Aussetzer nach dem Update wären damit erklärbar. Das Forum empfiehlt nach einem Update außerdem einen vollen Entlade- und Ladezyklus zur BMS-Kalibrierung. Den habe ich nicht gemacht.

Wenn der Speicher danach nicht reagiert

Reagiert der Speicher nach einem fehlgeschlagenen Update nicht mehr, LEDs aus und nur der Lüfter läuft, reicht ein langer Tastendruck nicht. Netzstecker ziehen, mindestens zehn Minuten warten, dann wieder einschalten.

Quellen

• Firmware-Einreichung VNSE3-0 Control v150
• Archiv mit dem Changelog
• Photovoltaikforum, Aktueller Firmware-Stand
• Watchdog in Control v150, gelesen aus der Venus-D-Version
• Marstek FAQ Venus Series, Punkte zu App 1.6.2, Wartezeit bei 100 Prozent und RS485 beim BMS-Update

Seit dem 11. November 2019 bin ich auf wikifolio als Bullish71. Das Profil mit allen drei wikifolios: wikifolio.com/de/at/p/bullish71.

Die Zahlen sind der Stand vom 26. September 2026. Eine Bestandsaufnahme, keine Prognose und keine Anlageempfehlung.

Mit Aktien habe ich mich erstmals 1999 befasst, weil der damalige Arbeitgeber Aktien und Aktienoptionen als Teil des Gehalts angeboten hat. Danach kamen Fonds, Dachfonds, Aktien und Zertifikate. Beruflich sitze ich in der IT, bei Themen, die Bestehendes verschieben. Zuerst entscheide ich, worin ich überhaupt investieren würde. Den Zeitpunkt prüfe ich danach.

Bullish Stock Picking

Hier liegen Aktien, bei denen ich Innovationspotenzial sehe. Neue Technologie, Software, Internethandel, und Firmen, die von der Energiewende profitieren könnten. Ich halte lieber, als bei jedem Kursverlust zu verkaufen. Technisch schaue ich meist auf zwei Dinge: einen positiven MACD, und einen Kurs über dem Schnitt der letzten 90 Tage. Dazu der Blick auf Politik, Branche und Lieferketten. In der Regel mindestens zehn Titel. Ein einzelner soll nicht über rund die Hälfte hinaus, ETFs zur Streuung ebenfalls nicht.

Bullish Stock Picking (WFXBULLISH), ISIN DE000LS9TKG1, Erstemission 14. Juni 2022.

• Seit Erstellung +152,4 %
• Im Schnitt +14,8 % pro Jahr
• Letztes Jahr +13,6 %
• Volatilität ein Jahr 25,3 %
• Rendite/Risiko 0,4
• Zertifikategebühr 0,95 % p.a., Performancegebühr 9 %

Bullish DACH Select

Ein Dach aus anderen wikifolio-Zertifikaten, ohne Hebel. Ich suche Portfolios, die regelmäßig betreut werden und mindestens fünf Aktien halten. Breit gestreut, eher defensiv, mit langem Atem. Auf dem Profil führt wikifolio dieses als Top-wikifolio. Das Zertifikat ist in Deutschland zum Vertrieb zugelassen.

Bullish DACH Select (WFBULLDACH), ISIN DE000LS9RXP9, Erstemission 27. Juli 2021.

• Seit Erstellung +123,3 %
• Im Schnitt +13,3 % pro Jahr
• Letztes Jahr -1,8 %
• Volatilität ein Jahr 16,6 %
• Rendite/Risiko 0,6
• Zertifikategebühr 0 %, Performancegebühr 0 %

Bullish ETF

Eine Liste von ETFs, von denen ich mir eine positive Entwicklung erwarte. Keine Chartanalyse. Die Ideen kommen aus der Berichterstattung, auch aus Social Media. Ein Zertifikat gibt es dazu noch nicht, kaufen kann man es derzeit nicht.

Bullish ETF (WFXBULLETF).

• Seit Erstellung +82,3 %
• Im Schnitt +10,2 % pro Jahr
• Letztes Jahr +13,5 %
• Volatilität ein Jahr 23,4 %
• Rendite/Risiko 0,3
• Vorgesehene Zertifikategebühr 0,95 % p.a., Performancegebühr 5 %

Über alle drei weist wikifolio die Auszeichnung "Regelmäßige Aktivität" aus. In den Risikoklassen 1 bis 5 steht die Handelserfahrung jeweils auf drei oder mehr Jahre.

Die neue everHome-Oberfläche liegt unter everhome.cloud/app. Eine ältere Anleitung richtet das Überschussladen über das Intelligenz-Symbol im Reiter Strom ein. In der neuen Cloud ist das die Aufgabe in der Energieplanung, nicht mehr dieser Weg.

Gebraucht wird eine OCPP-fähige Wallbox, hier ein go-e Charger Gemini, und ein Stromzähler, den everHome schon ausliest. Ohne den Zähler kennt die Cloud den Überschuss nicht.

EcoTracker P1 am Smartmeter

Am Zähler der Netz Niederösterreich hängt ein everHome EcoTracker P1. Er steckt am P1-Anschluss des Smartmeters, mit dem beiliegenden RJ12-Kabel. Einen Elektriker braucht es dafür nicht. Die Installation ist einfach, und danach liegen die Zählerdaten in der everHome-Cloud.

Im Shop kostet der EcoTracker P1 derzeit 99 Euro: everhome.cloud/de/ecotracker-p1. Die everHome-App ist kostenlos, eine monatliche Gebühr für den Dienst nennt der Hersteller nicht.

Der P1-Anschluss muss beim Netzbetreiber freigeschaltet sein. Das Kennwort für den Smartmeter hat die Netz Niederösterreich innerhalb von zwei Werktagen geschickt, in zwei Teilen: das Kennwort in einem verschlüsselten ZIP, das Kennwort für das ZIP per SMS.

In der Cloud zeigt der EcoTracker die Leistungsaufnahme und die Zählerstände, die der P1-Anschluss liefert: Bezug 1.8.0 und Einspeisung 2.8.0.

Wallbox als Gerät anlegen

Unter Geräte auf Hinzufügen tippen und den Hersteller go-e wählen.

Als Produkt den Charger Gemini wählen. everHome zeigt danach eine OCPP-Adresse. Die gehört in die Wallbox, nicht in ein öffentliches Bild.

In der go-e App: Einstellungen, Verbindung, OCPP. Die angezeigte Adresse eintragen. Die Option Seriennummer an URL anhängen bleibt eingeschaltet. Damit meldet sich die Wallbox bei everHome.

Das Gerät ist danach sichtbar. Es lädt damit noch nicht mit dem PV-Überschuss.

Überschussladen ist eine eigene Aufgabe

Das Verhalten schaltet erst die Energieplanung: everhome.cloud/app/energy/management. Dort eine Aufgabe anlegen, die Wallbox auswählen und als Geräteverhalten Überschussladen setzen. Die Aufgabe muss aktiv sein.

Solange diese Aufgabe fehlt, bleibt der Gemini nur angebunden. everHome startet das Laden mit Überschuss nicht von selbst, nur weil das Gerät in der Liste steht.

Auf der Geräteseite zeigt die Kachel Energieplanung danach auf Überschussladen.

In der Energieplanung steht die Aufgabe mit dem Namen der Wallbox und dem Status Aktiv.

Öffnet man die Aufgabe, heißt das Geräteverhalten Überschussladen und der Status ist Aktiv. Erst das ist die Freigabe.

Ist der Gemini schon einer Aufgabe zugeordnet, bietet das Plus kein weiteres freies Gerät an. Das Verhalten sieht man dann an der bestehenden Aufgabe, nicht in einem leeren Auswahldialog.

Zähler und Gateway

In den Geräteeinstellungen hängen übergeordneter Stromzähler und Gateway am EcoTracker. Die OCPP-Adresse steht auf derselben Seite unter dem Speichern-Knopf. Sie ist ein Zugang zur Wallbox und bleibt aus dem Bild.

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.

Der Anwendungsfall

Im Sommer oder in Übergangszeiten bleibt die Pumpe meist komplett ausgeschaltet. Sobald die Heizperiode wieder beginnt, soll sie zuverlässig anlaufen – tut sie das nicht, drohen kalte Räume und im schlimmsten Fall ein kostspieliger Pumpentausch.

Der Workaround mit Shelly

Mit einem Shelly-Relais lässt sich ein einfacher Schutzmechanismus einbauen: Einmal pro Woche wird die Pumpe für ein paar Minuten eingeschaltet. Dadurch bleibt sie beweglich und lässt sich im Herbst wieder problemlos starten.

„Prävention ist günstiger als Reparatur – ein paar Minuten Pumpenlauf pro Woche können viel Ärger vermeiden.“

Integration in die Heizungssteuerung

Damit es keine Konflikte mit der Heizungssteuerung gibt, sollte das Skript am Ende den ursprünglichen Zustand wiederherstellen. Läuft die Pumpe, bleibt sie an – war sie ausgeschaltet, wird sie auch wieder ausgeschaltet.

Beispiel Ablauf:

• Shelly-Timer löst wöchentlich aus
• Pumpe läuft für 2–3 Minuten
• Ursprünglicher Status der Heizungssteuerung wird wieder gesetzt

Beispielskript (Shelly Script)

Das folgende Skript lässt sich direkt im Shelly eintragen:

// Shelly Script: Pumpe wöchentlich kurz einschalten
// Funktion, die nach 60s prüft ob der Eingang aktiv ist
function checkInputAndSwitch() {
  let input = Shelly.getComponentStatus("input:0");
  if (input.state) {
    print("Eingang ist aktiv – Pumpe bleibt EIN");
  } else {
    Shelly.call("Switch.Set", { id: 0, on: false });
    print("Eingang ist aus – Pumpe wird ausgeschaltet");
  }
}

// Schedule erstellen: Montag 09:00 Uhr
Shelly.call("Schedule.Create", {
  enable: true,
  timespec: "0 9 * * 1",  // Montag 09:00
  calls: [
    {
      method: "Switch.Set",
      params: { id: 0, on: true }
    },
    {
      // hier wird das Script selbst gestartet,
      // welches dann den Timer setzt
      method: "Script.Start",
      params: { id: Shelly.getCurrentScriptId() }
    }
  ]
});

// Event-Handler: wenn das Script gestartet wird (durch Schedule)
Shelly.addEventHandler(function (ev, data) {
  if (ev === "script_started") {
    // Timer: 60 Sekunden warten, dann Funktion aufrufen
    Timer.set(60 * 1000, false, checkInputAndSwitch);
  }
});


          

Fazit

Mit wenig Aufwand lässt sich so die Lebensdauer der Pumpe verlängern. Die Kombination aus Shelly-Automatisierung und Timer bietet eine einfache, aber wirkungsvolle Lösung, um teuren Defekten vorzubeugen.

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)

Die Zertifizierungen haben vor allem im Bereich Log-Modelling und Scenario-Design meine Fähigkeit verbessert, aus oft heterogenen Mail-Logs zuverlässige Signale zu extrahieren.

CrowdSec auf der E.F.A. (Email Filter Appliance)

Auf meiner E.F.A. läuft ein Satz klassischer Mail-Dienste (sshd für Remote-Management, postfix für SMTP, SpamAssassin und MailScanner für Mailprocessing). CrowdSec lässt sich gut auf der E.F.A. betreiben und bringt sofort Mehrwert:

• Out-of-the-box: Für viele Dienste existieren bereits Parser & Szenarios — z. B. sshd, postfix, webserver-logs, und mehr.
• Mail-spezifische Lücken: Für MailScanner gibt es jedoch zum Zeitpunkt meiner Integration kein fertiges Parser-/Scenario-Paket.

Warum kein MailScanner-Support vorhanden ist

MailScanner ist in vielen Installationen ein wichtiger Teil der Mailpipeline. Da seine Logstruktur teils proprietär oder stark konfigurierbar ist, existieren nicht immer allgemeingültige Parser. Außerdem sind Mail-Logs oft sehr rauschbehaftet — viele Events sind normal und müssen gefiltert werden.

Meine Lösung: Eigene Parser & Szenarios

Ich habe deshalb eigene parsers (für die Log-Formate) und scenarios (für die Erkennung von Angriffs-/Missbrauchsmustern) geschrieben. Hier die konkreten Beispiele:

Parser a) MailScanner Spam Blacklist

name: cbrandlehner/mailscanner-spam-blacklist
description: Parse MailScanner spam logs for blacklisted senders
onsuccess: next_stage
filter: "evt.Parsed.program == 'MailScanner'"
grok:
  pattern: 'Message %{NOTSPACE:message_id} from %{IP:source_ip} \(%{EMAILADDRESS:from_email}\) to %{NOTSPACE:to_domain} is spam \(%{WORD:spam_reason}\)'
  apply_on: message
statics:
  - meta: log_type
    value: mailscanner_blacklist
  - meta: source_ip
    expression: evt.Parsed.source_ip
  - parsed: source_ip
    expression: evt.Parsed.source_ip
  - parsed: spam_reason
    expression: evt.Parsed.spam_reason
  - parsed: rawmessage
    expression: evt.Line.Raw

Parser b) MailScanner Spam mit Score

name: cbrandlehner/mailscanner-spam
description: Parse MailScanner spam logs
onsuccess: next_stage
filter: "evt.Parsed.program == 'MailScanner'"
grok:
  pattern: 'Message %{NOTSPACE:message_id} from %{IP:source_ip} \(%{EMAILADDRESS:from_email}\) to %{NOTSPACE:to_domain} is spam.*(score|Wertung)=%{NUMBER:spam_score}'
  apply_on: message
statics:
  - meta: log_type
    value: mailscanner_spam
  - meta: source_ip
    expression: evt.Parsed.source_ip
  - parsed: source_ip
    expression: evt.Parsed.source_ip
  - parsed: spam_score
    expression: float(evt.Parsed.spam_score)
  - parsed: rawmessage
    expression: evt.Line.Raw

Scenario c) Blacklisting sofort sperren

name: cbrandlehner/mailscanner-blacklisted
description: Detects MailScanner logs where a message is marked as spam due to blacklisting
type: trigger
filter: "evt.Meta.log_type == 'mailscanner_blacklist' && evt.Parsed.spam_reason == 'blacklisted'"
groupby: evt.Parsed.source_ip
blackhole: 5m
labels:
  type: spam
  remediation: true
  behavior: "smtp:spam"
  spoofable: 0
  confidence: 2
  label: "MailScanner detected an SMTP message from an blacklisted sender"
  service: smtp

Scenario d) SPAM mit sehr hohem Score

name: cbrandlehner/mailscanner-highscore-spam
description: Detects spam messages in MailScanner logs with score > 20.0
type: leaky
filter: "evt.Meta.log_type == 'mailscanner_spam' && float(evt.Parsed.spam_score) > 20.0"
groupby: evt.Parsed.source_ip
leakspeed: 10s
capacity: 1
blackhole: 5m
labels:
  type: spam
  remediation: true
  behavior: "smtp:spam"
  spoofable: 0
  confidence: 1
  label: "MailScanner classifed an SMTP email as SPAM with a spam_score higher 20"
  service: smtp

Testing & Deployment

Meine Vorgehensweise:

1. Parser lokal gegen historische Logs testen (benchmarks, grep + regex)
2. Scenarios in simulation mode laufen lassen, Alerts sammeln
3. False-Positives analysieren und Regex/Filter verbessern
4. Produktion: Szenarien schrittweise aktivieren und Monitoring ergänzen

Tipps & Best-Practices

• Nutze labels im Parser, damit Szenarien gezielt filtern können.
• Beginne mit conservative thresholds und verfeinere.
• Verwende CrowdSec-Community-Feeds, aber prüfe sie — nicht alle Blocks sind in jeder Umgebung sinnvoll.

Fazit

CrowdSec ist ein mächtiges Werkzeug für die Absicherung von Mail-Infrastrukturen — auf der E.F.A. liefert es sofort Mehrwert für viele Standarddienste. Für spezielle Tools wie MailScanner lohnt sich jedoch die Erstellung eigener Parser und Szenarios: so kannst du präzise Signale erzeugen und die False-Positive-Rate niedrig halten.

Den vollständigen Parser, die Szenarien, die Collection und meine Test-Scenarios habe ich als Pull Request zur Diskussion auf GitHub veröffentlicht: PR #1500 im CrowdSec Hub.