The day my EV charger quietly got slower

The symptom

Single-phase domestic install, underground garage, Tesla Model 3, overnight charge pinned at 32 A with no solar modulation and no limit set on the car. The charger starts at 32.6 A and heats steadily. When line temperature reaches 79 °C it waits 105 seconds, applies a single 2.1 A cut, and then holds there for the rest of the session.

Three properties worth writing down, because they shape how you detect this at all:

• The threshold is 79 °C with about 105 seconds of persistence. It is not an instantaneous comparator — a night that touches the threshold without holding it never triggers a cut. That single fact explained several nights I had previously filed as inconsistent.
• The cut is discrete and one-shot: −2.1 A, −523 W, in a single sample. Temperature responds within a minute and the system settles into equilibrium around 76 °C.
• Configuration never moves. max_charging_current and max_avbl_current sit at 32 A throughout, the cut included.

Dating the change

My recollection was “it worked fine at first, then one day it started, and it stayed that way”. Recollection is not evidence, so: the charger keeps a session table going back two full years, which is far more history than the live telemetry buffer holds. Mean power per session is a crude metric — it folds in the car's own taper at high state of charge — but it is perfectly valid for comparing equivalent sessions against each other.

A 10 % drop, then fifteen months of dead flat. That shape matters more than the magnitude: contact resistance creeping up from thermal cycling would give you a gradual slide. A step that lands and then holds for over a year is a parameter change, not a wearing part.

What the charger logged in that window

The error table is the only one on the device with usable timestamps going that far back. Between the last good session and the first bad one, it contains exactly four entries — each one a simultaneous restart of every service on the box.

A double restart cycle inside one minute, with a driver event wedged between them, is what a remotely applied firmware update looks like from the inside.

My working theory is that the threshold was deliberately lowered for safety — the kind of change a manufacturer ships quietly when field data starts showing units running hotter than they would like. It fits the shape of the evidence better than any failure mode I can think of, and it has an uncomfortable implication: if that is what happened, there is nothing to repair. The unit is doing exactly what it was told to do.

What it isn't

Each of these was a live hypothesis at some point, and each one cost measurements to kill. Recording the dead ends is the whole point of a field note.

• Not ambient temperature. In April, with the garage around 15 °C, the unit still reached 81—83 °C. In September, at 28.5 °C ambient, it reaches 79 °C. The device's own rise of +50 to +60 °C over ambient at 32 A dominates completely. This one genuinely surprised me — I had assumed summer was the trigger.
• Not a limit from the car. charge_current_request and charge_current_request_max both read 30 A: the vehicle is asking for precisely what the charger offers on the control pilot, with no limit of its own.
• Not a stale control pilot. This one is subtle and worth the warning. A car that cached an old pilot value looks similar — current below the configured maximum — but the signature is inverted: with a stale pilot, current rises while temperature rises. Here the cut tracks temperature. Same symptom, opposite cause, and the fix for one is useless against the other.
• Not in the error log. The device's error table contains no over-temperature code anywhere in its entire life.

What it costs

Sessions since

136

Energy delivered

3003 kWh

Hours charging

635

Time overhead

~58 h

Those 58 hours are the difference between delivering that energy at the old level and at the current one. On a typical night it is around 30 minutes — annoying, not painful. The real cost sits in the tail: on the worst night on record the cut went all the way down to 18.3 A, which turns a full charge into an all-day affair.

How to check yours

None of this is visible from the vendor app or the cloud API, so all of it came from the device itself. The Pulsar Plus runs embedded Linux and there is excellent prior work on getting a root shell and on getting its state out over MQTT. If you want to run the same measurements on your own unit, start here — credit where it is due, I wrote neither of these:

With a shell, the interesting state lives in a local MySQL database called wallbox. Two tables carry everything used in this write-up:

-- live telemetry: temp_l1, ac_current_rms_l1, max_charging_current...
-- circular buffer, 25k rows, roughly 2.5 months
SELECT timestamp, temp_l1, ac_current_rms_l1, max_charging_current
FROM state_values ORDER BY timestamp DESC LIMIT 50;

-- session history: this one goes back years
SELECT DATE(start_time)              AS day,
       ROUND(energy/1000, 1)         AS kwh,
       ROUND(charging_time/60)       AS minutes,
       ROUND(energy*3.6/charging_time, 2) AS mean_kw
FROM session
WHERE HOUR(start_time) IN (23, 0)   -- overnight sessions only
  AND charging_time > 7200          -- longer than two hours
  AND energy > 15000
ORDER BY start_time;

On the MQTT side the topics you want are wallbox_<serial>/temp_l1/state and wallbox_<serial>/charging_current_l1/state. Log both at a few seconds' resolution through a full session and the staircase draws itself. If you also run the car through TeslaMate, cross-reference charge_current_request_max from MQTT rather than the charger_pilot_current column in Postgres — the latter reported 16 A against 30 A of measured current on my car, which is physically impossible and cost me another wrong turn.

Where this stands

Unresolved, honestly. The threshold is characterised, the change is dated to a four-month window, and the mechanism behind that window is still inference. Two things are queued.

The first is boring and will probably work: forced convection. A 120 mm fan, a smart relay, a 3D-printed bracket, and an automation that spins it up above 60 °C while charging. If the unit never reaches 79 °C it never cuts, whatever threshold the firmware is carrying. I have run a couple of sessions with the lid physically open and they still hit the threshold, which is suggestive but nowhere near enough nights to call passive convection dead — moving air is a different physical regime anyway, and that is the one worth testing properly.

The second is to ask the vendor for the firmware history on the unit and see whether that window matches a deployment. Whichever way that answer goes, the interesting part is already done: the device recorded its own regression, in two separate tables, and kept it for two years. It was sitting there the whole time, behind a mismatched timestamp format and a config field that never moves.

Once the fan is in, the test is simple and the data already exists to compare against: line current holding 32.6 A for a whole session, instead of stepping down at minute twenty-three.