WTH does ESPhome wireless update fail so often

[bkbartk]

I read that, and I do believe other network equipment would work. But I actually don’t want to add any other network hardware to avoid this issue.
I have OpenWrt wireless roaming to cover my whole house.
And it other devices/software doesn’t have issues with it, ESPHome should be able to handle this as well.
Also if a network issue occurs during an update, which can always happen the device should be able to recover itself, either reboot or something else but this now is not the case.

[edit] btw modifying power_save_mode doesn’t make the problem go away, just tested this.

[Protoncek (Pavel)]

I can also confirm that it’s a network issue rather than FW’s one. I’ve had similar problems until i managed to “get my router” in order.
Regarding Tasmota: i agree, it’s easier to configure the part YOU CAN configure. But it’s quite harder (if not impossible at times) to get some special function you want if tasmota’s FW doesn’t have it built-in already. Yes, lately tasmota has scripts, but… oh, dear jesus…

[petro]

It’s ubiquiti. I have their system and this happens every other firmware update to the access points. Super annoying. They are known for pushing out crap firmware.

[aceindy]

Also using Ubiquity ap’s here, no issue (apart from the controller, which doesn’t want to fall in line with my firewall rules on my windows machine (so if i want to make changes/check for updates, i have to switch off my firewall )

[petro]

How often do you update your AP firmware?

[aceindy]

Actually, i don’t have a clue…when i set up the controller, all was working fine and set to auto.
However, i think abt 2 months ago, i noticed the controller lost connection with both AP’s.
So i changed my firewall and opened all required port (according ubiquity), but connection is lost whenever I turn on my firewall again.
I think i checked it last 2-3 weeks ago, and updated them… (still no issues though)

[jayjay (JJ)]

I had to switch on ping in settings of esphome to get them stable, now almost none fail or drop out of the network, maybe that helps!

[bkbartk]

I don’t have Ubiquity so that can’t be it,
I have tp-link running OpenWrt.
I did some additional tesging and found actually really strange, this error.

INFO Successfully compiled program.
INFO Resolving IP address of bijkeuken-light.local
INFO  -> 192.168.180.140
INFO Uploading /data/bijkeuken-light/.pioenvs/bijkeuken-light/firmware.bin (524944 bytes)
INFO Compressed to 364308 bytes
Uploading: [==================                                          ] 30% 
ERROR Error sending data: timed out

the error on itself is not strange, but starting from 20% the bar went slower and slower untill it stopped.

And with it the device died(also the physical buttons won’t respond, so not only wifi), like it’s chocking on the update process.
If just the update fails bacause of a network issue the device wouldn’t die.

It could be device specific, that my devices have issues when using to much power or something.
I have this issue with sonoff t0 and t4,
but not on my esphome “slimmelezer” which I’m using for over a year now with ESPHome.

@jayjay
how does this ping actually work, then I can give it a try.

[Protoncek (Pavel)]

Did you try with different power supply? This behaviour sounds to me like power issue…

But, regarding routers: i have Asus routers with Merlin FW. There are TONS of settings for wifi. Setting them right is pain in the a**, but once you do it it’s ok. For starter turn off all “speed boost” functions for 2.4GHz (like turbo etc…). Supposely these functions should improve transmission speed on 2.4GHz, but since they were never standardized they generally doesn’t work good and cause nothing but problems, so it’s best to avoid them.

[aceindy]

@Protoncek

Did you try with different power supply? This behaviour sounds to me like power issue…

good point

[bkbartk]

Those sonoff wallswitches go directly into the maingrid. Do can’t really change the powesupply. What I did try was flashing a sonoff t0. Because the t4 has some override on the neutral which I thought maybe the issue. But the t0 had the same issue.

You wire them directly to 230v

I’ll have a look at speedboosters. I think I don’t have them for 2.4G. As performance requiring devices are all on 5G

[Protoncek (Pavel)]

I have all my switches connected so that they are all directly on mains supply, not via capacitor. Powering module via capacitor can cause problems. But, yes, i know… it’s not always possible to add another wire - in this using bigger capacitor could help perhaps (bigger capacitance).

[baz123 (Brian)]

@bkbartk

the error on itself is not strange, but starting from 20% the bar went slower and slower untill it stopped.

That was exactly the error I was getting. Once I move the device to a different physical AP, it stopped happening. YMMV.

[orange-assistant (the real one)]

One thing you all can try is to activate the safe mode before running the update. This is easy as pressing a button once configured.

Safe Mode Button

From my ~100 esphome devices I only experience such problems with the few ones that also work as ble receivers/proxies. It’s probably caused by the shared antenna (wifi and bluetooth can’t use it at the same time but technically they use it in alternating fashion) which in that case is able to somewhat break the upload over wifi.

If the safe mode is activated no components/scripts/etc. will be loaded but just the bare essentials - it should then always work to do a ota update (when a sufficient wifi signal is present )

[bkbartk]

you probably won’t believe me but I was trying to get some more enabling VERY_VERBOSE
but 40 installs later, and no issues. I had a few(2 or 3) errors, but at least the be devices always recovered from it. which is good enough as I don’t need physical access to fix it.
I will test some more but is looks really strange to me.

@baz123

That was exactly the error I was getting. Once I move the device to a different physical AP, it stopped happening. YMMV.

If I have the issue again, I will check some advanced network settings, add another AP and if needed purchase your suggestion. but for now suddenly all seems to work fine without any isseus.

@orange-assistant

One thing you all can try is to activate the safe mode before running the update. This is easy as pressing a button once configured.

good one,
but then I should’t forget to click this button.
And if I understand this correct

OTA Update Component

safe_mode will be enabled by default once OTA starts.

[orange-assistant (the real one)]

@bkbartk

Those sonoff wallswitches go directly into the maingrid. Do can’t really change the powesupply.

In that case you also should take care that you have the power_save_mode: set to HIGH (that’s the default for tasmota but not for esphome!) in case it’s a esp82xx

@bkbartk

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  power_save_mode: HIGH

That’s because the moment the device is doing a ota update it is having a power peak.

Also If at the same time relays are toggled on (also drawing power) it can be easily that the internal PSU isn’t able to provide the power need for a longer period (for the whole time of the update for example) .

@bkbartk

Also sometimes the device gets unresponsive up untill the point whrere I need to unpower it.

And that should really never happen and is definitely a bug.

I had this maybe two times in many years and probably thousand of ota updates for my now roughly 100 esphome devices

[bkbartk]

I actually assumed power_save_mode would be disabled because of save safe_mode.

but if this is not the case an automation like this would help I guess

ota:
  password: !secret ota_password
  on_begin:
    - lambda: id(wifiId).set_power_save_mode(esphome::wifi::WIFI_POWER_SAVE_NONE);

after ota a reboot applies, and power_safe_mode is back to high

btw, I’m not using any buttons while updating, so drawing too much power is what I would think, but then I can’t be the only one having those issues.

@orange-assistant

In that case you also should take care that you have the power_save_mode: set to HIGH (that’s the default for tasmota but not for esphome!) in case it’s a esp82xx

true,
that’s why tasmota on the same device on idle uses ~0.4W of power and ESPHome ~1W
And I’m in Europe, so with the current prices and 30 devices and growing, this option isn’t optional for mee actually

[bkbartk]

I still have to dive in to the network part,
but I notices one thing,
whenever a device gets unresponsive after an upload fail it’s always an esp8285, I never have this with my one esp8266 device. In the past I had an esp32 running ESPHome, also with that one, I never had those issues.

[bkbartk]

I actually found something while using logger level: VERY_VERBOSE
the logs stops on a percentage like OTA in progress: 71.6%
but as soon as I try to load the site on another tab it logs 2 additial lines.

19:52:11	[D]	[ota:312]	OTA in progress: 70.5%
19:52:26	[D]	[ota:312]	OTA in progress: 70.8%
19:53:19	[D]	[ota:312]	OTA in progress: 71.6%
19:56:55	[V]	[json:031]	Attempting to allocate 512 bytes for JSON serialization
19:56:59	[V]	[json:051]	Size after shrink 64 bytes
19:57:20	[V]	[json:031]	Attempting to allocate 512 bytes for JSON serialization
19:57:21	[V]	[json:051]	Size after shrink 64 bytes
19:57:57	[V]	[json:031]	Attempting to allocate 512 bytes for JSON serialization
19:58:01	[V]	[json:051]	Size after shrink 64 bytes

could it be that there just isn’t enough RAM left? or does this mean anything to anyone?

[Solarflor]

@bkbartk

power_save_mode: HIGH

This was the solution in my case