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.
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 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:
@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.
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?