Two days ago, I walked into the garage to a completely dead Tesla. Not “won’t drive” dead – properly dead: black screen, no response from the door handles, not even the Bluetooth advertisement a sleeping Tesla always emits. It had been a perfectly normal car the evening before, parked and plugged into the Wattpilot as usual.
Getting into a dead Model 3 is a small adventure of its own. Behind the tow eye cover there are two leads for exactly this situation – 12V from a bench supply pops the frunk, and from there you can reach the 16V Li-ion low-voltage battery and bring the computers up properly. The car booted into a wall of red: “High voltage fuse A blown”, speed limited, gateway locked. Service Mode showed DTC P0A9501 with the pyro disconnect flagged red and a squib resistance of 5.744 ohms.
The pyro disconnect is a one-shot explosive fuse inside the battery pack, there to sever the high voltage circuit in a crash. Mine had not fired – more on that below – but the car believed the fuse might not fire when needed, and that turns out to be enough for it to shut everything down.
The repair itself was undramatic: the car still charged and drove, so it made the 400 km trip to the Bucharest service center on its own wheels (DC fast charging at 121 kW along the way), where they replaced the high voltage controller and the pyro disconnect under warranty. Alert gone, case closed. Except my first theory was a power surge from the grid – the car lives on a charger wired into my PV and battery system, and if something upstream killed it I’d quite like to know before it kills something else.
Three witnesses
This is where logging everything pays off. I had three independent records of that night: the Home Assistant recorder (grid, PV, battery and charger data), TeslaMate polling the car over the cloud API, and an ESP32 running the Tesla BLE proxy a few meters from the car. The BLE proxy turned out to be the star witness – a sleeping Tesla still advertises over Bluetooth (that is how the phone key works), so the proxy hears the car even when the cloud API shows nothing at all.
The reconstructed timeline, all times local:
- 18:55 – charge session ends normally at 67%. 6 A single phase, gentle taper, nothing unusual.
- 19:04–19:30 – the charge port latch spontaneously cycles disengaged/engaged three times and the gear selector briefly reads “Invalid”. Parked, plugged in, nobody in the car. In hindsight, the first symptom.
- 19:38 – the car goes to sleep, like every night.
- 20:55:01 – the BLE advertisement vanishes. The moment of death, to the second.
- overnight – the recorder shows a completely quiet grid: no outage, no sag, voltage inside 237–255 V, frequency flat at 50 Hz. Whatever killed the car, it was not the grid.
- next morning – the car misses every one of its usual wake-ups. TeslaMate shows one unbroken 16-hour offline gap.
- 13:34 – my 12V jump; BLE flickers back to life and the fault re-stamps itself in the log.
Shut down by policy
The DTC text explains the death mechanism better than I could. Set condition: “The BMS detects a low resistance value in the high voltage fuse A squib.” Potential impact: “Vehicle is unable to start, drive, charge or support the low voltage system.”
The BMS continuously measures the resistance of the squib – the pyro fuse’s ignition element – because a fuse that cannot fire is a safety device that does not exist. Healthy is roughly 1.0 to 5.0 ohms; mine read 5.744, just past the “open/defective” threshold. The BMS cannot tell a drifted measurement from a genuinely compromised fuse, so it assumes the worst and locks everything down, including the DC-DC converter that keeps the 16V battery topped up. A 16V battery alone lasts a couple of hours. The car did not die of anything; it was shut down by policy, on the word of one small analog measurement.
That the fuse itself was fine is visible right there in Service Mode: pack contactors closed, 381 V on the DC link, and of course the 400 km drive to service. A genuinely fired pyro fuse means a flatbed.
The collateral damage
Two more things broke that week, and neither was obvious until I looked at the data.
First, the Wattpilot. Three minutes after the jump-started car came back online, the charger’s local API froze mid-thought – its last reported state was “ChargingBecauseDischargingPvBattery”, the mode where it feeds the car from the home battery. The charging hardware kept working, the brain was gone until a factory reset two days later.
Second, and this one genuinely surprised me: my house exported 1.6 kWh to the grid in 23 minutes, against a zero feed-in limit. When the revived car finished charging, nobody told the inverter. It was still executing “discharge the home battery to help charge the car” on the wedged charger’s stale say-so, so the BYD kept pushing about 1.7 kW into a house drawing barely one, with the PV running uncurtailed on top. It stopped only when the pack hit the assist mode’s internal floor at exactly 48.2%. For scale: a normal day here exports maybe 0.2 kWh total.
I checked the Modbus storage-control registers my own automations write – caps only, never a forced discharge. The command came from inside the Fronius ecosystem, faithfully executing the last order of a dead charger. I considered working around it charger-side with scheduled restarts, but the actual hole is that the inverter obeys a commander that has stopped talking. So there is now a watchdog automation in Home Assistant: battery discharging to grid with no consumer for three minutes straight – reset the storage registers, verify, notify.
One embarrassing footnote for honesty’s sake: I also restarted the GEN24 inverter during the rescue, which planted a fake 36-second “grid outage” in my own logs and muddied the crime scene for a while. The grid-down event at 13:35 was me.
Not just me
Turns out this is a known Model 3 failure mode. Tesla Motors Club has a thread on exactly this squib resistance warning, and at least two documented cases of the harsher variant where the HV bus drops mid-drive, for no apparent reason – locked wheels, flatbed, warranty repair. Dying quietly overnight in the garage was the lucky draw. There is even a small industry of remote alert-clearing services for these HVP pyro faults, which tells you something about how often it happens.
The part that sticks with me: the cheapest device in this whole story, an ESP32 listening to Bluetooth, produced the single most valuable piece of evidence – the exact second of death, from a device the car does not even know exists. The car’s logs begin where Tesla decided they should; mine begin where I decided.
If your EV sleeps in the garage, put something next to it that listens.