Bug in server.sleepfor(seconds) for large values of "seconds"


There appears to be a bug (I think I’m on Card OS 5) when using server.sleepfor() for very long intervals (I’ve tried 1 month and 1 year). I basically want to tell it to go to deep sleep mode and only wake up on a rising edge on pin 1. So I tried to pass a really large value to server.sleepfor (2592000 for 1 month or 31536000 for 1 year). The Imp goes to sleep but wakes up in just a few seconds (maybe 4-5 seconds). Is there a limit to the values passed to server.sleepfor()? How do I make it sleep forever (that is only wake up on pin1 activity, not by timer)?

Currently it’ll sleep for a maximum of one day. In general, you want a device to wake at least once a day so it can pick up messages queued on the server for it.

Is there a reason you want it to sleep forever apart from a pin wakeup? Checking in is rather a good idea so you can tell the device isn’t actually dead (eg it can report its battery level).

The reason is that (for now) I can’t tell what has caused the wakeup (pin1 going high or timer expired). I know this is going to be implemented in a future release, I just wanted to disable the timed wakeups for now for testing and reimplement them later when I can tell them apart from pin1 wakeups.

BTW, if 86400 is the maximum (24 hours), it should really throw an error if you use a larger value, not wake up after a few seconds.

Yes, that’s a bug, sorry: it should sleep for 24 hours in that situation. Fixed in the next release.


Peter, any chance for a way to make it sleep indefinitely (maybe sleepfor(0) or sleepfor(-1) or similar)? I understand what Hugo said (that it’s a good thing for it to wake up every now and then), but I can definitely see cases where the developer would not want it to wake up unless some external condition is met (for instance when it uses a battery that charges from a solar panel and the charge controller is the only one knowing if the battery has enough power to complete whatever reporting operation it’s meant to complete).

Is there any technical (or commercial) reason for it to wake up at least once a day?

No reason for it to wake once a day apart from sleepfor() was based on the sleepuntil() code which works on a particular hour/min/sec.

In general though, when things are deployed you want to know they’re ok - even if they’re only used occasionally. eg if a router went down, you wouldn’t know until the device woke up and failed to connect.

For very low power devices, shallow wakes (which don’t bring up wifi) will be many times more power efficient. You could shallow wake once a day and if there was enough power margin, connect to wifi and send status. These are coming soon.

I had the same issue with the imp waking up immediately if I asked for 24 hours or more. For my current purposes I am happy for 24 hours being the maximum but I don’t see why it should be unachievable to sleep longer.

My problem with the 24 hours maximum is that there isn’t a way to tell what woke the module up. This is actually kind of funny, when my test Imp wakes up, it triggers a call to a server that makes a call to my cell phone as an alert. I accidentally left it powered on a few days ago when I tested (it was in deep sleep mode so the LEDs were off) and 24 hours later I jumped out of my bed when my cell phone started ringing, indicating an alarm… I knew it wasn’t me testing, so I though this was for real :)… then I realized it was exactly 24 hours after my previous test and looked at the Imp …

Please give us a way to tell what woke it up or let us sleep forever (not just for 24 hours).

This is coming, until then you need to ensure the external circuitry will either stretch the wake signal or provide a way of latching the wake condition (eg: on hannah you’d ask the IO expander if it generated an interrupt… well, pin1 would stay high until you cleared the interrupt)

That’s actually a great idea about using Hannah for this - I didn’t think of that. I hate solving software problems through hardware and this is a proof of concept for now, we only plan to go commercial with it sometime early February 2013, so I guess we’ll show it off on the Hannah or keep it in WiFi powersave mode for now and go to full deep sleep when we can detect a button press wakeup vs timed wakeup.

Thanks Hugo!

We’re somewhat limited by the fact the processor doesn’t latch the wakeup state, so it’s a manual software operation at boot time - so there will always be a length of pulse which, if it occurs at precisely the moment the RTC alarm is due, the software can’t distinguish reliably. If the processor wakes and doesn’t see the pulse - but the RTC alarm isn’t due - then the wake must have been the pin.

If you stay above this minimum pulse length then the software can always work out whether there was a transition. We’ll define this length when everything is implemented; It should be under 20ms.