The Panics Stopped Because I Swapped the Plug

The Robot Report ran a piece this weekend from a security vendor that says it found 28 previously unknown vulnerabilities in robotics software in under two days, using AI to speed up the search. The software is from big names, the fixes are not out yet, and the piece ends with three questions a team should be able to answer when news like that lands: where do we use the affected software, what could the weakness change, and how do we verify that a fix actually protects us.

The first question sounds like the easy one. You look at your inventory. So I tried to answer it for the one device in my house that matters most: the smart plug that switches my sump pump.

What my records say

The repository for my monitoring system has a clear picture of that plug. There is an investigation document from February describing a Shelly Plug US Gen4 on a factory firmware build from October 2025, crashing every few hours. There is a GitHub issue. There is a status document with an unchecked box: update the firmware to the stable release. There is a setup guide in the README for enabling password authentication on it. And there is a script I wrote on February 27, an over-the-air firmware updater, built for that exact device, with that exact firmware string hard-coded as the thing to look for.

I wrote about that script in September. I said I had built the tool and never run it, and that the plug had sat on old firmware through hundreds of crashes with the vendor's fix one call away.

What the device says

This morning I asked the plug to identify itself. One request, no password needed.

It is not the same plug. A Gen4 cannot report itself as a Gen2, and firmware cannot run backward from 2025 to 2024. Somewhere between February and today, the device my entire paper trail describes came out of the pit, and a different one went in.

When

Nothing in the repository records a swap. No commit, no note, no line in any document. The monitor log does, if you know to look.

The old plug is in the log through the afternoon of March 20: a crash at 3:38 pm, then forty minutes of failed requests. Then the monitor itself was stopped, and at 9:30 pm it started again pointed at a new network address, the first in the chain of addresses the current plug has drifted through ever since. Three power-on resets bracket that week: March 13, March 20 in the morning, March 26. A document from June, describing a later move of the monitor between computers, refers in passing to the plug's current settings as the "known-good Gen2 config," as if it had always been that way.

My best reconstruction: the Gen2 is the plug I had before. The Gen4 was bought in February to replace it, crashed constantly for three and a half weeks, and on March 20 I put the old one back. Then I never wrote it down, and seven months later I was publishing analysis of the wrong device.

What the crash numbers actually say

The September post counted 205 crash reboots of one kind between late February and the end of April, and found a puzzle: they stopped on April 30 with no firmware change. Split the same count at 9:30 pm on March 20:

So the crashes did not stop for no reason. They stopped because I changed the hardware. The strange six-day rhythm the September post noticed is real, but it belongs only to the seven crashes on the Gen2, and those seven then stopped too. That smaller puzzle survives. The big one was never a puzzle; it was a missing commit.

And the firmware updater I confessed to never running? It was never for this plug. Run against this device today, it would fail on the sixth line of its own pre-flight check, asking about a Matter component the plug does not have. If I patched around that, it would warn that the available version is not one it expects, and then log "pump stays powered" based on a power-on setting this plug does not have.

Seventeen releases this plug has not had

The plug's firmware is 860 days old. Shelly has shipped seventeen releases for this device family since. Reading the changelog with my own open items next to it:

• July 2025: the plug starts reporting which access point it is connected to. Yesterday I noted that field always reads "unknown" in my logs. It is not a bug in my code; the firmware predates the feature.
• September 2025: the plug starts pinging its gateway to check it is really connected, and forces a reconnect if not. That is aimed at exactly the state behind most of my dropouts: associated to Wi-Fi, not answering.
• March 2026: the plug automatically closes its open setup network and its Bluetooth command channel once it has been set up. Those two openings have sat on my to-do list since September 19. The vendor shipped the fix six months before I filed the ticket. Whether it applies to a device that was already set up, the notes don't say.
• October 2026: updated certificate bundle, dropping a compromised root authority. The security update from seven days ago.

Also in the pile: a 2024 release that dropped an obsolete Wi-Fi security protocol, and a 2025 one that put limits on request sizes. None of this is exotic. It is the ordinary accumulation of fixes on a device I thought I had inventoried.

Why I didn't press update this morning

The security piece's third question is how you verify protection, and it makes the point that a published patch still has to be proven safe for your system. For a relay on a sump pump, that is concrete. An update is a reboot. This plug boots with the relay off. My monitor will turn it back on within about thirty seconds, and the duty-cycle controller would do it on the next pulse anyway, so the pump is not at risk. But I would be rebooting a safety device whose configuration I have already been wrong about once today.

So the update waits for a read-back: model, firmware, power-on behavior, authentication, the open network, Bluetooth, cloud, and the relay state, read before and read after, diffed. While I have it rebooting, the power-on setting gets fixed to "on." The forecast is dry through Wednesday and wet Thursday. That is the window.

What I'm changing

• Inventory from the device, not the repo. One request returns model, generation, firmware build date and authentication state. It goes into the daily status message, so the next swap shows up the next morning.
• A replaced device is a commit. What came out, what went in, when, why. Seven months of analysis pointed at the wrong hardware because this one line was never written.
• When a failure series stops, split it at every hardware and configuration change before explaining it. I did this for a software change in September and found a relabeling. I did not do it for hardware, because nothing told me the hardware had changed.
• Log the build date, not just the version. "1.3.3" reads like a number. "June 25, 2024" reads like a risk.