DynDaCo

Charging a car with whatever the house isn't using

Sector
EV charging and energy management
Period
2022–2023
Role
Architect and developer
Stack
.NET 6 · OCPP 1.6 · Blazor · DSMR / P1 · Modbus · MQTT · Apache Pulsar

Situation

A building has a fixed electrical connection — say forty amps. An EV charge point would happily draw thirty-two of them. Run the oven, the heat pump and the washing machine at the same time and the main fuse goes, in the dark, on a Sunday.

The usual fix is to permanently cap the charger at whatever is safe in the worst case. It works, and it means the car charges slowly all the time to protect against a situation that occurs for twenty minutes a day. If there are solar panels on the roof the waste is sharper still: power is exported to the grid for a few cents while the car charges on electricity bought back at full price.

Doing better needs two things most charge points don't have on their own: knowing what the rest of the building is drawing right now, and being able to change the charging current continuously rather than once at installation.

What I built

A controller sitting between the building's meter and its charge points, doing both.

It reads the meter directly. Belgian and Dutch digital meters expose a serial port that streams consumption several times a minute. The controller parses that feed for actual per-phase voltage, current and power, and reads Modbus meters where the smart meter isn't available or a sub-circuit needs its own measurement. Import and export are tracked separately, across day and night tariffs, so the picture is what the building is actually doing rather than a monthly average.

It speaks the charge points' own language. The controller is an OCPP central system: charge points connect to it and it handles the full conversation — boot and heartbeat, authorising who may charge, starting and stopping transactions, meter readings, status, remote start and stop, reset. Any compliant charge point works; nothing is tied to one manufacturer.

It adjusts the current continuously. Spare capacity is the connection limit minus what everything else is drawing, computed per phase because a three-phase connection can be loaded unevenly and it is the worst phase that blows the fuse. That figure is pushed to the charge point as an OCPP charging profile and revised as the building's load changes. The car gets the maximum that is safe at each moment instead of a cautious constant, and with solar generating, the surplus goes into the car rather than back to the grid.

It can be worked on without a car. Charge point simulators speaking the protocol let the whole system be exercised end to end at a desk. Anyone who has debugged against real charging hardware understands why that mattered: the alternative is a developer, a vehicle and a parking space per test.

A browser interface shows live state per charge point and per phase, with messaging underneath to carry measurements and events between the parts.

Outcome

Charging happens at whatever rate the building can actually spare, updated continuously, and the fuse stays in. The behaviour that used to require an electrician's worst-case guess became a measurement.

This is the same shape as the industrial work, at domestic scale: read the real signal from the equipment, decide from it, and write the decision back over the equipment's own protocol. The domain was new to me; the problem was not.

← All work