This is a miscellaneous post about recent things that have happened with the ESPHome project, and how I’ve implemented them at home. As well as a little bit of troubleshooting.
ESPHome Remote Build server
The fact that you can compile ESPHome binaries for each individual device is both a good thing and a bad thing. It’s good, because the binaries can be very efficient, typically using less than half of the storage space even on older ESP8826 chips. That means you can update them easily ‘over the air’ (OTA).
But the re-compiling process can take a while, especially if you are running the ESPHome Device Builder on low-powered hardware. If you use it alongside Home Assistant, then this may mean that you run it on a Raspberry Pi, or a Home Assistant Green like I do. And that’s good from the perspective of having a low-powered device that’s always on, but not so good when it comes to compiling software. Even a relatively basic compile on my Home Assistant Green takes about 10 minutes.
Now, there’s the option of using a Remote Build Server. This is where you install the ESPHome Device Builder on a more powerful machine – in my case, my MacBook Neo, and the build is done on this. You just need to have the more powerful device on with the device builder running in the background, link it with the device builder on your Home Assistant device, and all future builds will be done on the faster device. Device builds now take around a minute, instead of ten minutes. This is especially good if you’re tinkering with settings and need to re-compile several times in a short space of time, or have lots of devices to update when a new version of ESPHome is released.
Fixing OTA failures
One of the old Tuya smart plugs that I re-flashed with ESPHome has been temperamental with over-the-air updates recently. It hasn’t always accepted the latest firmware when a new ESPHome release has come out, and given a rather unhelpful error message. I would see things like “set Error flag: unspecified” and “unknown error from esp“, and it would time out after about 10 minutes of doing nothing after “preparing to upload“.
What was bizarre was that I have four of these plugs, all running essentially the same ESPHome configuration (just with different names), and yet only this one was problematic. Anyway, I managed to solve it by taking the nuclear option and manually re-flashing it. I even followed my own guide that I wrote last summer, which helped with matching up the pins on the device with my USB-UART converter. A manual re-flash worked, and a subsequent OTA update worked as well. This suggests that there may have been some corrupt code left on the flash memory of the device that the manual re-flash wiped.
Changing to OTA Encryption
Last month’s release of ESPHome introduced OTA encryption for over-the-air updates. Previous updates would include a password in the YAML code, but things like your Wi-Fi key were sent unencrypted across your home network when updating. This improves security, but also makes the firmware more efficient; it uses your Home Assistant API key as an encryption key, and this typically frees up about 30 KB of flash memory on your device. That might not sound like a lot, but on ESP8266 devices with only a single megabyte of memory, that’s about 3% more space freed up.
To enable it, you’ll need to update your devices to ESPHome 2026.9 with the existing YAML code, but then once the update is installed, the ESPHome device builder will ask you to change from a password to encryption. A single click of the button, and a re-compile of the firmware, and you’re done.
It’s great to see continual improvement in ESPHome, with useful new features being added every month and a concerted effort to make it easier to use. Having smart devices running on open source firmware that isn’t tied to an anonymous cloud server is great.
