IDM Wärmepumpe, Fronius und SENEC: Warum das Energiemanagement nicht funktioniert und wie der Hack entstand
Dieses Repository dokumentiert ein sehr konkretes Problem, nach dem vermutlich viele frustriert suchen:
- IDM Wärmepumpe
- Fronius Wechselrichter
- SENEC Batterie
- kein Hybridwechselrichter
- SolarAPI
- Wärmepumpe bekommt keine Batterie- und Verbrauchsdaten
Wenn du eine ähnliche Kombination im Haus hast und dich wunderst, warum die Wärmepumpe zwar einen Fronius findet, aber trotzdem kein sinnvolles Energiemanagement macht, dann bist du hier richtig.
In meinem Haus wurden die falschen Komponenten zusammengebaut:
- Die Wärmepumpe (WP) ist von IDM
- Der Wechselrichter ist von Fronius
- Die Batterie ist von SENEC
Das Problem: Der eingebaute Fronius ist kein Hybridwechselrichter. Die SENEC-Batterie ist außerdem nicht passend integriert. Dadurch können die Geräte nicht so miteinander sprechen, wie die Wärmepumpe es für intelligentes Energiemanagement bräuchte.
Die Wärmepumpe war trotzdem auf „Fronius“ eingestellt. Sie hat also versucht, mit dem Wechselrichter über die Fronius SolarAPI zu reden. Dabei bekommt sie aber nur unvollständige Informationen zurück.
Genau deshalb entstand der Hack: Ein Hybridwechselrichter wird simuliert, damit der Wärmepumpe endlich die fehlenden Informationen bereitgestellt werden können.
Dieses Repository zeigt einen funktionierenden Hack für meinen ganz konkreten Aufbau. Es ist kein fertiges Produkt und erhebt keinen Anspruch auf Production Readiness.
Das ist wichtig, weil im Code an mehreren Stellen Dinge hart verdrahtet sind, zum Beispiel:
- IP-Adressen
- Geräteannahmen
- Antwortfelder
- feste Zuordnungen zwischen SENEC und Fronius
- bewusst vereinfachte Antworten für genau meinen Anwendungsfall
Deshalb sollte man dieses Repository so lesen:
- als Inspiration
- als Dokumentation eines funktionierenden Ansatzes
- als Startpunkt für einen eigenen Aufbau
Aber eben nicht als allgemeingültige, sofort produktionsreife Lösung für beliebige Anlagen.
Ein wichtiger Punkt bei meinem Aufbau war:
- Ich hatte niemals Administrator-Zugang zur Wärmepumpe
- Die Wärmepumpe stand bereits auf „Fronius“
- Ich wollte an der eigentlichen Anlage nichts direkt verändern
- Mein Ziel war, außen herum zu arbeiten, statt in die bestehende Konfiguration der WP einzugreifen
Das ist wichtig für das Verständnis des Hacks:
- Ich habe die Wärmepumpe nicht intern umprogrammiert
- Ich habe keine versteckten Service-Einstellungen benutzt
- Ich habe stattdessen versucht, der bereits auf Fronius eingestellten WP von außen genau die Antworten zu liefern, die sie erwartet
- Wärmepumpe:
192.168.178.61 - Fronius Wechselrichter (non-hybrid):
192.168.178.146
Um herauszufinden, was wirklich passiert, habe ich einen Rechner zwischen Wärmepumpe und Netzwerk gesetzt und den Traffic über mehrere Stunden mitgeschnitten.
So hätte das Energiemanagement eigentlich aussehen sollen:
So war es tatsächlich:
Der entscheidende Unterschied ist:
- Im Soll-Zustand ist der Wechselrichter die zentrale Stelle für PV, Batterie und Hausverbrauch
- Im Ist-Zustand liefert der non-hybrid Fronius diese Hybrid-Informationen nicht
Das erste wichtige Ergebnis aus dem Mitschnitt: Die Wärmepumpe sucht ihren Ansprechpartner nicht manuell, sondern über einen UDP-Broadcast im lokalen Netz.
Auf dem Screenshot sieht man, dass die Wärmepumpe (192.168.178.61) an 192.168.178.255:50052 sendet:
Die Bedeutung ist einfach:
- Die Wärmepumpe fragt im Netzwerk: „Wo ist hier ein Fronius Datamanager?“
- Der Broadcast dient also dazu, dass die WP ihren Fronius Ansprechpartner findet
Der Fronius-Wechselrichter (192.168.178.146) antwortet auf diesen Broadcast mit einer Datamanager-Antwort.
Damit ist klar:
- Die Wärmepumpe und der Wechselrichter finden sich
- Das Problem ist nicht die Netzwerkerkennung
- Das Problem beginnt danach, wenn es um die eigentlichen Daten geht
Sobald sich WP und Fronius gefunden haben, öffnet die Wärmepumpe eine normale TCP-Verbindung auf Port 80 und schickt HTTP-GET-Anfragen an die Fronius SolarAPI.
Das sieht man hier:
Als Protokollreferenz dient in diesem Repository die Datei:
Diese Fronius-Dokumentation bestätigt auch den wichtigen Grundsatz:
- SolarAPI V1 arbeitet über HTTP-GET
Um die eigentlichen Anfragen lesbar zu machen, kann man in Wireshark dem HTTP-Stream folgen:
Das Ergebnis dieses Schritts ist hier abgelegt:
Und als Screenshot:
Ich habe auch andere Streams angesehen. Das Ergebnis war immer gleich: Die Wärmepumpe schickt immer dieselben drei Abfragen, und zwar in dieser Reihenfolge:
GET /solar_api/v1/GetPowerFlowRealtimeData.fcgi?Scope=Device&DeviceId=0 HTTP/1.1
GET /solar_api/v1/GetStorageRealtimeData.cgi?Scope=Device&DeviceId=0 HTTP/1.1
GET /solar_api/v1/GetOhmPilotRealtimeData.cgi?Scope=Device&DeviceId=0 HTTP/1.1Das ist ein sehr wichtiger Befund für alle, die dieselbe Kombination debuggen:
- Die Wärmepumpe fragt nicht beliebige Fronius-Endpunkte ab
- Sie erwartet offenbar ganz gezielt Daten zu Power Flow, Speicher und OhmPilot
Die Fronius-Dokumentation ist hilfreich, aber für einen echten Hack ist ein reales Beispiel noch besser. Deshalb war ich zusätzlich bei einem Bekannten mit einem Fronius GEN24, also einem Hybridwechselrichter.
Dort habe ich die gleichen API-Endpunkte einfach direkt per Browser aufgerufen und die Antworten gespeichert:
Das ist wichtig, weil wir damit nicht nur die Theorie aus SolarAPI_v1.pdf haben, sondern auch eine echte Vorlage aus einem laufenden Hybrid-System.
Der Unterschied zum non-hybrid Fronius ist deutlich:
- Der GEN24 meldet bei
GetPowerFlowRealtimeDatanichtproduce-only, sondern:"Mode" : "bidirectional"
- Es gibt dort echte Werte für:
P_GridP_LoadP_AkkuP_PV
- Zusätzlich tauchen Hybrid-relevante Felder auf wie:
BatteryStandbyBackupModeSOCBattery_Mode
Mit anderen Worten:
- Der GEN24 liefert genau die Art von Informationen, die bei meinem echten Aufbau fehlen
- Genau diese Struktur brauchen wir später als Vorlage für den simulierten Hybridwechselrichter
Im echten GEN24-Beispiel sieht man unter anderem:
"Mode" : "bidirectional""Meter_Location" : "grid""P_Akku" : 0.0"P_Grid" : 696.8"P_Load" : -696.8"P_PV" : 0.0"BatteryStandby" : false"BackupMode" : false"Version" : "12"
Außerdem enthält der Bereich Inverters zusätzliche Hybrid-Informationen wie:
"Battery_Mode" : "suspended""SOC" : 36.0
Das ist genau der Unterschied zum non-hybrid Fronius:
- Beim echten Hybridwechselrichter gibt es Batterie- und Verbrauchsdaten
- Beim non-hybrid Fronius fehlen diese Daten oder sind
null
Auch die Speicherantwort ist auf dem GEN24 genau das, was man von einem Hybrid-System erwartet.
Dort kommen zum Beispiel:
Capacity_MaximumDesignedCapacityCurrent_DCVoltage_DCTemperature_CellStateOfCharge_RelativeStatus_BatteryCellDetails.ManufacturerDetails.Model
Im konkreten Beispiel ist die Batterie:
- Hersteller:
BYD - Modell:
BYD Battery-Box Premium HV
Damit haben wir eine sehr brauchbare Vorlage dafür, wie eine gültige Speicherantwort aussehen muss, wenn die Wärmepumpe einen Hybridwechselrichter vor sich haben soll.
Der Bekannte hat keinen OhmPilot. Die Antwort enthält deshalb:
"Code" : 12,
"Reason" : "OhmPilot '0' does not exist."Das ist in diesem Fall sogar hilfreich:
- Mein Bekannter hat keinen OhmPilot
- Ich habe auch keinen OhmPilot
- Für meinen Anwendungsfall ist diese Antwort also vollkommen passend
Wichtig ist nur:
- Auch auf einem echten GEN24 wird dieser Endpunkt sauber beantwortet
- Selbst wenn kein OhmPilot existiert, kommt eine plausible, gültige Antwort
Bis hierhin wussten wir:
- welche drei Endpunkte die Wärmepumpe abfragt
- dass mein echter non-hybrid Fronius dafür nicht die nötigen Daten liefert
Mit dem GEN24-Beispiel wissen wir jetzt zusätzlich:
- wie ein echter Hybridwechselrichter auf genau diese drei Abfragen antwortet
- welche Felder vorhanden sein müssen
- welche Struktur die JSON-Antworten haben
- welche Antwort auch ohne OhmPilot noch plausibel ist
Damit haben wir jetzt eine belastbare Vorlage für den nächsten Schritt:
Einen Fronius-Hybrid so zu simulieren, dass die IDM-Wärmepumpe genau die Antworten bekommt, die sie erwartet.
Die gute Nachricht ist: Die fehlenden Informationen waren in meinem Aufbau nicht komplett weg. Sie lagen nur nicht in der Form vor, die die IDM-Wärmepumpe von einem Fronius-Hybrid erwartet.
Aktuell liefert die SENEC-Batterie schon fast alles, was wir brauchen:
- Sie kennt den Netzbezug / die Netzeinspeisung
- Sie kennt ihre eigenen Batteriedaten
- Sie kennt den Ladezustand der Batterie
- Sie bekommt vom Fronius die PV-Leistung
Das eigentliche Problem ist also nicht fehlende Messung, sondern fehlende Übersetzung.
Sehr hilfreich ist dabei das GitHub-Projekt:
Mit pysenec lässt sich die SENEC-Batterie mit ihren Details auslesen. Dadurch wird der Hack konzeptionell viel einfacher:
Wir müssen nicht selbst alle Energiedaten neu erfinden. Wir müssen im Kern nur von SENEC nach Fronius GEN24 übersetzen.
Der Plan, der hier umgesetzt wird, sieht so aus:
In einfachen Worten:
- Der echte Fronius bleibt im System
- Die SENEC-Batterie bleibt ebenfalls im System
- Ein Laptop als Hack liest die verfügbaren Daten aus
- Dieser Laptop spricht zur Wärmepumpe so, als wäre er ein passender Fronius-Hybridwechselrichter
Damit wird aus dem Ist-Zustand kein kompletter Soll-Zustand mit neuer Hardware, aber ein funktionierender Zwischenschritt, den die Wärmepumpe versteht.
In meinem Fall ist dieser Hack-Rechner einfach ein sehr altes Laptop, das ich noch hatte. Das ist keine besondere Spezialhardware. Man könnte dafür zum Beispiel genauso gut auch einen Raspberry Pi (Raspi) verwenden, solange er dauerhaft im Netzwerk läuft und die beiden Aufgaben übernehmen kann.
In der Praxis habe ich den echten Fronius SYMO (non-hybrid) für diesen Aufbau offline genommen. Der Grund ist einfach:
- Die Wärmepumpe sucht per Broadcast nach einem Fronius
- Wenn mehrere Geräte auf diesen Broadcast antworten, kann das die WP verwirren
- Für den Hack soll deshalb nur der Fake Fronius auf diese Suche antworten
Außerdem ist wichtig:
- Der Fake Fronius ist erst dann wirklich „aktiv“, wenn beide Skripte gleichzeitig laufen
receive_UDP.pyübernimmt das Findenfake_fronius.pyübernimmt die SolarAPI-Antworten
Erst zusammen bilden sie aus Sicht der Wärmepumpe einen brauchbaren Fake Fronius.
Wenn die Wärmepumpe über den Hack die richtigen Informationen bekommt, werden die Daten sauber erkannt und in der IDM-Oberfläche auch korrekt dargestellt:
Das ist für mich ein sehr wichtiger Punkt:
- Die IDM-Wärmepumpe kann wunderbar regeln, sobald die Informationen richtig ankommen
- Man sieht hier, dass PV, Batterie, Netz und Verbrauch korrekt geliefert und erkannt werden
Deshalb gehört an dieser Stelle auch ein ausdrückliches Kompliment an IDM:
Sobald die Infos richtig kommen, regelt die Wärmepumpe wunderbar.
Mir ist wichtig, das fair zu sagen:
- Die einzelnen Komponenten funktionieren für sich betrachtet gut
- Die IDM-Wärmepumpe funktioniert gut
- Der Fronius-Wechselrichter funktioniert gut
- Die SENEC-Batterie funktioniert gut
Das Problem war in meinem Fall nicht, dass eines dieser Geräte grundsätzlich schlecht wäre.
Das Problem war das Zusammenspiel:
- Der Installateur hat nicht ausreichend beachtet, ob die konkret bestellten Komponenten im Energiemanagement wirklich sauber zusammenarbeiten
- Genau diese fehlende Abstimmung hat dazu geführt, dass die Wärmepumpe zwar einen Fronius findet, aber nicht die erwarteten Hybrid-Informationen bekommt
Die beiden zentralen Dateien in diesem Repository sind:
Sie passen sehr genau zu dem, was im Netzwerk-Mitschnitt zu sehen ist.
Dieses Skript bildet den ersten Schritt der Kommunikation nach:
- Die IDM-Wärmepumpe sendet einen UDP-Broadcast auf Port
50052 receive_UDP.pywartet genau auf diese Anfrage- Wenn die Anfrage passt, antwortet das Skript mit einer Datamanager-ähnlichen JSON-Antwort
Das ist genau die Rolle, die wir im Trace schon gesehen haben:
- Die Wärmepumpe sucht einen Fronius Datamanager
- Das Skript antwortet so, dass die Wärmepumpe einen passenden Ansprechpartner zu finden glaubt
Das RESPONSE-Objekt ist also keine Zufallszeichenkette, sondern eine nachgebildete Fronius-Erkennungsantwort.
Wichtig für das Verständnis:
- Die Form dieser Antwort stammt aus dem echten UDP-Mitschnitt
- Felder wie
DeviceFamily,Hardware,Id,Label,ModelundSoftwareorientieren sich direkt an der real beobachteten Datamanager-Antwort aus dem Trace
Dieses Skript bildet den zweiten Schritt nach:
- Nachdem die Wärmepumpe ihren „Fronius“ gefunden hat, ruft sie die drei bekannten SolarAPI-Endpunkte auf
fake_fronius.pystellt genau diese Endpunkte bereit:GetPowerFlowRealtimeData.fcgiGetStorageRealtimeData.cgiGetOhmPilotRealtimeData.cgi
Dabei macht das Skript genau das, was wir aus der bisherigen Analyse erwarten würden:
- Es liest Daten aus der SENEC-Batterie
- Es übersetzt diese Daten in eine Form, die wie ein Fronius GEN24 aussieht
- Es liefert für OhmPilot eine plausible Antwort vom Typ „gibt es nicht“, passend zu einem System ohne OhmPilot
Die Herkunft der Informationen ist damit sauber getrennt:
- Die Live-Werte kommen von der SENEC-Batterie
- Die Zielstruktur der JSON-Antworten kommt aus der Fronius SolarAPI-Doku und aus den echten GEN24-Beispielen
Anders gesagt:
receive_UDP.pysorgt dafür, dass die Wärmepumpe den Ansprechpartner findetfake_fronius.pysorgt dafür, dass sie danach die richtigen Antworten bekommt
Die Parallele zur bisherigen Doku ist klar sichtbar:
- Die Wärmepumpe fragt nach Power Flow
- Die Wärmepumpe fragt nach Storage
- Die Wärmepumpe fragt nach OhmPilot
Und genau dafür baut fake_fronius.py Antworten:
GetPowerFlowRealtimeData()liefert Fronius-artige Werte wie:Mode: "bidirectional"P_GridP_LoadP_AkkuP_PVrel_Autonomyrel_SelfConsumptionSOCBattery_Mode
GetStorageRealtimeData()liefert Fronius-/BYD-artige Speicherinformationen wie:Capacity_MaximumDesignedCapacityCurrent_DCVoltage_DCTemperature_CellStateOfCharge_RelativeStatus_BatteryCell
GetOhmPilotRealtimeData()liefert bewusst eine gültige Antwort mit Fehlercode 12, weil kein OhmPilot vorhanden ist
Genau das ist die praktische Übersetzung von SENEC nach Fronius GEN24.
In fake_fronius.py gibt es die Klasse Memorizer.
Die Idee dahinter ist schlicht:
- Die IDM-Wärmepumpe schickt pro Zyklus drei schnelle Abfragen direkt hintereinander
- Ohne Zwischenspeicher würde das dazu führen, dass auf diese drei IDM-Abfragen im schlimmsten Fall auch drei direkte Abfragen an die SENEC folgen
Der Memorizer speichert deshalb das letzte Ergebnis einfach kurz zwischen und verwendet es für die unmittelbar folgenden Antworten weiter.
Wichtig:
- Das ist nicht zwingend notwendig
- Es schadet aber auch nicht
- Es vermeidet vor allem unnötige Mehrfachabfragen derselben aktuellen Daten
Kurz gesagt:
Der
Memorizerist ein kleiner Puffer, damit aus 3 schnellen WP-Abfragen nicht sofort 3 fast identische SENEC-Abfragen werden.
Aus dem Netzwerk-Trace lässt sich außerdem erkennen:
- Die IDM-Wärmepumpe ruft ungefähr alle 5 Minuten neue Informationen ab
Das sieht man im Mitschnitt rund um den UDP-Broadcast und die danach folgende TCP/HTTP-Kommunikation:
Praktisch bedeutet das:
- Etwa alle 5 Minuten startet wieder ein neuer Such- und Abfragezyklus
- Innerhalb dieses Zyklus folgen dann wieder dieselben drei SolarAPI-Abfragen
Die Antworten erklären, warum das Energiemanagement scheitert.
Der Wechselrichter meldet:
"Mode" : "produce-only""P_Akku" : null"P_Grid" : null"P_Load" : null
Das bedeutet in normalen Worten:
- Der Fronius sagt im Grunde: „Ich bin nur PV-Erzeuger.“
- Er liefert keine brauchbaren Hybrid-Daten
- Es fehlen genau die Informationen, die für eine Wärmepumpe interessant wären:
- Hausverbrauch
- Netzbezug / Einspeisung
- Batterieleistung
- sinnvoller Batteriestatus
Hier kommt vom Fronius:
"Code" : 255,
"Reason" : "GetStorageRealtimeData request is not supported by this device."In Klartext:
- Der Wechselrichter sagt offen, dass dieser Speicher-Endpunkt auf diesem Gerät nicht unterstützt wird
Hier kommt:
"Code" : 12,
"Reason" : "DeviceId '0' does not exist"In Klartext:
- Die Wärmepumpe fragt nach einem Gerät oder Datentyp, den dieser Fronius gar nicht hat
Das Grundproblem ist also nicht:
- dass die Wärmepumpe den Fronius nicht findet
- oder dass HTTP nicht funktioniert
- oder dass die SolarAPI gar nicht benutzt wird
Das eigentliche Problem ist:
- Die Wärmepumpe findet erfolgreich einen Fronius
- Aber sie findet keinen Hybridwechselrichter
- Deshalb bekommt sie nicht die Daten, die sie für intelligentes Energiemanagement erwartet
Wenn die Wärmepumpe einen Fronius erwartet, der Informationen zu
- PV-Leistung
- Batteriestatus
- Batterie-Leistung
- Hausverbrauch
- Netzbezug / Einspeisung
bereitstellt, der echte Wechselrichter aber nur „produce-only“ liefert, dann bleibt nur ein logischer nächster Schritt:
Einen Hybridwechselrichter simulieren, der genau diese fehlenden Informationen bereitstellen kann.
Genau das ist die Idee hinter dem Hack, der in den nächsten Schritten dokumentiert wird.
Dieses Repository soll Menschen helfen, die mit Suchbegriffen wie diesen hier landen:
- IDM Wärmepumpe Fronius SENEC Problem
- Fronius produce-only Wärmepumpe
- IDM Wärmepumpe bekommt keine Batteriedaten
- Fronius SolarAPI GetPowerFlowRealtimeData GetStorageRealtimeData
- Wärmepumpe Hybridwechselrichter simulieren
Wenn du in genau so einer Situation bist: Du bist nicht verrückt. Die Geräte reden tatsächlich nicht so miteinander, wie man es bei einer sauber geplanten Hybrid-Lösung erwarten würde.