As a technical PM, I often know enough to get myself into sticky situations, yet not enough to cleanly extract myself. I’m a badge-wearing newbie in the ESPHome space and recognize that the platform provides ample rope to hang yourself with. So I tread carefully.
I don’t write the config for any of my ESPHome devices. All (except one) were purchased from trusted vendors like ratgdo or Apollo, and reference a github repo for their config.
I started reading the release notes for new versions of ESPHome. Recent releases are stuffed with efficiency & security enhancements, not to mention shiny new features.
This introduces a risk/reward decision for critical devices: should I really be updating them? I do OTA / OTN updates for everything and expect that rolling back versions won’t be quick or easy – especially for a platform novice.
I’m happy to accept these risks for non-critical devices (i.e.: AQI & temperature sensors). Critical devices (i.e.: ratgdo) give me pause since I’d be in bad shape if they bricked. So if it’s critical device, and it ain’t broke… I probably shouldn’t roll the dice often – if ever – right?
The problem is, when you do want (or need) to update, how many previous version release notes and breaking changes do you want to have to go through?
I update ESPHome once a month, and all my devices, too. I start with the least critical and work my way up to the more important ones, in case I do run into a problem.
Rolling back wouldn’t be much of an issue. I’ve re-installed ESPHome a couple of times. As long as I have my “source” .yaml files, it doesn’t really matter.
I can’t argue with the “if it ain’t broke, don’t fix it” approach. Ideally, you would never have to do an OTA update for the life of the device. But this isn’t an ideal world. I don’t need to be on the bleeding edge, but I don’t want to be left behind, either.
Admittedly I’m in the opposite boat, in that I wrote all of the YAML my devices use, but I would assume that if the vendor is legit, trustworthy and invested in their customers, they would update their GitHub repo as ESPHome changes. In that case, still no real need to update unless there’s a specific feature or issue that needs fixed and at the same time, should be easy to update at any future time since their YAML should already be up-to-date for the then-current ESPHome version.
In my case, I usually update my devices once (maybe twice) a year just to limit changes I have to make to my YAML as ESPHome evolves. The exception being when there’s a change I want/need.
This same problem was in my mind for some time too. A lot of my esphome devices are totally developed out to a state that it does everything I want and I need. So for those devices there is no real need to update them. But the development of esphome doesn’t stop and what happens when an old esp8266 device that already runs 2 years nicely goes defect. You take a new one, get the config yaml and … it won’t compile any more. Well, to be prepared for that worst case scenario I store those config yaml’s in a separate folder and i generate a firmware bin file that i store there also. If the yaml has to much problems to compile then I upload the bin file directly and the new device is ready to go in minutes
No, every case is different. If you know you need to make some changes to the code once in a while , keep it updated. In case your device does what it has to do and you really don’t have a reason to touch it, just let it run.
This debate has been around for as long as there has been software. Back when I did IT for a living, and updates impacted our production users and had a significant cost, we’d tend to “leapfrog” one or two versions before updating.
Good point about being prepared to replace failing hardware. There always seems to be a reason to keep your source maintainable. Although I do like the idea of storing the binaries for a quick recovery.
I don’t think there is a “right” answer. Do what works for you!
what happens when an old esp8266 device that already runs 2 years nicely goes defect. You take a new one, get the config yaml and … it won’t compile any more. Well, to be prepared for that worst case scenario I store those config yaml’s in a separate folder and i generate a firmware bin file that i store there also. If the yaml has to much problems to compile then I upload the bin file directly and the new device is ready to go in minutes
Excellent point about hardware failures. My HA instance and all relevant data are backed up daily, yet my ESPs lack the same capability to restore from a time-specific backup. I’ll be stealing this approach and will begin storing a compiled bin for each device.
The .bin files should already be there. I found mine in .esphome\build\devicename.pioenvs\devicename\firmware.bin, \firmwarefactory.bin and firmwareota.bin. All bear the date/time stamp of the last time I updated the device.
I haven’t tried uploading the binary without re-compiling it, first.
If that work for you then that is an excellent solution. For me I find this to much work and risk to restore each time a compatible esphome build to hopefully do a compile and re-install the latest version again.
I also use HAOS, and I agree that not having to deal with the “guts” of a VM makes HA easier to administer. However, I wouldn’t survive without the Samba Share add-on to let me view and edit the files that an HA administrator needs to maintain. There’s also the File editor add-on.
Things got a lot easier for me when I realized that ESPHome development doesn’t have to be tied to HA. I manage, maintain and compile my ESPHome devices on my regular laptop. I do have the ESPHome Device Builder add-on installed in HA but I never start it any more.
HA is a production system. I do all my development on my laptop. Why should I connect to the HA host using a browser just to do development and compiles for my ESPHome devices? It’s inefficient for me and it’s not doing the HA host any good. There are lots of posts in this forum about how compiling ESPHome stuff killed their running HA system.
You don’t write configs, so will not change them too ?
Then IMHO there is no big benefit from changing ESPHome version.
Recently upgraded my devices from 2024.12 to 2025.9 version, just because have some plans to use implemented features. Otherwise was completely satisfied how it works on 9 months old version.