PV Surplus Charging with EVCC - and a 6-Year-Old Wallbox

The PV system has been in operation for a few days now. The battery storage is running. What’s not running yet: the wallboxes. Two units are planned for the final expansion stage, both with automatic phase switching - but neither is installed yet.

However, there’s already one hanging on the wall: a go-e Charger Box, over six years old, in use every day since then. In all that time it’s done exactly one thing, and done it reliably - it puts electricity into the car. No charge management, no regulation, no questions asked. An outlet with a cable, just more expensive.

Now there’s photovoltaic power, and suddenly “charges” becomes “charges when and how much”. So the obvious question: Do I need to wait for the new wallboxes, or can I integrate the existing box into EVCC now - so that later I just swap out the hardware?

Short answer: it can be done. Slightly longer answer: after spending an evening figuring out a few things that nobody tells you. Because the box was always in operation, but nobody has ever actually talked to it. In the meantime, it does - and it’s charging PV-controlled.

The Setup at a Glance

Component	Role
Fronius Verto Plus 15 kW	PV and grid meter for EVCC
Fronius Reserva (15 kWh)	Home battery storage - and optional secondary source for charging
go-e Charger Box (HW V2)	Interim wallbox, fixed 3-phase, 22 kW hardware maximum
Tesla Model 3 Performance (Highland)	Currently the only vehicle, connected via Tesla Fleet API
EVCC	Independent Docker Compose stack on the homelab server
Home Assistant	Additional integration of the go-e box for monitoring

Act 1: Nobody Ever Asked the Box Before

The first step seemed straightforward: open the app, enable the API, done. But the current go-e app makes it unmistakably clear with a message that it doesn’t support this box, and directs you to the Classic App instead. At least it’s honest - no guessing games, no cryptic error messages. For old hardware, there’s the old app, and it does what it’s supposed to.

Then there’s the serial number. On the device is something like CM-02-XXXXXX, and I couldn’t figure out where to enter that. No field long enough, no error message that helped. Resolution: The app wants only the last six digits plus a password - not the full printed number.

The prefix turned out to be the most useful piece of information from the entire evening anyway. CM-02 stands for hardware generation V2 - and it can’t do automatic phase switching, unlike the newer V3 boxes. This matters later for the EVCC configuration, because it means charging is fixed at three-phase.

Next problem: The “Advanced Settings” were grayed out - and without them you can’t enable the API.

The reason is trivial, but stated nowhere: As long as your phone is connected to the normal home WiFi, the settings menu stays locked. You have to connect directly to the access point of the box itself. Once you’re on the charger’s WiFi, the settings are active.

After that, API v1 was active. The first test in the browser promptly gave a Not found: / - momentary panic, then the realization: the correct path is /status, not the root. So the thing had been working the whole time and was politely telling me I was knocking on the wrong door.

Act 2: Home Assistant Acts Up

Back to Home Assistant with a working API, installed the “go-e APIv2 Connect” integration there - and immediately got the error message “Host/IP is wrong”. But the IP was demonstrably correct; the browser had just retrieved JSON from exactly that address.

It was simply a version mismatch: the old box only speaks API v1, the chosen integration exclusively v2. The error message pointed in a direction where the problem didn’t even exist.

The right choice is the classic “go-eCharger” integration. That worked right away.

Act 3: EVCC Gets Its Own Stack

EVCC runs for me as a deliberate independent Docker Compose stack, not as another container in an existing setup. Accessible only internally, via the existing reverse proxy and Tailscale - charge management doesn’t need an open door to the internet.

I handed the actual setup task to Claude Code, with an explicit instruction beforehand: first inspect the existing server infrastructure, and ask for missing information rather than guessing. That’s become my standard approach for anything that touches a grown infrastructure.

Act 4: Why You Need the Tesla API at All

A quick interlude, because it’s not self-explanatory: why isn’t the wallbox alone enough?

Because the box knows surprisingly little. It knows whether electricity is flowing and how much. It doesn’t know which car is connected, how full the battery is, or how much charge it can still take. But EVCC needs exactly that information once it’s supposed to do more than just stubbornly set an amperage: read the charge level, plan charging goals, relate excess PV power to a concrete vehicle instead of regulating into thin air.

With the Tesla, this information comes via the Fleet API. Without it, EVCC is essentially a switch with an amperage setting. With it, it becomes charge management.

And then came the hurdle that had nothing to do with old hardware.

For the Fleet API, Tesla demands a permanently publicly accessible public key under its own domain. Not just for registration - permanently. An internal, VPN-only accessible setup doesn’t meet that.

That was the moment the project almost got a Cloudflare Tunnel and half an hour of domain tinkering. Until I remembered: I’ve had TeslaMate running on my VPS for a while. And TeslaMate has exactly this registration - domain, public key, client credentials - already handled.

So no new solution, but reuse of the existing one. Much faster, and one less construction site to maintain later.

Virtual key pairing on the vehicle and OAuth authorization in EVCC were mere formalities after that. Both are set up, the connection to the car is there.

Act 5: 14 Amps as a Test Balloon

On the hardware side, the old box is fixed three-phase and handles 32 A, so around 22 kW. In practice, that’s pure paper. In EVCC the max charging current is set to the default of 16 A, which is 11.0 kW - and the Tesla won’t accept more than that over AC anyway. The box isn’t the bottleneck here.

More interesting was the reverse direction: can the charging power actually be limited cleanly? As a test, I throttled maxcurrent to 14 A - not because it’s necessary now, but because I wanted to see if the limiting kicks in and the vehicle accepts it without complaint.

The background is future music, but foreseeable: with the grid charges reform and thresholds at monthly peaks, it becomes interesting to deliberately cap loads - especially when other household appliances hang in EVCC later and get in each other’s way. When I then start seriously regulating, I don’t want to find out whether the basic mechanism works. You test that kind of thing while nothing depends on it.

What All This Effort Is For: The Charging Modes

Up to here it sounds like a lot of small work for little effect. The difference appears only when you see what EVCC makes out of a connected box. Instead of “charges” or “doesn’t charge,” there are four operating modes:

• Off - charging doesn’t happen, period.
• Now - full power, regardless of where the power comes from. This is the mode for “I need to leave in an hour.”
• Min+PV - a guaranteed minimum power always runs, everything above that comes from surplus. The compromise for anyone who needs a certain amount of range by tomorrow morning but wants to grab as much sun as possible.
• PV - surplus only. If a cloud rolls in, EVCC throttles or pauses. The real reason you go through all this.

All three active modes are already running here: pure surplus charging, Min+PV, and full throttle from the grid. That’s exactly the test I wanted to see - not sometime with the new wallboxes, but now.

One limitation remains, though, and it’s not hardware-avoidable: the V2 box charges fixed three-phase. Switching between single and three-phase is technically simply not provided. EVCC makes the consequence helpfully clear - the phase selection is right next to the associated power ranges: three-phase is 4.1 to 11.0 kW, single-phase would be 1.4 to 3.7 kW.

So the difference isn’t at the top, it’s at the bottom. In pure PV mode, the lower limit decides whether charging happens at all: on a cloudy afternoon with 2 kW surplus, the box can’t do anything because it won’t even start below 4.1 kW. A phase-switching wallbox would capture exactly these hours and already start at 1.4 kW. For an interim setup, acceptable - but it’s the most concrete reason why the final expansion stage gets wallboxes with automatic phase switching.

Plus there’s the Fronius Reserva as home storage - and with it a question you first have to answer for yourself: should the car be allowed to charge from storage at all? Two batteries competing for the same solar power need a hierarchy. EVCC calls this Battery Boost and keeps it pleasantly simple: either disabled, or you set a limit up to which fast charging from the house battery is allowed.

For me, that’s disabled for now. The house battery is there to get the house through the night, not to fill a car that mostly just sits anyway. Once a second vehicle arrives, I’ll look at that again.

Quick Interlude: EVCC Is Open Source, But Not Free

That deserves mentioning fairly. EVCC is open source but funded via GitHub Sponsorships, and some functionality requires sponsor status. There are monthly tiers and a one-time lifetime option at 150 € - plus one at 180 € if you want an especially good conscience.

My unsolicited opinion: anyone who goes through all this effort wants to save money. And if you calculate what PV-optimized charging saves in grid consumption over the years, the one-time payment quickly stops being a serious discussion. A project you use daily is allowed to cost something.

Where It Stands Now

The over-six-year-old wallbox is charging the Tesla - just no longer blindly. Surplus charging runs, Min+PV runs, and when things need to go fast, it draws from the grid without question. From the outside, the box looks like it has every day for the past six years. The difference is entirely underneath.

Completed:

• go-e box: API v1 active, three-phase confirmed, integrated in Home Assistant
• EVCC stack set up and internally accessible
• Tesla Fleet API connection via existing TeslaMate registration
• Virtual key pairing on vehicle and OAuth authorization in EVCC complete
• Charging modes tested: PV surplus, Min+PV, and immediate charging from the grid

Still open:

• Reassess Battery Boost once a second vehicle arrives
• Switch to final wallboxes with automatic phase switching, second e-car, heat pump integration

Conclusion

Two insights and an afterthought.

First: Before replacing hardware, it’s worth looking at what it can already do. This box hung on the wall for six years and could have had an API the whole time - it just never needed anyone. You just need to know how to talk to it: right app, right WiFi, right API version, right path, right integration. None of these hurdles were genuine technical problems. They were all information problems.

Second, and this was the real surprise: the biggest hurdle came not from a six-year-old device, but from a policy. Not the box was the bottleneck, but Tesla’s requirement for permanent public accessibility of the public key. And the most elegant solution wasn’t building something new, but reusing something existing.

And third, because it pressed itself on me while writing: the effort bears no relation to the result - in the positive sense. One evening of tinkering, and a wallbox that could do only one thing for six years now hangs in an energy management system and charges with the sun. Eventually two wallboxes will hang there that can do what’s missing here: automatic phase switching, two charging points, no more Classic App archaeology. Then we’ll see whether this was a temporary solution or just an early start.