[Feature Request] Handle Light Sleep or Deep Sleep

[txf-]

Is your feature request related to an issue you've encountered? If so, please elaborate. Given the fact that there are several tasks running in parallel it is hard to determine as to where one can put the device to sleep. Should each task be suspended one-by-one and then sleep should be handled in the MQTT process loop? presumably if one would like to opportunistically enter light sleep MQTT keep alives periods should be considered.

Describe the new feature request In the example it would be nice to have a hint, or have special events to indicate when the best time would be to sleep, if desired. As there are a lot of abstractions away from a single loop, there could be a central way to trigger it, possibly in the agent?

[archigup]

Hi, could you explain the use case a bit more?

If I understand correctly, the intent is to get the device to go into sleep between receiving MQTT messages?

[txf-]

Actually, in my specific case is the device will have periods of activity where they're sending lots of sensor messages, and then variable periods of inactivity, where they're not taking any readings or sending anything.

However the device needs to be able to wake up from an external gpio interrupt and resume taking readings and sending that data.

If my device needs to receive any data I will schedule it to fetch it during periods of activity.

I'm just looking for any guidance as to what tasks I should suspend and where would be the best place to call light sleep. In my case, deep sleep is probably out of the question as it would take too long to reboot, but light sleep with the modem off would be a reasonable compromise.

[archigup]

For either sleep, you should not need to suspend any tasks. No tasks will run while the device is sleeping.

[txf-]

For example, would MQTT keep alives be scheduled to be sent by the device if it enters light sleep? Or would I need to set up a wake timer?

[ActoryOu]

Hi @txf-,

It depends on the definition of light sleep. As @archigup mentioned, if all tasks are suspended, no tasks will run. Referring to the example provided in this repository, a separate MQTT agent manager task handles all commands by calling MQTTAgent_CommandLoop. In that case, this task must be running to send the MQTT keep-alive ping message to the server when necessary. @archigup, Please correct me if I'm wrong.

Thank you.

[txf-]

In that case, this task must be running to send the MQTT keep-alive ping message to the server when necessary.

Yes that is the kind of thing I'm mostly concerned about. Does automatic light sleep (the Freertos tickless idle) contemplate the scheduling necessary for the device to wake in time for the command loop to send these messages?

[ActoryOu]

The behavior may depend on the receive timeout setting, which is 1s by default. If the receive timeout is configured to be shorter than the keep-alive period, it could trigger the process to maintain the MQTT session active.