Growatt Thor mit eigenem OCPP-Server: Überschussladen, 0-A-Sperre und die Fallen der Firmware

10. November 2026 · 7 Min. Lesezeit · Auch auf English

Die Growatt Thor ist eine solide 11-kW-Wallbox mit eingebautem Solarmodus. Der hat mir aber nicht gereicht: Er brach Ladungen immer wieder mit SuspendedEVSE ab und kannte weder meinen Hausakku noch die genauen Werte meines Netzzählers. Deshalb steuert mein Energiemanagement JG Energy die Box seit Anfang 2026 komplett selbst – über einen eigenen OCPP-Server auf einem Raspberry Pi.

Hier beschreibe ich, wie das aufgebaut ist und welche Eigenheiten der Thor-Firmware ich unterwegs gefunden habe. Die meisten davon stehen in keiner Anleitung.

Der Aufbau

OCPP (Open Charge Point Protocol) ist eigentlich für Ladesäulen-Betreiber gedacht. Die Wallbox baut eine WebSocket-Verbindung zu einem Server auf und tauscht darüber JSON-Nachrichten aus. Dieser Server kann auch ein kleines Node.js-Programm im Heimnetz sein.

In der lokalen Weboberfläche der Thor trägt man als OCPP-Server die Adresse des Pi ein, z. B. ws://<pi-adresse>:9000/.
Der Server muss das Subprotokoll ocpp1.6 annehmen.
Die Thor meldet sich mit BootNotification, danach kommen laufend StatusNotification, MeterValues und Heartbeat.

Nach jedem Verbindungsaufbau schickt mein Server einmal eine Grundkonfiguration:

Schlüssel	Wert	Zweck
`MeterValueSampleInterval`	`5`	Messwerte alle 5 s (bei Ablehnung 10 s)
`ClockAlignedDataInterval`	`0`	nicht auf volle Uhrzeit warten
`AuthorizeRemoteTxRequests`	`false`	Fernstart ohne zusätzlichen Authorize-Schritt
`G_WebSocketPingInterval`	`30`	Verbindung stabil halten
`G_LCDCloseEnable`	`Enable` / `Disable`	Display aus / an

Zwei Dinge daran sind nicht offensichtlich: Für den WebSocket-Ping muss man den Growatt-eigenen Schlüssel G_WebSocketPingInterval verwenden – der Standardschlüssel aus OCPP führte bei mir zu Timeouts. Und G_LCDCloseEnable = Enable heißt „Display aus“. Ich schalte das Display damit automatisch ein, wenn ein Auto steckt, und sonst aus.

Die Überschussregelung

Die Thor bleibt fest im Modus „Schnell“ (G_SolarMode = 0). Die eigentliche Regelung läuft auf dem Pi:

Alle 15 Sekunden berechnet der Server den verfügbaren Überschuss aus dem Netzzähler (Shelly Pro 3EM), der aktuellen Wallbox-Leistung und dem Hausakku.
Davon zieht er einen Puffer von 350 W ab – lieber etwas einspeisen als Netzstrom laden.
Der Wert wird geglättet und in Ampere umgerechnet (6–16 A).
Ändert sich das Ziel um mindestens 1 A, setzt der Server G_MaxCurrent per ChangeConfiguration.

Einphasig laden mit einem Adapterkabel

Die Thor lädt dreiphasig, ihr Ladekabel ist fest angeschlagen, und auf eine Phase umschalten kann sie nicht. Weil sie mindestens 6 A braucht, beginnt das Überschussladen damit erst bei 6 A × 3 Phasen × 230 V, also gut 4,1 kW. Im Frühjahr, im Herbst und an wolkigen Tagen kommt dieser Überschuss oft gar nicht zusammen.

Mein Workaround ist ein kurzes Adapterkabel: auf der einen Seite eine Typ-2-Kupplung, in die der Stecker der Thor kommt, auf der anderen ein Typ-2-Stecker fürs Auto. Im Adapter ist nur eine Phase durchverbunden – L1, dazu N, PE und die Signalleitungen CP und PP. L2 und L3 enden im Adapter.

Die Wallbox merkt davon nichts und schaltet weiter alle drei Phasen. Das Auto bekommt aber nur Spannung auf L1 und lädt einphasig. Damit gibt es zwei getrennte Leistungsfenster, die sich nicht überlappen:

Kabel	Strom	Leistung
fest angeschlagen (3-phasig)	6–16 A	4,1–11 kW
mit Adapter (1-phasig)	6–16 A	1,4–3,7 kW

Einphasig fängt also schon schwachen Überschuss ab 1,4 kW auf, dreiphasig nimmt starken Überschuss bis 11 kW auf. Mit höchstens 3,7 kW bleibt die einphasige Ladung außerdem unter der Schieflastgrenze von 4,6 kVA, die in Deutschland für einphasige Verbraucher gilt.

Der Haken: Die Thor weiß nichts von dem Adapter. Die Regelung muss es also wissen, sonst rechnet sie Watt mit dem falschen Faktor in Ampere um. Steht sie auf drei Phasen und das Auto lädt nur auf einer, nutzt es nur ein Drittel des Überschusses. Im umgekehrten Fall zieht das Auto das Dreifache und damit Netzstrom.

Deshalb hat JG Energy eine Phaseneinstellung, die sich in der Oberfläche oder über einen Kippschalter an der Wallbox umstellen lässt. Und weil man das Umstellen leicht vergisst, prüft der Server während der Ladung die Ströme je Phase, die die Thor in ihren MeterValues mitschickt. Fließt Strom nur auf L1 oder auf allen drei, und passt das länger als eine Minute nicht zur Einstellung, erscheint ein Hinweis in der Oberfläche und kommt eine Telegram-Nachricht.

Welches Kabel sich gerade lohnt, zeigt die Wallbox-Seite ebenfalls: ein Rückblick auf die vergangenen Tage und eine Prognose aus den Einstrahlungsdaten von Open-Meteo, wie viel Sonnenstrom mit einem oder drei Phasen ins Auto gegangen wäre.

Pausieren, ohne die Ladung zu beenden

Reicht der Überschuss nicht mehr, könnte man die Ladung mit RemoteStopTransaction beenden. Dann zerfällt aber jeder wolkige Nachmittag in ein Dutzend Einzelvorgänge, und jeder Neustart braucht wieder einen Fernstart, auf den das Auto erst reagieren muss.

Besser ist ein Ladeprofil mit 0 A. Die Wallbox geht dann auf SuspendedEVSE, die Transaktion bleibt offen, und beim nächsten Sonnenfenster setzt ein neues Profil mit z. B. 8 A die Ladung fort.

Aber Vorsicht: Steht die Box zu lange auf 0 A, beendet die Thor die Transaktion manchmal selbst und meldet Preparing. Dann hilft kein Profil mehr, sondern nur noch ein neues RemoteStartTransaction. Der Regler muss beide Fälle kennen.

Falle 1: Free Vend lädt einfach los

Meine Thor ist auf Free Vend eingestellt: Auto einstecken, Ladung startet, ohne Karte. Das ist praktisch – aber im Überschussmodus unerwünscht. Wer abends einsteckt, will nicht, dass die Box sofort mit 11 kW Netzstrom lädt.

Erkennbar ist ein solcher Start am idTag freevenIdTag in der StartTransaction. Mein erster Ansatz: Jeden Start, den nicht der Server selbst ausgelöst hat, sofort auf 0 A begrenzen. Das funktioniert, aber das Schütz klackt trotzdem kurz.

Die bessere Lösung habe ich an der Anlage ausgemessen: Ein TxDefaultProfile mit Limit 0, das schon vor dem Einstecken in der Box liegt, verhindert, dass das Schütz überhaupt schließt. Die Thor piept nur.

{
  "connectorId": 1,
  "csChargingProfiles": {
    "chargingProfileId": 2,
    "stackLevel": 1,
    "chargingProfilePurpose": "TxDefaultProfile",
    "chargingProfileKind": "Absolute",
    "validFrom": "2026-11-11T10:00:00Z",
    "validTo": "2026-11-11T12:00:00Z",
    "chargingSchedule": {
      "chargingRateUnit": "A",
      "chargingSchedulePeriod": [{ "startPeriod": 0, "limit": 0, "numberPhases": 3 }]
    }
  }
}

Diese „Leerlauf-Sperre“ hat eine eigene Profil-ID (2) und liegt eine Stufe über dem Profil der Überschussregelung (ID 1, Stack 0). So kommen sich die beiden nicht in die Quere. Will der Server laden, löscht er gezielt Profil 2.

Falle 2: Was passiert, wenn der Server ausfällt?

Eine Sperre, die nur der Server wieder lösen kann, ist gefährlich. Fällt der Pi aus, bleibt die Wallbox gesperrt – und das Auto morgens leer.

Deshalb habe ich getestet, ob die Thor validTo auswertet. Ergebnis: ja. Nach Ablauf der Gültigkeit schaltet das Schütz beim Einstecken wieder normal.

Daraus wird ein Totmannschalter:

Die Sperre gilt jeweils 2 Stunden.
Der Server erneuert sie, sobald weniger als 45 Minuten übrig sind.
Stirbt der Server, verfällt die Sperre spätestens nach 2 Stunden, und Free Vend lädt wieder wie eine ganz normale Wallbox.
Wird der Server geordnet beendet (SIGTERM), löst er die Sperre sofort.

Dasselbe Prinzip gilt inzwischen auch für das Profil der Überschussregelung. Vorher konnte eine 0-A-Pause ohne Ablaufzeit in der Box stehen bleiben. Fiel dann der Pi aus, startete Free Vend zwar – aber mit 0 A.

Falle 3: ClearChargingProfile löscht mehr als gedacht

ClearChargingProfile mit nur connectorId löscht alle Profile – auch die Sperre. Mein Server ruft das z. B. nach jedem Neuverbinden auf, um alte Reste aufzuräumen. Danach muss die Sperre sofort neu gesetzt werden, sonst ist die Box bis zum nächsten Regelzyklus offen.

Die gute Nachricht: Die Thor kann ClearChargingProfile nach Profil-ID filtern. Zum gezielten Lösen der Sperre reicht { "id": 2 }.

Weitere Eigenheiten der Thor

GetCompositeSchedule wird abgelehnt (Rejected). Man kann also nicht abfragen, welches Limit gerade wirkt. Ob ein Profil greift, sieht man nur am Verhalten – oder hört es am Schütz.
Nicht zu schnell schreiben. Ich halte mindestens 3 Sekunden zwischen zwei Befehlen und 15 Sekunden zwischen zwei Stromänderungen ein. Schnellere Folgen haben die Box bei mir aus dem Tritt gebracht.
Doppelte Transaktionen. Bei träge reagierenden Autos öffnet die Thor auf ein einziges RemoteStartTransaction gelegentlich zwei Transaktionen kurz hintereinander. Ein zweiter Start innerhalb einer Minute wird bei mir als Dublette gewertet, sonst geht die Energie des ersten verloren.
„Auto voll“ ist nicht endgültig. Hat die Thor die Transaktion beendet, weil das Auto voll war, merkt sie nicht, wenn man später das Ladelimit im Auto erhöht. Mein Server versucht deshalb bei genug Überschuss alle 20 Minuten einen einzelnen Probestart.
Nach dem Neuverbinden Ruhe geben. Die ersten 20 Sekunden nach einem Reconnect schickt mein Server keine Regelbefehle.

Fazit

Mit einem eigenen OCPP-Server lässt sich die Thor sehr fein steuern – feiner als mit ihrem eingebauten Solarmodus. Der Aufwand steckt nicht im Protokoll, sondern in den Sonderfällen: Free Vend, Pausen, Neustarts und Ausfälle.

Mein wichtigster Grundsatz dabei: Jede Sperre, die der Server setzt, muss von selbst ablaufen. Dann ist der schlimmste Fall eines Ausfalls eine ganz normale Wallbox – und nicht ein leeres Auto.

Links

Open Charge Alliance – OCPP-Spezifikationen zum Herunterladen