power_save_mode logic is twisted in ESP8266

[konradmb]

Operating environment/Installation (Hass.io/Docker/pip/etc.): Not applicable

ESP (ESP32/ESP8266, Board/Sonoff): ESP8266

ESPHome version (latest production, beta, dev branch) dev branch

Affected component:

https://github.com/esphome/esphome/blob/5c86f332b269fd3e4bffcbdf3359a021419effdd/esphome/components/wifi/wifi_component_esp8266.cpp

Description of problem:

I've been looking through the power saving code for ESP8266 to find out what mode ESPHome uses and I've found this:

https://github.com/esphome/esphome/blob/5c86f332b269fd3e4bffcbdf3359a021419effdd/esphome/components/wifi/wifi_component_esp8266.cpp#L71

According to ESP8266 Low Power Solutions manual (page 9), the light-sleep mode, apart from disabling Wi-Fi for a DTIM period (this is the modem-sleep), "also powers off clock and suspends internal CPU".

So, the light-sleep mode is stronger than modem-sleep, but right now, when you set power save as HIGH, you get modem-sleep (lighter) mode.

Shouldn't it be the other way: modem-sleep is LIGHTand light-sleep is HIGH?

[probot-esphome[bot]]

wifi source wifi issues wifi recent changes _{^{(message by IssueLinks)}}

[CarlosGS]

Can confirm this. You are resolving two problems for me!

• Was getting many disconnections with the ""light"" mode. With ""high"" (modem) there are no spurious re-connections.
• My RGBW light bulbs and LED strips would some times flicker with the ""light"" mode. They work on 8266's software PWM and I assumed the ""light"" power saving mode was too much to ask for. Instead, there are no PWM random flashes with the ""high"" mode (modem mode) and the power consumption is well reduced (see below).

I have now set ""high"" power saving (modem) in all my ESP8266 devices and so far I cannot observe any problems.

Measurements

When starting with ESPhome I did notice the devices were getting quite warm compared to the manufacturer's firmware. After finding the power_save_mode settings I was always using the ""light"" mode and was noticing they ran much cooler (this is beneficial for the lifespan of capacitors, specially given the poor ventilation of most ESP devices). Now here are some measurements:

Tuya light bulb body (no brightness during test) off: 22ºC "light": 25ºC causes frequent re-connections, and some times PWM flashes "high": 26ºC with no re-connections, working OK none: 28ºC !! with no re-connections, working OK (approximate)

RGB strip chip temperature (no brightness during test) off: 22ºC "light": 31ºC causes frequent re-connections, and some times PWM flashes "high": 32ºC with no re-connections, working OK none: 37ºC !! with no re-connections, working OK (approximate)

In summer with higher ambient temperatures the problem gets worse.

As happens with ESP32, the ESP8266 should also have the modem sleep mode as the default in ESPHome. The increased component temperatures will otherwise reduce the lifespan of capacitors, causing premature device failure and more e-waste.

Thank you @konradmb for finding this out!

[CarlosGS]

I can confirm the findings after all this time using the power saving ""high"" mode (actual modem sleep). Absolutely no problems and measurably lower power.

Note that current users that try out the "light" power saving mode will quickly be discouraged, because currently "light" means extreme power saving for the ESP8266 (reduced CPU frequency, causing dropouts). Hence users won't even try "high", mislabeled for modem sleep power saving, which gives absolutely zero stability problems. (Modem sleep is a standard & robust WiFi feature that is already the default for ESP32 in ESPHome).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[CarlosGS]

~The simple solution is to swap the labels back to the logical name.~ (It would be a breaking change)

And as happens already with the ESP32, the default power saving for ESP8266 should be changed to modem sleep (currently mislabeled as "high"). Users would then benefit from the reduced power consumption & lower operating temperature. I must emphasize that modem sleep doesn't affect stability nor CPU speed, that's why we already have it as the default for ESP32.

Please write down your thoughts so we can arrange a fix.

[konradmb]

@CarlosGS I would do the same. The only issue I see is when someone had set power saving to HIGH and wouldn't read about this change, then they would get an unstable system after swapping.

The modem-sleep mode is stable for me too. It could be made default. I haven't seen any disconnections , high latency etc., which were often with light-sleep.

[CarlosGS]

Another option would be to mark "light" and "high" as deprecated, to notify the affected users, and define new flags that match the power saving modes of each platform:

• "MIN_MODEM" and "MAX_MODEM" for the ESP32
• "MODEM_SLEEP" and "LIGHT_SLEEP" for the ESP8266

This seems more cumbersome than just "light" and "high". However, it could help maintain coherence when new chips and power-saving modes appear.

[konradmb]

Well, introducing totally new labels is probably the best solution. Naming it the same as in official docs is a big plus, because this is exactly why I needed to check the source code - to see which label corresponds to which sleep-mode from docs. Then I've seen the twisted logic and opened this issue. :smiley:

[zanna-37]

Any update on this? it's quite confusing and I think that at least the docs should be fixed.

[Sammy1Am]

Just came across this myself.

Deprecating existing labels to make things more clear would be great, but I don't like the idea of having different yaml settings for different boards (sort of a big point of ESPHome is that it largely abstracts away the board-specific details).

Short of inconveniencing everyone by changing to an entirely new setting (e.g. having power_save_mode and power_save_mode_this_one_works_better), I vote for temporarily inconveniencing only ESP8266 users (to be clear, this is all of my devices) in order that things are correct/better moving forward.

I suspect the majority of users have either left the default (in which case this change doesn't affect them), or selected high because they're on battery power. Users using high aren't actually getting the maximum power savings they wanted anyway, so switching these around will give them power savings they wanted in the first place at the potential cost of stability 🤷‍♂️.

[travnick]

just putting here some reference: https://docs.espressif.com/projects/esp8266-rtos-sdk/en/latest/api-reference/system/sleep_modes.html?highlight=sleep#enumerations

There are two enums defined:

typedef enum {
    WIFI_NONE_SLEEP_T    = 0,
    WIFI_LIGHT_SLEEP_T,
    WIFI_MODEM_SLEEP_T
} wifi_sleep_type_t;

typedef enum esp_sleep_mode {
    ESP_CPU_WAIT = 0,
    ESP_CPU_LIGHTSLEEP,
} esp_sleep_mode_t;

I'm unable to find any explanation what the WIFI_LIGHT_SLEEP_T really is, and what's the difference between this and WIFI_MODEM_SLEEP_T and ESP_CPU_LIGHTSLEEP.

And if it's not enough, then there is additional enum:

typedef enum {
    WIFI_PS_NONE,        /**< No power save */
    WIFI_PS_MIN_MODEM,   /**< Minimum modem power saving. In this mode, station wakes up to receive beacon every DTIM period */
    WIFI_PS_MAX_MODEM,   /**< Maximum modem power saving. In this mode, interval to receive beacons is determined by the listen_interval parameter in wifi_sta_config_t */
} wifi_ps_type_t;

[travnick]

Here in the document, they use LIGHT_SLEEP_T as wifi_set_sleep_type() parameter (huh?).

Anyway it looks like, for light sleep it's required to have configured external wakeup (missing in ESPHome, in my opinion it'a bug since allow to put device in the light sleep without possibility to wake up) gpio_pin_wakeup_enable()

https://www.espressif.com/sites/default/files/9b-esp8266-low_power_solutions_en_0.pdf

[tikismoke]

Save me too, from 67°C to 55°C in winter in the attic for this shelly 2.5:

Wifi settings change just before 4am, same load since 21:00 (3 shelly gu10 in standby mode).