Does deep sleep has any effect on attached sensors/devices? (e.g. SCD41 or OLED)

[dannyyy]

Hi

I have two I2C sensors attached to my ESP32. Once a SCD41 to measure temperature, humidity and co2 and a BMP180 to measure air pressure. I'm playing around with deep sleep to find a proper solution to operate in battery mode for a longer period of time.

Does someone know, what happen to sensors if the ESP32 goes to deep sleep? The sensor themselves are connected to the 3.3V pin of the ESP32 and keep powered up constantly. But is there a reduction of power because the sensor also go in a deep sleep state? Or does the regular update frequency (for SCD41 every 5s) of the sensor keep in place?

Because the mentioned sensor has an amazing long response time (120s for t63%), deep sleep has almost no impact, because it needs to run for 4-5min to get proper readings. Is there a way to let the sensor untouched and to continue the reading after deep sleep? At the moment I guess, there will be a "reinit" which causes the sensor to reset and start from scratch. The initial 5min after a hard reset isn't an issue. But having 5min runtime and 10min sleep is.

What about attached displays (e.g. SSD1351 SPI)? Are they consuming less while deep sleep? Before deep sleep I do a id(myoled).turn_off(), but not sure whether the a power saving mechanism behind or just clean all lighting pixels.

[hindenbugbite]

I am also interesting in learning more about how entering deep sleep interacts with components. I believe the best case scenario is for a single thread where components update once by using a flag and checking the wake up reason, then reset the flag and trigger deep sleep again. This would ensure component updates are completed before entering deep sleep. But I have a scenario where I might enter deep sleep based on an external asynchronous pin event while an AHT10 is running with its own update_interval. Is this a bad combination where deep sleep will have higher priority and cause an incomplete component update?

I'd like to gather some info that might help update the deep sleep documentation. Maybe the best practice for deep sleep is to always wrap sensor updates in a separate interval component that can checks for any events that can cause deep sleep. In essence "synchronize" the sleep event with other components.

[ssieb]

An "incomplete" update isn't possible. Either the data is collected and sent or it isn't. What are you thinking would happen?

[hindenbugbite]

The scenario I am thinking about involves an external device that requires a long delay to return data and if it is possible for deep sleep to interrupt this polling for data. The AHT10 page specifically mentions that it will block for longer than 20-30ms which made me question if it could be interrupted when a scheduled deep sleep "run_duration" expires. It makes sense that at a high level a component update is likely a blocking function and won't exit until it is complete. Maybe the missing piece is my understanding of how ESPhome handles tasks and if a component blocking is absolute so any other timers and intervals, including deep sleep, will only be evaluated after the component completes?

I've explored just enough of ESPhome to make me think it could operate with multiple threads. Those threads might have different priorities which is how I got here. The risk might be higher if timers and events were interrupt driven that can cut into any thread.

[ssieb]

Yes, sensors are not allowed to block for that long so it might be in the middle of a poll when the ESP goes to sleep. What is the problem with that?