After an OTA update, some PLT-1B units appear to revert to their previous firmware version on their next wake cycle, rather than keeping the new version. A theory is that this looks like the ESP32's built-in anti-brick rollback safety feature triggering — likely because the device returns to deep sleep before the new firmware gets a chance to confirm a successful boot.
I have 13 identical PLT-1B units that all updated simultaneously (2026.7.3 → 2026.7.4), all using the ESPHome Builder. 10 kept the new version permanently, but 3 units showed the update apply successfully, then silently revert back to 2026.7.3 on their very next wake cycle (~8 hours later) — and never re-attempted the update on subsequent wakes. This was consistent across all 3 units, and I've noticed the three of them have had this issue with previous ESPHome releases.
I'm using the latest ESPHome Builder in HA that has the updated cache/upload logic and have been overall extremely impressed with the speed (I now use a the Remote Build Server on a Mac Mini instead of my RPi for the build process, and it is 10x faster), but also the support for the PLT-1B update on the next connect.
I'm not a programmer, but am using Claude Code and The Unofficial and Awesome Home Assistant MCP Server to help manage my instance, so do with this info what you will. ;-)
After some troubleshooting and looking at logs, it seems like the device may returns to deep sleep before calling the ESP-IDF "mark app valid / cancel rollback" step, so the bootloader's rollback safety net reverts it on the next boot, believing the new firmware failed. Claude suggested either extending the post-OTA awake window slightly before allowing sleep, or explicitly confirm app validity (cancel rollback) in the boot sequence before the device is permitted to sleep again, but again, I'm not going to pretend like that's better than real experience by the dev team, just sharing as a suggested option. I'm also going to check my wifi connectivity in case these have particularly bad connections, which could account for some delay.
I've created an automation separate from the ESPHome process that keeps the device awake for several seconds after an OTA install attempt to see if that gives the new firmware time to confirm a successful boot before sleeping again, since it is working on the other 10 devices. But I won't be able to see if that fixes the issue until the next ESPHome Builder update, which seems to have happen every week or two.
After an OTA update, some PLT-1B units appear to revert to their previous firmware version on their next wake cycle, rather than keeping the new version. A theory is that this looks like the ESP32's built-in anti-brick rollback safety feature triggering — likely because the device returns to deep sleep before the new firmware gets a chance to confirm a successful boot.
I have 13 identical PLT-1B units that all updated simultaneously (2026.7.3 → 2026.7.4), all using the ESPHome Builder. 10 kept the new version permanently, but 3 units showed the update apply successfully, then silently revert back to 2026.7.3 on their very next wake cycle (~8 hours later) — and never re-attempted the update on subsequent wakes. This was consistent across all 3 units, and I've noticed the three of them have had this issue with previous ESPHome releases.
I'm using the latest ESPHome Builder in HA that has the updated cache/upload logic and have been overall extremely impressed with the speed (I now use a the Remote Build Server on a Mac Mini instead of my RPi for the build process, and it is 10x faster), but also the support for the PLT-1B update on the next connect.
I'm not a programmer, but am using Claude Code and The Unofficial and Awesome Home Assistant MCP Server to help manage my instance, so do with this info what you will. ;-)
After some troubleshooting and looking at logs, it seems like the device may returns to deep sleep before calling the ESP-IDF "mark app valid / cancel rollback" step, so the bootloader's rollback safety net reverts it on the next boot, believing the new firmware failed. Claude suggested either extending the post-OTA awake window slightly before allowing sleep, or explicitly confirm app validity (cancel rollback) in the boot sequence before the device is permitted to sleep again, but again, I'm not going to pretend like that's better than real experience by the dev team, just sharing as a suggested option. I'm also going to check my wifi connectivity in case these have particularly bad connections, which could account for some delay.
I've created an automation separate from the ESPHome process that keeps the device awake for several seconds after an OTA install attempt to see if that gives the new firmware time to confirm a successful boot before sleeping again, since it is working on the other 10 devices. But I won't be able to see if that fixes the issue until the next ESPHome Builder update, which seems to have happen every week or two.