Just an observation, once the hardware is working nicely, it often takes more software to manage that hardware 🙂 – it’s a broad subject when talking about power – the battery voltage encodes battery type , solar panel sizing, solar aspect and vegetation coverage, and when is the power used – all to get the readings to show reliably on the web through all the seasons!!
I include a “sample number” or sequence number in my recording, so I can easily validate the data (missing sequences) and processor resetting. (sample number goes to zero) . A sample number might help show happens when the dates jump. Its ProcessorStats_SampleNumber() part of ProcessorStats()
I also found in early testing, I was getting resets at sunset (!) with small batteries, and standardized on using a 4.4Ahr battery. With a good solar aspect on a 2.5W solar panel, it charges in 8hours . Of course winter may not have that good a solar aspect, and typically has less sunshine unless its on the equator !! so I oversize the panel a little if I can, eg 3~5W
One thing for sure is that if the battery runs down completely, its a software issue on how it powers up and recharges the battery, one of the challenges in a remote solar powered logger. The “sample number” does help understand what is going on.
For my systems, it would take half a day to go and replace with a fully recharged battery (and who pays for all that time) – I upgraded the software to better manage the voltage. I also use “reliable delivery” of readings to the web, so when the voltage is low ( I use 3.8V on 4.4Ahr) the rest of the power is reserved for just reading the instruments. This can keep it working during a two week storm with no solar. Then when the sun comes out (and the solar panel hasn’t blow over) the battery charges back up, and it transmits all the stored readings. The software is on my fork, (which anybody is welcome to use) and or could be migrated back into the main.