[Solved] ESP8266 waking from modem sleep for longer than expected… any way to find out why?

ESPHome
1

Update: Got it sorted out, too much broadcast traffic on the WLAN. Moved my ESPs to another subnet with just them and no mDNS, it’s waking up much less frequently now. I haven’t done the math yet, but just looking at the scope I’d say I’ve cut my power consumption by at least 40%.

Trying to minimize current draw on a solar-powered ESP8266 project I’m working on. Deep sleep won’t work for my use case, so I need to keep the modem asleep as much as I can.

Based on the current draw, I’m seeing it wake up for about 90ms in line with the DTIM interval, as expected. However, periodically it stays awake for 10-30+ seconds. At first, I thought that it was something being polled by ESPhome, but it doesn’t correlate with network traffic.

Is there any way to identify why it thinks it needs to keep the modem powered?

1 Like
2

My config:

esphome:
  name: dev-esp-01
  platform: ESP8266
  board: d1_mini
 
# Enable logging
logger:
  level: VERY_VERBOSE

# Enable Home Assistant API
api:

ota:
  password: "<<redacted>>"

wifi:
  ssid: "<<redacted>>"
  password: "<<redacted>>"
  power_save_mode: high

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Dev-Esp-01 Fallback Hotspot"
    password: "<<redacted>>"

captive_portal:

With logging set to VERY_VERBOSE, I see the following repeated:

[09:30:57][VV][scheduler:152]: Running interval '' with interval=60000 last_execution=4294949649 (now=42353)
[09:31:00][VV][api.service:327]: on_ping_request: PingRequest {}
[09:31:00][VV][api.service:043]: send_ping_response: PingResponse {}
[09:31:06][VV][api.service:327]: on_ping_request: PingRequest {}
[09:31:06][VV][api.service:043]: send_ping_response: PingResponse {}
[09:31:15][VV][api.service:327]: on_ping_request: PingRequest {}
[09:31:15][VV][api.service:043]: send_ping_response: PingResponse {}
[09:31:21][VV][api.service:327]: on_ping_request: PingRequest {}
[09:31:21][VV][api.service:043]: send_ping_response: PingResponse {}
[09:31:30][VV][api.service:327]: on_ping_request: PingRequest {}
[09:31:30][VV][api.service:043]: send_ping_response: PingResponse {}
[09:31:36][VV][api.service:327]: on_ping_request: PingRequest {}
[09:31:36][VV][api.service:043]: send_ping_response: PingResponse {}
[09:31:45][VV][api.service:327]: on_ping_request: PingRequest {}
[09:31:45][VV][api.service:043]: send_ping_response: PingResponse {}
[09:31:46][VV][api.service:037]: send_ping_request: PingRequest {}
[09:31:51][VV][api.service:327]: on_ping_request: PingRequest {}
[09:31:51][VV][api.service:043]: send_ping_response: PingResponse {}
[09:31:57][VV][scheduler:152]: Running interval '' with interval=60000 last_execution=42353 (now=102359)
[09:32:00][VV][api.service:327]: on_ping_request: PingRequest {}
[09:32:00][VV][api.service:043]: send_ping_response: PingResponse {}
[09:32:06][VV][api.service:327]: on_ping_request: PingRequest {}
[09:32:06][VV][api.service:043]: send_ping_response: PingResponse {}
[09:32:15][VV][api.service:327]: on_ping_request: PingRequest {}
[09:32:15][VV][api.service:043]: send_ping_response: PingResponse {}
[09:32:22][VV][api.service:327]: on_ping_request: PingRequest {}
[09:32:22][VV][api.service:043]: send_ping_response: PingResponse {}
[09:32:31][VV][api.service:327]: on_ping_request: PingRequest {}
[09:32:31][VV][api.service:043]: send_ping_response: PingResponse {}
[09:32:37][VV][api.service:327]: on_ping_request: PingRequest {}
[09:32:37][VV][api.service:043]: send_ping_response: PingResponse {}
[09:32:46][VV][api.service:327]: on_ping_request: PingRequest {}
[09:32:46][VV][api.service:043]: send_ping_response: PingResponse {}
[09:32:52][VV][api.service:327]: on_ping_request: PingRequest {}
[09:32:52][VV][api.service:043]: send_ping_response: PingResponse {}
[09:32:57][VV][scheduler:152]: Running interval '' with interval=60000 last_execution=102353 (now=162353)
[09:33:01][VV][api.service:327]: on_ping_request: PingRequest {}

Neither the pings nor the interval timer correlate with modem power; DTIM spikes are every 1s or so, vs 6-10s for the pings, and the null interval runs every 60s, vs. an approx. 40s period for the longer modem activations.