Same issue here, reverted to 26.3 as per above and sorted the issue. Did not modify anything else. Thank you very much for your help. Defo will be slow to do updates from now on.
Has anyone been UNABLE to reflash their device? I have a Vue 3 and im having a heck of a time getting esphome flash wizard to even recognise my device. Granted i have a jerry rigged wire holder but my pin placement isnt that bad. Ive been trying for hours with no luck. Any completely bricked devices out there from this?
I was using Ethernet, and can ping the device. Is it still possible to recover without flashing via the pins again? Its a real pita to flash via the pins again.
I was trying to get it into safe mode by power cycling multiple times, but it always fails with āError receiving acknowledge version: timed outā and I am not sure if it actually enters safe mode.
I doubt there are any hard bricked devices from this update. Likely the wiring is just not perfect. Remember with the vue3 the rx and tx pins are mislabeled on the circuit board. It took me 45m of messing around with my terrible setup but finally got it flashed after redoing the wires multiple times.
I never did invest in a proper frame/pogo setup since I didnāt think Iād need to manually flash it again.
Yeah I donāt have a great setup either for flashing thatās why Iām trying to avoid it, but it looks like I will need to as the OTA update always fails. I even tried a simple YAML with just basic network connectivity and it still failed
I donāt normally curseā¦ but todayā¦ WTFā¦ 
Iāve been spoiled the past couple of yearsā¦ every time I upgraded ESPHome, itās been flawlessā¦ I used to upgrade almost every update, then I started only upgrading every 2-3 months. I read the release notes, I upgrade and look to see it comes onlineā¦ I have 9 of these Emporia Vue 3āsā¦ Most are using Ethernet, 1 is using WiFi. I upgraded the first 4 before I realized something was wrongā¦
The first 4 are upgraded to 2026.04 (A1.1, B1, B1.1, G1), the last 5 are on 2026.02ā¦ NOTICE they are showing ONLINE
āCONTINUED FROM ABOVEā
In my case, the devices are pingable on the networkā¦ I use Uptime Kuma to monitor themā¦
Youāll notice, Panel A1 (A1.1) does go offlineā¦ Panel B1 and B1.1 were also going offline due to:
Network Loops & Storm Control - Critical - STP State Flapping
NOTE: Iām unsure if the STP State Flapping is related to the firmware issueā¦ REASON: Also last night my UniFi network was updated (throw 2 changes into the mix), so I was unsure if the issue was with the switches, so I disabled the ports and re-enabled them, apparently this caused the default VLAN to be set and the devices got a DHCP address in VLAN1, then I reconfigured the switch ports to IoT VLAN and then they got their reserved IP on IoT VLANā¦ this is when I started seeing the STP blockingā¦ I think this was related to me trying to reconfigure/fix the ports on the switchā¦
As a test, I disabled RSTP + Loop Protection and also put these two devices on a dumb switch, then plugged that into the IoT VLAN that B1 was originally on. Thus, you can see via Uptime Kuma that the devices seem to be reliably on the network.
āCONTINUED FROM ABOVEā
Restored ESPHome to 2026.02, attempting to reflash via OTA is unsuccessfulā¦
Interestingly, it does seem able to connect to the IP and portā¦ 
My framework:
esp32:
board: esp32dev
framework:
type: esp-idf
version: recommended
advanced:
minimum_chip_revision: "3.1"
I am hoping that I donāt have to manually flash theseā¦ most of you above are concerned with just 1 or 2 unitsā¦ If ESPHome hadnāt shown devices ONLINE and also Uptime Kuma reporting as if all is normal, I wouldnāt have flashed 4 unitsā¦ it wasnāt until I looked at my Sankey energy chart that I noticed there was no data coming inā¦
I donāt know if itās possible that the ESPHome dashboard continues to show ONLINE (simply the device is pingable), but maybe add another metric that the firmware is up and operating as expected? Because what I experienced was very misleadingā¦
ONLINE - STATUS: OPERATIONAL
Yup, I have the exact same issue. I even tried timing sending the most basic YAML directly to the Vue 3 with ESPHome 2026.3.3 and it still fails with the same error you received.
At one point I got it to say āuploadingā, but ultimately it failed with the same error. It must be crashing so fast it has no way to send the OTA update
At this point I have wasted too much time and will just end up flashing with serial, as I only have 1 Vue 3.
Problem is likely here
This should solve it [core] coerce set_interval(0) / update_interval: 0ms to 1ms by bdraco Ā· Pull Request #15799 Ā· esphome/esphome Ā· GitHub
However the emporia-vue-local external component should be fixed to use an interval other than 0ms or use the high frequency loop requester instead
I have 4 Vue3ās Im in the process of installing, and as Im writing code for them everything is still opened up (at least they are not buried in the panels yet). Ive been working sequentially through these and was just getting to the third when I saw āweirdnessā in ESPHome such as the device names not matching the originally named YAML files (one in fact re-named to an existing device)ā¦ still havenāt got past that, but the code is correct - the static IP anyway.
All 4 devices are wireless with static IPās. Digging in deeper last night / this morning I found they were having the OTA rollback issue - downgrading ESPHome to 2026.3.3 seems to have temporarily fixed the issue, Im currently re-installing using 2026.3.3 and rolling through all devices (three have completed, working on the 4th as Im typing - and Im getting āexpectedā results in HA). Pretty sure that I initially started with this version on the Vueās as Ive only been working on flashing them for the last week or so, so the installed code wasnt that old.
*addition 4-19-21 ** 3 of four were able to flash wirelessly after rolling back to x.3.3 - one still had a minimal temporary flash on it, and that required serial flashing. After the 3rd of fourth wifi iteration I had another unit get stuck and wouldnāt accept new code, so I serial flashed that as well.
As this is a brand new installation I still have the panels opened up - Guess Ill leave coding alone and co back to labeling / documenting 63 circuits and double check all the phase settings before doing anythign else.
I suspect there are other things that are doing the same thing. Thanks for taking the time to find this.
I created this issue for magentometer meters that have the same issue.
Unfortunately this hit me too last night, after multiple years running with no issuesā¦ I even thought to myself before I did the upgrade of ESPHome that something was going to breakā¦ and boomā¦ it did.
I got back up, after pulling the device, erasing it. Restoring ESPHome Builder back to 2026.3.3 and then re-installing the code to the device with the following tweak:
esp32:
board: esp32dev
framework:
type: arduino
thankfully everything came back up as it was.
I havenāt re-tried 2026.4.0 with the code changeā¦ has anyone had success?
Regarding the pads on the back - I found those to be fragile and a gigantic pain from the outset with pogo pins.
When I first did my two units and again during the reflash I had to do on one this week, I put my Frankenstein pogo creation on the corresponding pins of the ESP32 itself. Due to the little crescent shapes where it is surface mount soldered to the board, my pogo pins tend to nestle in there and hold well with a little bit of pressure. You can see the photo earlier in the thread showing this on the screen of the microscope.
Itās janky, but it works.
I ordered a spare unit to have around that I will flash soon and keep in my lab. I will likely slow my upgrade pace as well, but Iāll send one of my configs to it ahead of the active units and make sure it survives to OTA reachability first.
Iām tempted to solder a little connector onto the ESP32 pins of the active units that I can extend through a hole in the case. Then I could reflash them in the panels from my laptop with relative ease.
So, mine seems to be working after about 2 days of going back and forth on itā¦
I didnāt have to revert back and am still on 2026.4.0
I updated the esphome: block to have āproject:ā information and the ESP32 board stuff to this:
friendly_name: Emporia Vue 2 - ESP32 - Main Panel
name_add_mac_suffix: false
project:
name: āesphome.coreā
version: ā2026.3.3ā
esp32:
board: esp32dev
framework:
type: arduino
Then I had to add this update_interval:10s timer in to the sensor: block to get it stable.
sensor:
- platform: emporia_vue
variant: vue2
i2c_id: i2c_a
update_interval: 10s
phases:
I appear to finally be back online and updating and seeing my sensors again.
Which was adjusted and merged in
Even with the update interval set we still need to limit to version: ā2026.3.3ā?
I just did your changes but with:
esphome:
name: emporiavue2
friendly_name: Emporia Vue 2
project:
name: "esphome.core"
version: "2026.3.3"
esp32:
board: esp32dev
framework:
type: esp-idf
version: latest
sensor:
- platform: emporia_vue
i2c_id: i2c_a
update_interval: 1s
It seems to be working fine but would like to keep things updating. At least with this change I can continue to use the update all when esphome updates. Thanks!
I see we have a 2026.4.1 upgrade now. Iām definitely gunshy after the Vue episode and will hold off, but curious if this fixes the issue, and if there is anything that needs to be changed in the Vue integrations themselves.
2026.4.0 broke one of my vue2s (recovered via serial). Both my vue2s upgraded to 2026.4.1 today. No problems. Nothing needed changing in the config.
I was bricked by 4.0. I just installed 4.1 and it has fixed my issue.