Firmware Updates: The Silent Change to Installed Equipment
Why this matters
When you leave a job, you leave equipment in a known state. A connected device does not stay in that state. The maker can replace its firmware overnight, and the new version can change a default, retire a feature, rename a setting or alter how the device talks to everything around it, with nobody in the house touching anything. The customer experiences that as "your install broke", and unless your record says what version you left behind, you have no way to show it was not you.
What firmware is, and why it changes behavior
Firmware is the software that lives on the device itself, as opposed to the phone app. The app is a remote control; the firmware is the thing being controlled. When a maker ships a new firmware version, it can change anything the old one did, because the old one is gone.
Updates arrive in three ways, and you need to know which one a device uses:
- Automatic and silent. The device downloads and installs on its own, usually overnight. Most consumer devices default to this. The customer is not asked.
- Automatic with notice. The app shows a banner, or the update waits for a tap. Customers routinely tap without reading.
- Manual only. Somebody has to start it, from the app, a local web page or a service tool. Common on equipment-grade controls and on anything meant to be installed by a trade.
Makers also stage rollouts: the same version reaches a small share of devices first and the rest over days or weeks. So two identical devices installed the same day can be on different versions next month, and the one the customer complains about may be the only one updated so far.
The five kinds of change that cause callbacks
Not every update is a risk. Most fix bugs and close security holes, and you want them. The ones that generate callbacks fall into five recognisable kinds, and naming them helps you read release notes quickly:
| Kind of change | What it looks like in the field |
|---|---|
| A default reset | A setting you changed at install quietly returns to the factory value: a lockout temperature, an auto-lock delay, a sensitivity level |
| A new feature switched on | Behavior appears that nobody asked for: an energy-saving mode that widens a temperature band, a motion feature that wakes a camera more often |
| A feature retired or moved | A setting disappears from the menu, or moves somewhere the customer cannot find it |
| An integration changed | The device stops answering a hub, a voice assistant or a second app, because the way it talks to them changed |
| A threshold changed | The same input now produces a different action: a different leak volume before closing, a different battery level before warning |
The first and fifth are the expensive ones, because the device still looks normal. It responds, the app shows it online, and it does something slightly different from what you set up. That is exactly the fault a tech is least likely to suspect.
Checking and recording the version
The whole defense is one line in your record, written at the moment you leave. What to capture for each connected device:
- Model and hardware revision. The revision is often on the label as a short suffix and matters because firmware differs by revision.
- Firmware version, exactly as displayed. Copy every character. Two versions can differ only in the last digit.
- Date and time you read it.
- Update policy setting. Automatic, notify, or manual, and whether you changed it.
- Every setting you changed from the default, with its value. This is the list a default reset would undo, so it is the list you will compare against later.
Where to find the version varies: usually under device settings, about or information in the app, sometimes on a local status page or a service menu at the device. If you cannot find it in two minutes, write "version not displayed" rather than leaving the field blank. A blank looks like you forgot; a note says you looked.
See related: Leaving a Device Record the Next Tech Can Use, which owns the full record format. This card is about why the version field earns its place.
When to hold updates, and when not to
Where a device lets you control updates, the question is when holding them is worth the security cost. The rule that works: hold for a defined window with a reason, never hold indefinitely.
Hold during commissioning and early life. For the first one to two weeks after an install, while you are still confirming the system behaves as set up, an update changes two variables at once and makes any problem harder to read. Set updates to manual or notify for that window if the device allows it, and write down the date you will switch them back.
Hold before a high-stakes season. A heat pump control the week before the first cold snap, an irrigation controller at the start of a drought restriction, a pool automation controller before a long vacation. An update that changes behavior at that point fails at the worst time. A common default: apply pending updates at your last maintenance visit before the season and then hold until the season settles, which is roughly a month.
Hold where devices are integrated. When one device's behavior feeds another (a sensor closing a valve, a thermostat talking to a hub that also runs dampers), an update to one side can break the conversation. Apply updates one side at a time, with a test after each.
Do not hold security updates beyond the window. A device left unpatched for a year is a device with every known flaw from that year still open on the customer's network. Holding is a timing decision, not a refusal.
What changes the answer. Many consumer devices offer no control at all; the maker updates whenever it chooses. Then holding is impossible and your defense is entirely the record, plus telling the customer at handoff that the device updates itself and may change. Equipment on a commercial account, where a building manager or an IT contact owns change control, inverts it: there you do not decide, you ask, and you record who approved what.
Worked example: one release, a fleet of installs
Say your shop has installed connected door locks at 23 homes over two years. A maker's release note says a new version changes the auto-lock default from 30 seconds to off for devices where auto-lock was never adjusted, and resets the setting on some devices where it was. You want to know who to call before customers notice their doors are staying unlocked.
Start from the records. Of the 23 installs, 19 have a firmware version and a list of changed settings recorded. 4 were installed before you started recording versions.
Sort the 19. The release applies to versions below a stated number. 14 of the 19 recorded versions are below it, so those 14 will update. The other 5 were installed recently and already shipped on the new version, so the change does not reach them.
Of the 14, who set auto-lock? Your changed-settings list shows 9 of the 14 where you set auto-lock to a custom delay at the customer's request, and 5 where you left the default. The 5 on the default are the ones the note says will go to off. The 9 you adjusted are the ones the note says "some" of will reset. You cannot tell which of the 9, so all 9 are suspects.
So the call list is 14 homes from the records plus the 4 unrecorded ones, which is 18 of 23, roughly four in five of the fleet. The 5 recent installs on the new version need no call. Without the version and settings fields you would have had to call all 23 or wait for complaints, and a lock that stops locking itself is a complaint that arrives after something has gone wrong.
What the call says. "The lock maker is pushing an update that may turn off the auto-lock we set for you. After it lands, please check the setting in the app is still at the delay you wanted. If it has changed, set it back or call us and we will walk you through it." That turns a silent change into a known one before it happens.
The failure mode. A shop with no version records learns about this release from the first customer who comes home to an unlocked door, then has to argue about whether the lock was set up right. The record is what lets you say, with a date and a value, what you left.
Finding the update after the fact
When a customer reports "it changed", check whether an update landed before you open anything. Most devices keep a version history or at least show the current version and sometimes the date it was installed; some apps show an event log entry for the update. Compare the current version against your record. A different version plus a setting that no longer matches your changed-settings list is a strong signal. See related: It Worked Until Last Tuesday and Nobody Touched It, which walks a full case built this way.
Then restore the setting, confirm the behavior, and update your record with the new version and the date. The record now shows two versions and a known difference between them, which is worth more than either version alone.
Verifying your process works
Pick three connected installs from last quarter at random and try to answer, from the record alone: what version was installed, what update policy was set, and which settings differed from default. If you cannot answer all three for all three installs, the record format is not being filled in, and the fix belongs in the commissioning step rather than in a reminder. See related: The Connected Device Commissioning SOP.
References
- Manufacturer release notes and installation manuals for each device installed
- See related: The Connected Device Commissioning SOP
- See related: Leaving a Device Record the Next Tech Can Use
- See related: It Worked Until Last Tuesday and Nobody Touched It
- See related: When the Manufacturer Shuts Off the Cloud