Recently had to update firmware on some of my devices to introduce a new functionality, the update involved upgrading the firmware and I got caught by a breaking change that I missed in the various releases between the old version of firmware and the new one.
I know the common saying on IOT devices, don’t update it unless you have to, however sometimes you end up having to so (new functionality, patch security issues) this got me wondering to what others might be doing to keep track of changes (particularly breaking) when they have to update firmware.
Thinking the problem is two fold:
being able to easily identify all component/platform etc defined in a particular firmware
being able to cross reference that list to see if changes (especially breaking ones) were introduced between version of firmware.
To solve #1 I was thinking maybe I should break out common platforms for like devices into separate packages (ie have one package for the hlw8012 sensor config for my wyze outdoor plugs) then maybe its easier to identify changes in platforms by looking at the packages list. Of course I could maintain this in an excel spreadsheet but where would the fun be in that.
Not sure how to solve for 2 as I don’t think there is a master list of changes by platform/component.
Hi,
There is an entire industry doing what you’re thinking of attempting with Excel - tracking component versions, changes, and issues. The main reason a Software Bill of Materials (SBOM) is maintained by enterprises is to impact asses security issues, however the same level of effort would also be needed to understand functionality changes:
What would I do instead? Create a pre-production or test HASS install with ESPhome and some test devices. Update pre-prod, test, then update production. It’s simpler to check the output than track all inputs.
I scan the release notes when they come out. I guess I’m fortunate that while I have a fair number of devices, there are really only a small set of actual modules I use, so I can mostly do it from memory. I always update one of each kind of device first. Usually the breaking changes come up during compile, so I fix them at that point if I didn’t see them during the read through of the release notes. Then I usually let those first devices bake in a couple days before doing the rest.
The other thing I do is intentionally trail on releases. So when, for instance, 2024.3.x came out, I updated to the last version of 2024.2. That way everyone else has mostly found the issues by then.
this post!