Manchmal braucht es nur einen einzigen Post in der Timeline, und man landet in einem Kaninchenbau. So geschehen heute: Ein Mastodon-Post von @Doppellhelix vom 2. März 2026 hat mich auf das Projekt evcc Crowdscience aufmerksam gemacht. Ein Forschungsprojekt der HTW Berlin, bei dem evcc-Nutzer:innen ihre Ladedaten anonym für die Energiewende-Forschung spenden können. Klingt gut, dachte ich.
Es hat dann etwas länger gedauert. Allerdings läuft es jetzt wirklich gut auf unserem Timberwolf-Server und vollkommen unauffällig im Hintergrund.
Was ist evcc Crowdscience?
Die Forschungsgruppe Solarspeichersysteme der HTW Berlin sammelt im Projekt evcc Crowdscience anonymisierte Messdaten von PV-Anlagen und Ladevorgängen. Wer evcc – die Open-Source-Software für PV-Überschussladen – betreibt, kann freiwillig mitmachen.
Übertragen werden dabei:
- Ladeleistung
- PV-Erzeugung
- Batteriezustand (SoC)
- Netzbezug und -einspeisung
Explizit nicht übertragen werden IP-Adressen, Standortdaten oder irgendwelche personenbezogenen Informationen. Die Zuordnung läuft ausschließlich über ein selbst generiertes, anonymes Token, das man sich einmalig auf der Projektseite erstellt. Teilnahme ist jederzeit beendbar.
Kurz: Ein sinnvolles Projekt, bei dem man mit ziemlich überschaubarem Aufwand echte Forschungsdaten beisteuert.
Das Problem: evcc kennt nur einen MQTT-Broker
evcc läuft bei mir als Docker-Container auf dem Timberwolf-Server 3500XL (TWS) von ElabNET. Daneben laufen dort u. a. Mosquitto (MQTT-Broker), Home Assistant und CometVisu. Der TWS ist mein zentrales Hausautomations-Herzstück – alles Relevante läuft darauf.
Der naheliegende Weg wäre gewesen: evcc direkt mit dem HTW-Broker verbinden. Geht nicht – aus zwei Gründen:
- evcc unterstützt nur einen MQTT-Broker gleichzeitig. Der ist bei mir bereits mit meinem lokalen Mosquitto belegt, über den Home Assistant und andere Dienste kommunizieren. Den einfach umzubiegen wäre keine Option.
- Der HTW-Broker läuft auf WSS Port 443 (WebSocket Secure). Das schließt eine native Mosquitto-Bridge aus, die üblicherweise plain MQTT oder MQTT over TLS (Port 8883) erwartet – aber kein WebSocket.
Sprich: Direktweg versperrt, Umweg gesucht.
Die Lösung: Community-Bridge
@Doppelhelix hatte mich freundlicherweise auf eine fertige Lösung der evcc-Community hingewiesen. Dort hatte bereits jemand genau für diesen Fall eine Lösung entwickelt: iseeberg79/evcc-crowdscience-bridge – ein Python-Skript, das als eigener Container läuft und zwischen lokalem Broker und dem HTW-Broker vermittelt.
Der Datenfluss sieht so aus:
evcc → lokaler Mosquitto (172.17.0.2:1883)
→ Bridge-Container (Python)
→ mqtt.evcc-crowdscience.de:443 (WSS/TLS)Die Bridge abonniert beim lokalen Broker alle evcc-Topics, filtert anhand einer Whitelist (die automatisch vom HTW-GitHub geladen wird) alles heraus, was nicht weitergegeben werden soll, und schickt nur die erlaubten Messwerte an den Forschungsbroker.
Für die TWS-spezifische Einrichtung – Named Volume, SSH-Container-Workflow, Image-Wahl und Umgebungsvariablen – habe ich eine eigene Anleitung im Forum geschrieben (siehe unten). Ein paar Punkte davon erkläre ich hier trotzdem, weil sie nicht offensichtlich sind.
Installation auf dem TWS
Die vollständige Schritt-für-Schritt-Anleitung habe ich im TWS-Forum dokumentiert – inklusive Named Volume, SSH-Container-Workflow und fertiger Container-Konfiguration.
TWS-spezifische Hinweise
Wer den allgemeinen Installations-Guide kennt, findet hier die Punkte, die auf dem TWS anders laufen als erwartet:
Image: python:3.11-alpine statt python:3.11-slim
Das im Repository vorgeschlagene Image python:3.11-slim läuft auf dem TWS nicht – es schlägt mit RuntimeError: can't start new thread fehl. Der TWS setzt ein systemweites Thread-Limit (ulimit), das die Debian-Basis anders handhabt als Alpine.
Lösung: python:3.11-alpine verwenden. Läuft problemlos.
STATS_INTERVAL=0 zwingend setzen
paho-mqtt versucht ohne diese Variable einen internen Stats-Thread zu starten – der auf dem TWS am systemweiten Thread-Limit scheitert. Mit STATS_INTERVAL=0 wird dieser Thread deaktiviert, und die Bridge läuft stabil.
Pfade explizit setzen
Da das Working Directory im Container nicht automatisch /app ist, müssen LOCAL_FILTER_PATH und LOCAL_WHITELIST_PATH explizit als Umgebungsvariablen angegeben werden. Sonst findet die Bridge ihre Konfigurationsdateien nicht und bricht beim Start ab.
Updates einspielen
Wer das Repository per git clone ins Volume gelegt hat, kann Updates einfach per SSH-Container einspielen:
cd /mnt/evcc-crowdscience-bridge && git pullDanach im Portainer den Bridge-Container neu starten (Restart) – fertig.
Fazit
Läuft. Seit heute Vormittag liefern wir die ersten Messwerte an die HTW – noch keine belastbare Langzeiterfahrung, allerdings ein guter Start.
Der Aufwand war überschaubar – wenn man die TWS-spezifischen Eigenheiten kennt. Die wichtigsten davon habe ich heute rausgearbeitet und hier und im Forum dokumentiert.
Ob die Daten wirklich nützlich sind? Ich denke schon. Die HTW Berlin betreibt seit Jahren seriöse Forschung zu Speichersystemen und Ladeinfrastruktur. Und irgendwoher müssen reale Feldmessdaten schließlich kommen.
Wer evcc betreibt und mitmachen möchte: evcc-crowdscience.de. Die Bridge-Anleitung für den TWS gibt es außerdem in meinem Forum-Beitrag auf forum.timberwolf.io.
Weiterführende Links:
