Server.sleepfor questions

Just testing server sleepfor and i’ve seen that after restart the IMP’s clock (clock()) is restarted but the time goes ok since it probably resyncs the clock with the server.

Hugo promised startup without wifi in future releases (which means no more clock resync after deep sleep recovery) - can we base a functionality on a good clock after deep sleep recovery and no wifi?

Usecase: dual powered (main & battery) device which does timed jobs looses his main power and wifi.
Devices goes to deepsleep with server.sleepfor(1year or infinite) and remains on batery with only the RTC running.
After main power gets back, the device gots back from deepsleep (via pin1 wakeup) but wifi is not (which is frequent on remote locations), the IMP is restarted and should retake his basic times jobs (which means needs a good clock). Will this be possible?

Another question: server.sleepfor has some limitation at the seconds parameter? (like sleepuntil has 24hr) Or I can just set a year there, or even better there is infinite possibility (-1)?

Hugo promised startup without wifi in future releases (which means no more clock resync after deep sleep recovery) - can we base a functionality on a good clock after deep sleep recovery and no wifi?

It is true that time() is resynchronised with the server on each connect (and the imp always connects on a true power-on or initial plug-in). But the imp also has a hardware RTC, so time() should be correct in wifi-less “shallow wakes” (after sleepfor) too. The 6uA or whatever it is that the imp draws in sleepfor() mode, is enough to keep the RTC ticking.

Currently sleepfor(), like sleepuntil(), can only do up to 24h. This was intended as a “don’t paint yourself into a corner” feature, so that people don’t write code that does “sleepfor(a-year)” and then find themselves wanting to update the code on a remote device that won’t be checking-in with the server (and thus getting the updated Squirrel) for another year. However, with the advent of shallow wakes, users are nowadays perfectly capable of painting themselves into their own corners in exactly that fashion, so we might as well take the 24h restriction out.

Peter

Good news.
For tests the 24h limit is fine - if possible on long term we would need the unlimited feature and anyone else would need it who want RTC backup on a small battery. If the unimaginable happens the IMP still can be reprogrammed after reinsertion so it’s not dead for a year just we need to reinsert it right?

I’ve done some tests with a CR2032 and it does works well, the drain is below 1mA (my sources can measure only till that value) - I will need to setup a better environment to check the exact uA value. So RTC backup is doable with a small coin cell, the only issue is the 24h limit …