Imp offline *** no network reconnection retry

I’m using my imp for a personal pool pump controler and water temp monitoring.
I notice since 1 week of usage that my imp is going offline for I don’t what reason after 1 days or 2. What I dont understand, is why the imp OS isn’t automatically reconnect to the network? To solve this, I must power cycle it and it goes back online after few seconds. So my WiFi isn’t the problem.

Are you planning to have a patch for this?

I think this is same problem I’ve been having.
So you’re not seeing it trying to re-connect every 10mins as it should?

You might find a solution in this thread but I’ve haven’t yet.

yes thas right. No retry at all. I’ll try what you suggest in the thread.

It doesn’t work. I implemented the server.onunexpecteddisconnect code.

I’ve got message 24/6/2013 08:18:55: Power state: online=>offline and nothing more.
After a power cycle the imp goes online as usual.

You have something else to suggest?

Sorry no my imp with the same issued broke again today.
Can only wait for the guys at e.imp to come online later.

Do you have any sort of “watchdog” timer (wakeup) that runs every 5 minutes or so?

Not any more as that work around shouldn’t be needed in the new release as bug was supposed to fixed :frowning: Probably worth re-instating it, thanks

yes I have multiple functions wakeup each 2 seconds and my water temp is sent to xively website. That’s why I know exacltly when the imp become offline.

hummmm. I hope the imp team will find a patch soon… I was expecting a more reliable connexion.

We’ve been looking into this, but can’t replicate the problem locally (I personally have imps at home that have been online for a month+, would be longer but I updated the sw on them).

We’ve got one known issue in 25 which relates to the TLS layer not reconnecting after a disconnect. It’s possible this is what you’re running into - though the bug has been there forever, release 25 treats wifi disassociations as full disconnects (requiring a full re-dhcp, etc) whereas this didn’t happen in all cases previously, and this could aggravate the issue.

I’ll PM both you and controlcloud…

I have a similar problem. I turn WiFi off at night for about 6-7 hours. Since rel 25 the Imp goes online=>offline and does not try to reconnect when WiFi is back. Hugo, is there a fix for this TLS layer issue?

@osherl That’s very interesting; part of our automated system testing turns wifi off then on and verifies that the imp reconnects. If you turn it off for a shorter period, does the imp reconnect?

I am having the same issue.
"Sat Jun 29 2013 20:27:04 GMT-0700 (PDT): Power state: online=>offline"
My Wifi was down for about 6 hrs. The imp has not tried to come back online.
I added this line:

server.setsendtimeoutpolicy(RETURN_ON_ERROR, WAIT_FOR_ACK, 200000) ;

to my latest imp code, hoping it wouldn’t reboot itself when it lost connection. I assumed it would keep trying to reconnect. It hasn’t yet.

@Hugo Yes. Even after 6-7 hours it is inconsistent (sometimes it reconnects).

Is there a way to do a “soft” boot. or partial boot of only the wifi components and software, leaving user memory untouched?

Yes, that’s disconnecting from the server and reconnecting. When disconnected, the wifi is powered down.

@mron the server.setsendtimeoutpolicy(RETURN_ON_ERROR, WAIT_FOR_ACK, 200000) won’t do what you think it does.

This will wait a long, long time for an ACK, but if there’s an error (server, wifi, etc) it will just return an error from the command that’s trying to send (eg agent.send or server.log etc).

This will NOT attempt a reconnect - you would have to register an onunexpecteddisconnect handler which then did a server.connect in order to reconnect. If you want the imp to retry connections automatically, you want to be using SUSPEND_ON_ERROR, where the imp will try for a minute, then sleep for 9, then try for a minute, etc.

FWIW I’ve rewritten the server.setsendtimeoutpolicy() page a bit, to make it clearer that it also (arguably, mainly) sets the reconnection policy. Code that sets a timeout policy of RETURN_ON_ERROR must then call server.connect() itself when it wants the connection to be brought back up.


I think I got it. the wifi signal drops out a lot where the imp is located. I’ll know soon enough if it’s behaving the way I want.

It just occurred to me that SUSPEND_ON_ERROR means suspend processing until the server acks. I want to continue logging data and stash it until the server is reconnected. I think I need to use RETURN_ON_ERROR and the whole server disconnect error handling Peter outlined. Is that correct?

That is correct.