Well as I mentioned, I did some firmwares before for custom boards, and never set any configuration on power saving mode and never had any issues on disconnected devices.
I already messed up with power saving mode, a long time ago and I remember that it won’t solve the issue.
Most of my devices are sonoff mini switch’s and I really doubt that sonoff has bad PSUs on their devices.
I can also try to put a capacitor in some d1 minis where I have the same problem, but again I doubt that is the problem!
My setup consists of 3 units of Ubiquiti Amplifi HD with the latest software 3.6.3.
It’s a mesh system, and ubiquiti allows you to set up the mesh points wired or wifi. I have the central router connected to the wan port and then the other 2 mesh points hardwired to the main router.
Only API. I already thought to change everything to MQTT, but I have a few devices to change and reconfigure, and since this problem was introduced some time ago, I was waiting for an update that could solve the problem. This was not an issue at the beginning of esphome.
I have an 2x sonoff S26, one loaded with ESPhome the other with Tasmota. They have both the same function, switch on/off at the same time lights each one side of the room. HA controls both switches.
My impression is that the tasmota one is more stable than the ESPhome one. Or Tasmota can deal with on/off line behaviour more elegantly. I swapped both switches to rule out WIFI difference, but it sticks to ESPhome.
My wife always pulls the plug from the ESPhome, therefore scores a low WAF factor.
I think one “big” difference is that tasmota by default uses a power safe mode (I think it is modem sleep) which seems to work very reliable nowadays.
Esphome on the other hand (still) uses no power safe on the esp82xx by default (on esp32 it uses it). The idea behind this is actually get a better/more stable experience but it might be that it actually tends to be even less stable in some cases (specially for ready made devices)? I even remember that a device didn’t run at all on esphome because it was drawing to much current from the internal psu and the esp only boot looped
By the looks of it the power safe modes (light and high - default is none) are even switched for the esp82xx’s:
If you are up for some (more) investigation @yann1420 you might wanna try some power save modes?
Another thing which some times can improve the stability (typically with a lot’s of components) is to change the logger level from the default DEBUG to INFO only.
So the esphome node looses connection to ha regularly? Can you be certain it also drop’s out of the wifi the same times?
You could also compare Tasmota and esphome when also using mqtt for the latter - so then they use the same means for communication - might be interesting @digiblur couldn’t made a difference back in 2020
Funny how now I have stability issues on the ESP8266 side so I stopped deploying any ESP8266 with ESPHome. ESP32 was perfectly fine. Mainly dealing with the inability to stay on the Wi-Fi or connect to it. I found that switching them all to MQTT and doing timeout count of 45 fixed it and they just reboot themselves until they connect. I haven’t had to touch them since this and probably won’t change them.
so the ESPhome powermode config is power_save_mode: none
From the devicelog
was connected
10:40:59 - 32 minutes ago
turned off
10:40:59 - 32 minutes ago
became unavailable
10:40:32 - 32 minutes ago
was disconnected
10:40:32 - 32 minutes ago
became unavailable
10:40:32 - 32 minutes ago
turned on
10:30:32 - 42 minutes ago
was connected
10:30:32 - 42 minutes ago
turned off
10:30:32 - 42 minutes ago
became unavailable
10:30:31 - 42 minutes ago
was disconnected
10:30:31 - 42 minutes ago
became unavailable
10:30:31 - 42 minutes ago
turned off
10:23:26 - 1 hour ago
was connected
10:23:31 - 1 hour ago
turned off
10:23:31 - 1 hour ago
became unavailable
10:22:34 - 1 hour ago
was disconnected
10:22:34 - 1 hour ago
became unavailable
10:22:34 - 1 hour ago
turned off
10:15:21 - 1 hour ago
was connected
10:15:21 - 1 hour ago
turned off
10:15:21 - 1 hour ago
became unavailable
10:15:19 - 1 hour ago
was disconnected
10:15:19 - 1 hour ago
became unavailable
10:15:19 - 1 hour ago
turned on
09:58:35 - 1 hour ago
was connected
09:58:35 - 1 hour ago
The device log shows
it comes and goes
turns on and turns off randomly
And for the latter, the WIFI may be flaky for the tasmota as well, but this device picks up the latest state better, not making it into a “disco light”
First my preference for ease of deployment, usage, maintenance etc for pre-built devices like regular light switches, plugs, bulbs etc. Those usually get TASMOTA as usually I have a need for MQTT sub/pub combined wtih Device Groups anyways. Those are simple devices. DIY stuff where I’m digging in and doing weird stuff with sensors etc I usually go ESPHome with those. I stopped deploying ESP8266 on those due to stability issues with it over the past year or so though. ESP32 ESPHome works fine, and the weird thing is some of the ESPHome YAML configs were from years ago where it was solid. Luckily I found the fix on using the MQTT watchdog timer to keep them connected when things went south so I haven’t had to mess with them.
I guess you can say sound mix… My TasmoBackup page has about 100 devices and ESPHome has about 10.
So 100 WIFI clients in your network is not the issue. I sometimes think that my router and AP’s just cannot handle it and that this would be the cause.
I have 2x ESP32’s in my network functioning as a gateway for Xiaomi Mijia BLE Sensors , but also they drop off the network very often.
You mention the MQTT watchdog timer, what is that? Can I RTFM it?
And does that suggest you use MQTT for your ESP devices or do you use the default API?
Indeed that’s the default. The idea I gave in my last post is that you try also the other modes (high and light) - from what I read Tasmota uses high
This is the “view” from Home Assistant. What you really need to look at are the logs of the device. This can be ether over the network or via serial (that’s necessary if the node not only looses the api connection but also wifi).
Maybe that is due to mqtt - did you gave it a try yet with esphome? As I remember (don’t use it anymore since years) mqtt can be “lazzy” it terms of a device can be offline for seconds but it will still show “online” (depends of last will and stuff). The native api on the other hand will immediately detect when a esphome node is not reachable anymore from ha .
Could you explain that a little more? Does your load/light-bulb etc. switch rapidly? Or is it the led status light (for example on a button) of the device?
BLE shares the wifi radio, so that complicates the situation. I ended up removing my two doing the same as they were a pain to OTA as well. It seems BLE doesn’t make it any easier on these devices.
I have around 100 esphome nodes in my network which all use the native api and work a treat. I don’t have any of this device going unavailable problems like some people experience.
By chance you have (serial) logs from that device? (not the ha device logs as they are no use at all in debugging such behauvior)
The FAQ also good a quite big entrace about this problems and indeed mentioned a settings on your wifi AP’s to maybe mitigate the problem for some.
I really can’t back this. All my esphome nodes that capture BLE broadcasts are rock solid:
(last HA update was one week ago and since them esphome was permanently connected)
This is something I experience from time to time indeed. The ota update will just stop at a random percentage. Easiest mitigation I found is to just restart into safe mode and then just run ota - worked 100% the time for me and is only one click more
Yeah this was the crux. Before I even knew about the safe_mode switch, I couldn’t OTA and had to reflash manually. I also found that the more BLE devices I added, the worst the OTA situation was for me. Since 2022.8.0 I’ve migrated to the native Bluetooth Integration that HA introduced.
I also reported several times this issue, but nothing is performed to solve or mitigate the problem. Usually my device are off for some seconds, but I never had any issues triggering any action. For me the simplest solution would be having a configurable timeout parameter to give the node as unavailable. My history is a mess due to this bug. Regarding tasmota is rock solid, never had any issues and I have nodes deployed for years… I only use esphome because is easier to setup, but then I have this downside. This bug was introduced long time ago, because when I started esphome was really rock solid in terms of WiFi stability.
Well, it may be the something in the ESPhome stack, but it could also be something in the ESP-WIFI (Expressif) stack. Or maybe the WIFI network itself is (routers and AP’s) cannot handle the amount of devices or traffic.
But I would like to have tools to rule some of these options out.
, you sticked to ESPhome or moved to Tasmota or do you have a sound mix?
