浪人
DE|EN
PV-Überschussladen mit EVCC - und einer 6 Jahre alten Wallbox
tech

PV-Überschussladen mit EVCC - und einer 6 Jahre alten Wallbox

Zurück zum Blog
9 Min. Lesezeit

PV-Überschussladen mit EVCC - und einer 6 Jahre alten Wallbox

Die PV-Anlage ist seit ein paar Tagen in Betrieb. Der Speicher läuft. Was noch nicht läuft: die Wallboxen. Zwei Stück sind für die Endausbaustufe eingeplant, beide mit automatischer Phasenumschaltung - aber verbaut ist noch keine davon.

An der Wand hängt allerdings längst eine: eine go-e Charger Box, über sechs Jahre alt, seither jeden Tag im Einsatz. Sie hat in dieser Zeit exakt eine Sache gemacht, und die zuverlässig - Strom ins Auto. Kein Lademanagement, keine Regelung, keine Fragen. Steckdose mit Kabel, nur teurer.

Jetzt gibt es Photovoltaik, und damit wird aus „lädt“ plötzlich „lädt wann und wie viel“. Naheliegende Frage also: Muss ich auf die neuen Wallboxen warten, oder lässt sich die vorhandene Box schon jetzt in EVCC einbinden - so, dass später nur noch die Hardware getauscht wird?

Kurze Antwort: Sie lässt sich. Etwas längere Antwort: nachdem man an einem Abend ein paar Dinge herausgefunden hat, die einem niemand sagt. Denn die Box war zwar immer in Betrieb, aber noch nie hat jemand mit ihr geredet. Inzwischen tut sie es - und lädt PV-geführt.

Das Setup auf einen Blick

Komponente Rolle
Fronius Verto Plus 15 kW PV- und Netz-Meter für EVCC
Fronius Reserva (15 kWh) Hausspeicher - und optionale zweite Quelle fürs Laden
go-e Charger Box (HW V2) Übergangs-Wallbox, fix 3-phasig, 22 kW Hardware-Maximum
Tesla Model 3 Performance (Highland) Aktuell das einzige Fahrzeug, Anbindung über die Tesla Fleet API
EVCC Eigenständiger Docker-Compose-Stack am Homelab-Server
Home Assistant Zusätzliche Anbindung der go-e-Box zur Beobachtung

Akt 1: Die Box hat noch nie jemand gefragt

Der erste Schritt war unspektakulär gedacht: App auf, API einschalten, fertig. Die aktuelle go-e-App sagt allerdings unmissverständlich per Meldung, dass sie diese Box nicht unterstützt, und verweist auf die Classic App. Immerhin ehrlich - kein Rätselraten, keine kryptische Fehlermeldung. Für alte Hardware gibt es die alte App, und die tut, was sie soll.

Dann die Seriennummer. Auf dem Gerät steht etwas in der Form CM-02-XXXXXX, und genau das ließ sich nirgends eintippen. Kein Feld, das lang genug war, keine Fehlermeldung, die weitergeholfen hätte. Auflösung: Die App will nur die letzten sechs Ziffern plus ein Passwort - nicht die volle aufgedruckte Nummer.

Der Präfix war trotzdem die nützlichste Information des ganzen Abends. CM-02 steht für die Hardware-Generation V2 - und die kann keine automatische Phasenumschaltung, im Gegensatz zu den neueren V3-Boxen. Das ist später für die EVCC-Konfiguration relevant, weil damit fix dreiphasig geladen wird.

Die Classic App findet die alte Box

Nächstes Problem: Die „Erweiterten Einstellungen“ waren ausgegraut - und ohne die kommt man nicht an die API-Aktivierung.

Der Grund ist banal, steht aber nirgends: Solange das Handy im normalen Heim-WLAN hängt, bleibt das Einstellungsmenü gesperrt. Man muss sich direkt mit dem Access Point der Box selbst verbinden. Sobald man im WLAN des Chargers ist, sind die Einstellungen aktiv.

Danach war die API v1 aktiv. Der erste Test im Browser lieferte prompt ein Not found: / - kurzer Schreckmoment, dann die Erkenntnis: Der richtige Pfad ist /status, nicht die Wurzel. Das Ding hatte also die ganze Zeit funktioniert und mir nur höflich mitgeteilt, dass ich an der falschen Tür klopfe.

Statusabfrage der go-e API

Akt 2: Home Assistant zickt

Mit funktionierender API zurück nach Home Assistant, dort die Integration „go-e APIv2 Connect“ installiert - und sofort die Fehlermeldung „Host/IP is wrong“. Die IP war aber nachweislich richtig, der Browser hatte gerade eben noch JSON von genau dieser Adresse geliefert.

Es war schlicht ein Versions-Mismatch: Die alte Box spricht nur API v1, die gewählte Integration ausschließlich v2. Die Fehlermeldung zeigt in eine Richtung, in der das Problem gar nicht liegt.

Richtige Wahl ist die klassische „go-eCharger“-Integration. Damit lief es auf Anhieb.

Fehlermeldung in Home Assistant

Akt 3: EVCC bekommt einen eigenen Stack

EVCC läuft bei mir bewusst als eigenständiger Docker-Compose-Stack und nicht als weiterer Container in einem bestehenden Setup. Erreichbar nur intern, über den vorhandenen Reverse Proxy und Tailscale - eine Ladesteuerung braucht kein offenes Tor ins Internet.

Den eigentlichen Setup-Auftrag habe ich an Claude Code übergeben, mit einer expliziten Anweisung vorneweg: erst die bestehende Server-Infrastruktur inspizieren, und bei fehlenden Informationen nachfragen statt raten. Das ist inzwischen mein Standard-Vorgehen bei allem, was in eine gewachsene Umgebung eingreift.

Akt 4: Wozu man die Tesla-API überhaupt braucht

Kurzer Zwischenschritt, weil das nicht selbsterklärend ist: Warum reicht die Wallbox allein nicht?

Weil die Box erstaunlich wenig weiß. Sie weiß, ob Strom fließt und wie viel. Sie weiß nicht, welches Auto dranhängt, wie voll der Akku gerade ist und wie viel überhaupt noch reingeht. Genau das braucht EVCC aber, sobald es mehr tun soll als stur eine Stromstärke einzustellen: Ladestand auslesen, Ladeziele planen, überschüssige PV-Leistung auf ein konkretes Fahrzeug beziehen statt ins Blaue zu regeln.

Beim Tesla kommen diese Informationen über die Fleet API. Ohne sie ist EVCC im Wesentlichen ein Schalter mit Amperezahl. Mit ihr wird daraus ein Lademanagement.

Und dann kam die Hürde, die nichts mit alter Hardware zu tun hatte.

Für die Fleet API verlangt Tesla einen dauerhaft öffentlich erreichbaren Public Key unter einer eigenen Domain. Nicht einmalig zur Registrierung - dauerhaft. Ein rein internes, VPN-only erreichbares Setup erfüllt das nicht.

Das war der Moment, in dem das Projekt beinahe einen Cloudflare Tunnel und eine halbe Stunde Domain-Bastelei bekommen hätte. Bis mir eingefallen ist: Auf meinem VPS läuft seit Längerem TeslaMate. Und TeslaMate hat genau diese Registrierung - Domain, Public Key, Client Credentials - längst erledigt.

Also keine neue Lösung, sondern Zweitverwertung der bestehenden. Deutlich schneller, und eine Baustelle weniger, die man später pflegen muss.

Virtual-Key-Pairing am Fahrzeug und die OAuth-Autorisierung in EVCC waren danach nur noch Formsache. Beides steht, die Verbindung zum Auto ist da.

Akt 5: 14 Ampere als Testballon

Hardware-seitig ist die alte Box fix dreiphasig verdrahtet und schafft 32 A, also rund 22 kW. Praktisch ist das eine reine Papierzahl. In EVCC steht der Max-Ladestrom auf den Standardwert von 16 A, also 11,0 kW - und mehr nimmt der Tesla über AC ohnehin nicht an. Die Box ist an dieser Stelle nicht das Nadelöhr.

Interessanter war für mich die Gegenrichtung: Lässt sich die Ladeleistung überhaupt sauber begrenzen? Testweise habe ich maxcurrent auf 14 A gedrosselt - nicht, weil es jetzt schon nötig wäre, sondern weil ich sehen wollte, ob die Limitierung greift und das Fahrzeug sie klaglos mitmacht.

Der Hintergrund ist Zukunftsmusik, aber absehbare: Mit der Netzentgelt-Reform und den Schwellen bei den Monatsspitzen wird es interessant, Lasten gezielt zu deckeln - erst recht, wenn später weitere Hausgeräte in EVCC hängen und sich gegenseitig ins Gehege kommen. Wenn ich dann anfange, ernsthaft zu regeln, will ich nicht erst herausfinden müssen, ob die Grundmechanik überhaupt funktioniert. Solche Dinge testet man besser, solange nichts davon abhängt.

Wofür der ganze Aufwand: die Lademodi

Bis hierhin klingt das nach viel Kleinarbeit für wenig Effekt. Der Unterschied zeigt sich erst, wenn man sieht, was EVCC aus einer angebundenen Box macht. Statt „lädt“ oder „lädt nicht“ gibt es vier Betriebsarten:

  • Aus - es wird nicht geladen, Punkt.
  • Sofort - volle Leistung, egal woher der Strom kommt. Das ist der Modus für „ich muss in einer Stunde weg“.
  • Min+PV - eine garantierte Mindestleistung läuft immer, alles darüber kommt aus dem Überschuss. Der Kompromiss für alle, die morgen früh eine gewisse Reichweite brauchen, aber gern so viel Sonne wie möglich mitnehmen.
  • PV - nur Überschuss. Zieht eine Wolke auf, drosselt oder pausiert EVCC. Der eigentliche Grund, warum man sich das alles antut.

Alle drei aktiven Modi laufen hier bereits: reines Überschussladen, Min+PV, und Vollgas aus dem Netz. Genau das war der Test, den ich sehen wollte - nicht irgendwann mit den neuen Wallboxen, sondern jetzt.

Eine Einschränkung bleibt allerdings, und die ist hardwareseitig nicht zu umgehen: Die V2-Box lädt fix dreiphasig. Ein Umschalten zwischen ein- und dreiphasig ist technisch schlicht nicht vorgesehen. EVCC macht die Folge davon dankenswert deutlich sichtbar - die Auswahl der Phasenzahl steht direkt neben den zugehörigen Leistungsbereichen: dreiphasig sind es 4,1 bis 11,0 kW, einphasig wären es 1,4 bis 3,7 kW.

Ladepunkt-Einstellungen in EVCC

Der Unterschied liegt also nicht oben, sondern unten. Im reinen PV-Modus entscheidet die Untergrenze darüber, ob überhaupt geladen wird: An einem trüben Nachmittag mit 2 kW Überschuss kann die Box nichts anfangen, weil sie unter 4,1 kW gar nicht erst anfängt. Eine phasenumschaltende Wallbox würde genau diese Stunden noch mitnehmen und schon ab 1,4 kW loslegen. Für ein Übergangs-Setup verschmerzbar - aber es ist der konkreteste Grund, warum in der Endausbaustufe Wallboxen mit automatischer Phasenumschaltung kommen.

Dazu kommt der Fronius Reserva als Hausspeicher - und damit eine Frage, die man erst mal für sich beantworten muss: Soll das Auto überhaupt aus dem Speicher laden dürfen? Zwei Akkus, die um denselben Sonnenstrom konkurrieren, brauchen eine Rangordnung. EVCC nennt das Batterie Boost und hält es angenehm simpel: entweder deaktiviert, oder man wählt ein Limit, bis zu dem Schnellladen aus der Hausbatterie erlaubt ist.

Bei mir steht das vorerst auf deaktiviert. Der Hausspeicher ist dafür da, das Haus über die Nacht zu bringen, nicht dafür, ein Auto zu füllen, das ohnehin die meiste Zeit steht. Sobald ein zweites Fahrzeug dazukommt, schaue ich mir das nochmal an.

Kurzer Einschub: EVCC ist Open Source, aber nicht gratis

Das gehört fairerweise dazu. EVCC ist quelloffen, finanziert sich aber über GitHub Sponsorships, und ein Teil der Funktionalität setzt einen Sponsoren-Status voraus. Es gibt monatliche Stufen und eine einmalige Lifetime-Variante um 150 € - sowie eine um 180 €, wenn man ein besonders gutes Gewissen haben möchte.

Meine Meinung dazu, unaufgefordert: Wer sich die Mühe macht, das alles aufzusetzen, will damit Geld sparen. Und wenn man dagegenrechnet, was PV-optimiertes Laden über die Jahre an Netzbezug vermeidet, ist die einmalige Zahlung ziemlich schnell keine ernsthafte Diskussion mehr. Ein Projekt, das man täglich nutzt, darf etwas kosten.

Wo es jetzt steht

Die über sechs Jahre alte Wallbox lädt den Tesla - nur eben nicht mehr blind. Überschussladen läuft, Min+PV läuft, und wenn es schnell gehen muss, zieht sie ohne Diskussion aus dem Netz. Von außen sieht die Box aus wie an jedem Tag der letzten sechs Jahre. Der Unterschied liegt komplett darunter.

EVCC im PV-Modus

Erledigt:

  • go-e-Box: API v1 aktiv, dreiphasig bestätigt, in Home Assistant eingebunden
  • EVCC-Stack aufgesetzt und intern erreichbar
  • Tesla-Fleet-API-Anbindung über die bestehende TeslaMate-Registrierung
  • Virtual-Key-Pairing am Fahrzeug und OAuth-Autorisierung in EVCC abgeschlossen
  • Lademodi getestet: PV-Überschuss, Min+PV und Sofortladen aus dem Netz

Noch offen:

  • Batterie Boost neu bewerten, sobald ein zweites Fahrzeug dazukommt
  • Umstieg auf die finalen Wallboxen mit automatischer Phasenumschaltung, zweites E-Auto, Wärmepumpen-Integration

Fazit

Zwei Erkenntnisse und ein Nachsatz.

Erstens: Bevor man Hardware ersetzt, lohnt der Blick, was sie eigentlich schon kann. Diese Box hing sechs Jahre an der Wand und hätte die ganze Zeit über eine API gehabt - gebraucht hat sie nur nie jemand. Man muss lediglich wissen, wie man sie anspricht: richtige App, richtiges WLAN, richtige API-Version, richtiger Pfad, richtige Integration. Keine dieser Hürden war ein echtes technisches Problem. Es waren durchwegs Informationsprobleme.

Zweitens, und das war die eigentliche Überraschung: Die größte Hürde kam nicht von einem sechs Jahre alten Gerät, sondern von einer Policy. Nicht die Box war das Nadelöhr, sondern Teslas Anforderung an die dauerhafte öffentliche Erreichbarkeit des Public Keys. Und die eleganteste Lösung war nicht, etwas Neues zu bauen, sondern etwas Bestehendes weiterzuverwenden.

Und drittens, weil es sich beim Schreiben aufgedrängt hat: Der Aufwand steht in keinem Verhältnis zum Ergebnis - im positiven Sinn. Ein Abend Fummelei, und eine Wallbox, die sechs Jahre lang nur eine Sache konnte, hängt jetzt in einem Energiemanagement und lädt mit Sonne. Irgendwann hängen dort zwei Wallboxen, die das können, was dieser hier fehlt: automatische Phasenumschaltung, zwei Ladepunkte, keine Classic-App-Archäologie mehr. Dann zeigt sich, ob das hier eine Übergangslösung war oder einfach ein früher Anfang.