Imp goes offline-requires power cycle -didn't before

My 25.2 imp has adopted a new habit - I am not sure at which release this started.

It is requiring a power cycle each time I get around to using it - I don’t use the device every day.

i added some code to log to the planner every 5 minutes but this did not change it. Most recently it ran for 12 hours before stopping and today for 5 hours.

from boot the log looks like this:

8/8/2013 6:18:04 AM: 8 8/8/2013 6:18:04 AM: 0e967a4 - Fri Jul 19 10:04:28 2013 8/8/2013 6:18:04 AM: 02bdb9e2b5cf 8/8/2013 6:18:04 AM: 28464 8/8/2013 6:23:04 AM: 42864 8/8/2013 6:28:04 AM: 42864 8/8/2013 6:33:04 AM: 42864 and on and on

and at the end the last thing I see is

8/8/2013 11:03:04 AM: 42864 8/8/2013 11:08:04 AM: 42864 8/8/2013 11:13:04 AM: 42864 8/8/2013 11:18:04 AM: 42864

I have tried sending new code to it and get no response. I am fairly certain that I used to tinker with this machine over my lunch hour.

I also have an imp running at work and that thing has never gone offline that i can recall.

What do I have to do in order to make it stay awake and online?

I have never used the sleep commands in my code.

This is the code I added to attempt keeping it awake

`function stayalive(){



That is the last thing in my program

A few of the common reasons this happens:

  1. while(1) loops.
  2. excessivley long for loops.
  3. Setting server.setsendtimeoutpolicy(RETURN_ON_ERROR, …) and never explicitly calling a server.connect() in code that runs after the device disconnects.

If you can share more (or all) of the code running on the device, we can more easily try to figure out if it’s something in the code, or something else (you can IM or email it to me if you don’t want to post it here).

I don’t mind sharing the code (attached) but actually I did find that I had added a server.setsendtimeoutpolicy statement. Strange I don’t remember adding that but I must have started trying to implement some of the new stuff. And as you have warned I did not have a server.connect statement to go along with it.

I’ll try taking that out for now and see how that goes - thanks!

Yep, take that line out (or change the policy to SUSPEND_ON_ERROR).

If there is a transient connection issue, because you don’t have an unexpecteddisconnect handler to force a reconnect, it will not attempt to reconnect (it’ll just return an error from any network operation, eg server.log, agent.send, etc).