All committers have signed the CLA.

What was happening is the node would not boot back up when sufficient power was applied, especially on a slowly rising level like you would get from a solar panel. Can you confirm this is not happening any more?

node would not boot back up when sufficient power was applied

@caveman99 This doesn't seem to be the expected behavior. The code tells the device to sleep for config.power.sds_secs which defaults to one day for routers and UINT32_MAX (effectively infinite time) otherwise.

If you've witnessed a node wake from the low battery state, it was likely a router that woke up the next day to check the battery level rather than waking because of the battery level. With that in mind, I can confirm my WisBlock mini does not correctly wake after config.power.sds_secs for unknown reasons, which is likely what they mean by "freezing".

Perhaps allowing super deep sleep when sds_secs is the UINT32_MAX default is a good compromise? That way nodes expecting to wake up regularly to recheck voltage (like routers) will not fall into this bugged infinite sleep while all other users that expect an infinite sleep will get exactly that :)

Now we'll only allow super deep sleep if "Super Deep Sleep Seconds" is set to the default of UINT32_MAX. Then it doesn't matter if the board freezes since it wouldn't be waking up for over 136 years anyway.

This avoids the known deep sleep bug on NRF52 while preserving the intended behavior for most users.

This was very problematic, can you verify this is not happening anymore?

Please read my previous comment. The latest version of this PR should make the board freezing issue irrelevant.

tested on my device,seems work

Can this be merged please? This simple fix is far overdue for something that could prevent battery damage. At this point I've shipped 80+ devices with this PR cherrypicked to 2.6.11 with no issue, so I'm fairly confident it works as intended.

@garthvh If you have an issue we can discuss it. Closing my PR without reading it is ridiculous.

I think the missing bit of information here is that RAK boards are intended to wake from deep sleep when the battery power exceeds 3.7v, regardless of what super deep sleep seconds is set to.

See https://forum.rakwireless.com/t/how-can-i-automatically-recovery-a-wisblock-box-from-a-low-battery-scenario/11352/3 for Bernd, a RAK engineer describing exactly the bug in question.

@jp-bennett reading that thread it seems to imply there is a hardware issue rather than software. The current expected behaviour is to sleep X seconds regardless of what board is in use. In the case of solar nodes just set SDS seconds to any non max value (or one day as is the current default for routers) and the low battery sleep is bypassed avoiding freezing.

On a side note, it seems strange to prioritize the uptime of solar nodes with undersized batteries/panels over the battery health and safety of all nodes.

I'm running this changes (cherry-picked) on 2.6.11 latest beta on my heltecs T114 and rak4631 and everything runs fine

I think that the hang you see not respecting SDS time is expected in a ROUTER node:
https://github.com/meshtastic/firmware/blob/develop/src/platform/nrf52/main-nrf52.cpp#L358

The device sleeps only if TRACKER/SENSOR. Otherwise it's powered off and will only be powered back on user button press.

@Joseph-DiGiovanni in this my PR (#7882) I do more than using the deep sleep, FYI.

Closing in favor of #7882. Thank you for the awesome work @viric