Do you update everything at once when a release like 2026.10.0 lands, or one device at a time?

I'm firmly in the one-device-first camp, and my canary is the landing light, purely because I pass it a dozen times a day and woud notice straight away if it came back wrong. A year or so back I flashed everythign in one go and the kitchen under-cabinet strip came up at full brightness at 3am, which cured me of that approach permanently. Now I wait a few days, check the logs now and then, and only then let the rest go in batches of three or four.

The boot state change you mention is exactly why. Anything on a wall switch that gets flicked off at night is going to restart often, so a light behaviour change shows up fast here. My method before flashing is to open the YAML and set restore_mode explicitly on every light instead of trusting the default, then I stop caring what the release notes changed.

Garage and loft devices are the exception for me. Those get the longest soak, sometimes a month, because I only find out something is wrong when I actually walk out there. The compile speed gain is nice but it'll still be there next month, whereas standing on a step stool in the cold at 10pm debugging a light that will not come on is no fun at all.

I'm on the other end of the scale, mostly because of how I built my setup. Every board in the house also runs the web server, and I keep the old compiled firmware files on my PC in a folder named by version. If a light comes up wrong after an update, I flash the previous build back over WiFi in a couple of minutes without touching a ladder. That safety net is what lets me do the whole batch in one Saturday morning, garage door controller included.

The one habit I'd never skip is timing. I never update anything after dark anymore. Learned that when a hallway light on an ESP8266 decided it wanted boot brightness instead of the night dim level I'd set, and my wife was not impressed at midnight. Now everything gets flashed around 9am with coffee in hand and I wander the house checking each one like a security guard doing rounds. The annoying-to-reach question matters less to me for that reason. If rolling back is painless, the ceiling-mounted workshop light is no scarier than the bench one. I do leave my config files in git with a tag per version, so if the new boot behaviour breaks a bedroom lamp I can add a restore state line and know exactly what changed between the two.

The faster ESP8266 compiles alone are tempting enough that I'll prolly do the full sweep this weekend.

I don't really think adding restore_mode explicitly to the YAML for every light is the best move. Relying on a software setting to handle what is fundamentally a power state issue seems like overkill. If I’m worried about a bulb booting up incorrectly, I’d prefer using the physical wall switch to cycle the power once when the system first boots up. That way I’m not tied to whether the new firmware correctly interprets the state of the previous power cycle. It just feels more reliable not to put logic like that in the configuration files.

I'm with the idea of going slow and testing a few devices first. Using a highly visible or frequently checked item like a light switch is definitely the easiest way to spot a bug quickly without having to pull out the phone to check a log file. I had an issue once with a temprature sensor in the laundry room and waited two days after the update before flashing the others. I noticed the sensor started reporting wierd stability even when I was sure the room was heating up, wich led to me keeping the old firmware on that specific unit.