Assuming your solar node battery is dimensioned for 3 days without sun and you want to bridge 7 or more days.
I have extended the BMS in Meshtastic for myself to reach my solar routers and the meshnet for several days when the charge level is low.
Instead of fully discharging the battery as before, my nodes switch to a time based interval below a defined charge level (e.g. 30%), which only switches on the nodes on for 5 minutes every full hour. This means that the nodes and the mesh can still be reached at regular intervals. In combination with Store & Forward, direct messages can be exchanged in a buffered manner.
This reduces power consumption by 90%. The remaining 30% is then sufficient for a further 3 days darkness. In addition, only 10% solar energy is required to maintain this operating mode permanently and your node will run weeks of cloudy weather.
The current battery management is simple and switches the node off at 0% battery charge or <3.1 volts. As a ROUTER, the node starts automatically after 24 hours, but CLIENT & co remain FOREVER in deep sleep.
My proof of concept is compatible with normal nodes and apps. I interpret existing power management parameters for configuration. The feature can be activated and deactivated, the limit value for continuous operation can be defined from 10% to 90% and the minutes per hour from 1 to 59. You can also control whether the NodeDb is saved with every shutdown or less often or never.
The nodes should run for at least 5 minutes every hour to update the time from position messages from other nodes with GPS or NTP.
You don’t have to wait 3 hours for nodeinfo from neighbors. Your node sends its own nodeinfo every hour after the resume and neighbors respond after 30 seconds with their own nodeinfo if they do not yet know the nodedb.
I tested the feature successfully for weeks. The mesh network and routers remain accessible even when it’s cloudy and the battery charge is low.
There is now deep sleep and timer based resume, but you can light sleep with micro amps. My fork isn’t not designed for RAK, just for power hungry ESP32.
