I like updating things. I like the little red badge disappearing. I like knowing that the thing in the rack is on the current version and that I will not have to think about it again.
But UniFi has taught me that an available firmware update is not the same thing as an upgrade I should make tonight.
This is probably the single real downside of buying into Ubiquiti equipment for me. Most of the time it is great. The management is pleasant, the hardware is capable, and the update screen makes everything feel very simple. Then a firmware release comes along that is rough on a particular generation of hardware, and the simple button turns into an evening of unplugging things, reading forum threads from my phone, and hoping I remembered what version I was on before.
That is especially true with older equipment. Some of mine was bought used in the first place. It is not reasonable to assume every new release was tested equally hard against every older switch, access point, PoE behavior, or weird corner of a network like mine.
So I wanted a little friction in front of the button. Not a giant approval process. Just a second opinion that could remember what it had already checked.
The prompt was simple
I gave Hermes a plain-English version of the problem:
Any time there is a UniFi release for equipment in my homelab, research the official Ubiquiti sources, UniFi Community reports, and a few other credible sources before recommending an upgrade.
Do not re-notify me for the same version. Pay special attention to older hardware and reports of adoption problems, boot loops, PoE trouble, uplink or VLAN issues, switch-port failures, controller compatibility, rollbacks, and regressions.
Give me an initial report, then check again after 7, 14, and 21 days. Do not install anything automatically.
That is it. No giant dashboard request. No spreadsheet of every possible release. I just wanted the part of the work I always do badly: remember that a version exists, search for the exact hardware and version, weigh the reports, and come back later after the first few days of real-world use.
Swamp was a good fit because that request has a shape. A version offer is a piece of data. A device-and-target-version pair is a durable key. A review has stages. A report has evidence. And an acknowledgement means I actually received the report instead of the system merely assuming it yelled into the void.
What it does now
The model reads a small, explicit list of firmware-update entities from Home Assistant. It is read-only. It does not log into a controller and click upgrade. It does not mutate Home Assistant. It is not an auto-update system with a nicer name.
It records each available update by the combination that matters: the device and the proposed target version. If the same offer remains tomorrow, I do not get a fresh alert pretending something new happened. If the offer is still there a week later, it becomes worth another look. The same happens at 14 and 21 days.
The daily monitor only does research when a release is actually due for a review. When it is, the default recommendation is Hold/Observe. That is deliberate. No complaints is not evidence that a firmware release is safe, especially on infrastructure that the rest of the house depends on.
The report is short on purpose:
- what changed, without turning my actual inventory into a public blog post;
- which review stage it is in;
- Hold/Observe, Conditional, or Consider;
- what the official note says;
- what exact-hardware community reports say; and
- links so I can judge the evidence myself.
The extension is reusable because the personal part stays private: a Home Assistant URL, a token, and the particular update entities I care about. The public model is only the behavior: discover updates, deduplicate versions, schedule follow-up reviews, and keep the upgrade decision human.
The first real result was not “update it”
The first live scan looked at 11 tracked update entities and found two pending firmware offers. It did not produce duplicate work when it ran again. That was already better than my old system, which was mostly a notification badge plus good intentions.
Then the research did the useful, less satisfying thing: it recommended holding both.
One pending wireless update had an official note that sounded reasonable, but an exact-device community report described the device going offline after a mode change. Other reports around that release mentioned flapping and client regressions. That is not proof that every installation will fail. But it is plenty of reason not to be the person who finds out on a normal evening.
The other was an update for older PoE switching hardware. The official release note existed, but it did not give me much confidence for that exact older family. Community reports for the release included enough switch trouble—ports behaving badly, rollbacks, multicast problems, driver or SNMP failures, and firmware updates that did not complete—that “current” did not sound like the goal anymore.
So the recommendation was not dramatic:
Hold/Observe. Let more people find the problems first.
That was exactly what I wanted. I did not need Swamp to tell me that Ubiquiti is bad or that updates are scary. I needed it to interrupt my habit of dismissing the badge and clicking through because a clean update screen feels like a completed chore.
The primary evidence was still the official release information and the UniFi Community. The community reports that mattered were not random “this broke my network” posts with no details. They were exact-version, exact-family reports that matched the kind of regression I would care about: adoption, connectivity, ports, power, and rollback behavior. Other web searching is corroboration, not a substitute for that.
The two source trails from that first review are public if you want to see the kind of evidence I mean: an exact-device community regression report and the relevant official switch release note. They are not a universal verdict on either release. They are a record of why I chose not to rush.
Why I love Swamp for this
I could write a script that polls for available updates. I could write another script that searches a few URLs. I could glue them together and send myself a message. That would work right up until I wanted the script to remember a version, distinguish an initial finding from a seven-day check, preserve structured evidence, and avoid notifying me repeatedly about the same thing.
Then I would have built a little pile of scripts that was technically working but hard to explain, inspect, or change without re-reading all of it.
Swamp makes the useful shape explicit. There is a model with typed inputs. It produces a typed release-safety report. The report retains the known update offers, the review candidates, the notification stage, and the next review time. The monitor can run again without forgetting what happened the first time.
That is not magic. It is just the boring part of automation being treated as part of the automation instead of as an afterthought.
There is also an important limit here. The system is not deciding that a release is safe. It is making the decision easier to make with better memory and better receipts. I still get to look at the evidence, weigh the inconvenience of waiting, and choose when I want to upgrade.
For something as unglamorous as a firmware badge, that is a pretty good use of an agent: let it do the patient follow-up work so I do not turn “I should probably check that first” into another avoidable troubleshooting project.
The update button is still there. It just has to wait for a second opinion now.