I have a bunch of ESPHome/ESP8266 projects, several of which are have been plagued by repeated disconnection during seemingly random times of instability. Sometimes they’ll be fine for days, and then suddenly they start acting up again, and it can be so sporadic that it’s hard to know if what I’m changing is doing any good. Here’s I’ll list out what I’ve currently settled on, though. But first a description of the types of devices I’m working with:
- Custom-built hand-soldered ESP8266 devices that provide things like software PWM for LED strings, capacitive touch sensors, motion sensors and relays, loaded up with ESPHome.
- The exact same types of devices loaded up with custom firmware that I wrote myself (more on why this is interesting later).
- Several Kauf Plugs (PLF10 and PLF12) that run ESPHome because I really dig this idea of “here’s a great product but feel free to customize it and flash whatever firmware you want.” (Drop what you’re doing and go buy some of his stuff — not a paid advertisement.)
The Symptoms
It’s not an uncommon problem apparently, but the devices will work fine for a while (like days or weeks or months) but then suddenly become very unstable and frequently disconnect from the API or the network (usually both), and often frequently — like several times per hour. The WiFi signal strength didn’t see to matter.
Interestingly, in a couple of cases so far, I have replaced my own custom firmware (written in C — not ESPHome) with an ESPHome version that’s generally functionally equivalent. In one of these two cases, a previously stable device became unstable immediately and remained that way until I got all of my fixes in place. Maybe it was coincidence — not sure — but that was the first time that device had acted up in years, which makes me wonder if there’s something in ESPHome that’s causing the problem.
My Current Cocktail
Here are the things I’ve settled on, and so far things are looking okay.
- Wifi signal strength seems to correlate with instability, when the ESP reports -70db or worse.
- Power Save Mode: Add
power_save_mode: high
to the WiFi section of the configuration file. I haven’t looked into it yet, but rumor has it that there’s a bug in this mode setting, and that “high” and “light” are flipped. I think the default is “none”. “High” power saving turns off just the modem, while “light” power saving turns off the modem, CPU and clock. If you’re not super power conscious, this may allow the device to stay connected unless it’s off. - Single-radio 2.4GHz network: Turn off all the other radios. Honestly, I’m not convinced that this is actually a meaningful change, but this testing takes time.
- 20HHz Channel Width: Not 40MHz or auto — just 20MHz.
- Select a specific channel that’s not crowded: Common wisdom says to use 1, 6 or 11 because they don’t overlap. At one point I tested around this and couldn’t corollate the channel to the instability, but that was also before tried some of these other things, too.
Here are some of the other random things I’ve tried, in absolutely no particular order. I lot of this was because at one point it really appeared to be an EMI issue combined with signal quality. None of these seemed to make a difference.
- Ferrite cores.
- Move device closer to the router.
- Decoupling/filter capacitors.
- A couple of power smoothing options.
Try this:
Set arduino_version: latest under the esphome: section.
Set power_save_mode: none under the wifi: section.
Thanks, Jeff — I had originally tried power_save_mode none, but that didn’t do the trick for me and I ended up experimenting with other values. I think off was the default for my 8266s actually. The arduino_version is a great tip — I’ll give that one a try and update the post with the results. Thanks for the input!