Is it possible for the callback on server.connect() to return anything other than SERVER_CONNECTED (5), NO_WIFI (1), NO_IP_ADDRESS (2), NOT_RESOLVED (3) or NO_SERVER (4)?
I’ve had a couple of occasions where 0 was passed back to my handler.
Zero is NOT_CONNECTED. There’ll be a symbol for this in the next release.
I’d guess this is due to wifi dropout or connection reset.
Thanks for response, it’s good to know that it means something. However, in my case, I think it’s neither wifi dropout nor connection reset.
On my desk I have a imp-card with a debug serial port connected to my pc. I’m monitoring a number of wifi-related details while the imp is either connected or disconnected. After an unsuccessful server.connect() attempt, I get a callback with the reason 0. After that, I cannot successfully attach to an access point until I pull the card out and plug it back in again. The imp remains perfectly responsive through the uart. I can query pretty much everything and get normal responses. I can issue commands for it to attach to a different network and force a server.disconnect() or server.connect(). It just will not connect to a known network even though it has the correct ssid/pw details. Is there any way I can reset the imp (or at least the broadcom chip) through the api?
You could try @aron’s trick to restart the imp, but server.disconnect() already turns off the wifi chip.
The next release works harder to detect and recover from wifi driver errors (which may also bubble up as NOT_CONNECTED). In the meantime if you can PM test code and logs we’ll try to repro the problem.
From my testing, I’ve tried server.disconnect() and imp.deepsleepfor() in an attempt to kickstart the wifi chip back to life, without success. Calls to server.connect() still fail and the callback still returns 0 after every attempt.
However, I can confirm that using Aron’s trick (implemented in device, not agent) does force the imp to restart and switch ssid/pw without a physical reset. This seems to be the only way to get imp.setwificonfiguration() to work. It is strange that imp.deepsleepfor() does not achieve the same thing.
This comment from mjkuwp94 on a different thread seems to imply the same thing.
As I recall it takes some patience waiting for it to connect and maybe? a power cycle but for sure I have witnessed this method work.I'm using a similar approach with a table of ssid/pw pairs, except I'll only attempt to connect to a different access point if it is visible in a scan.
Imps connect with a 60 second time out after a squirrel error. What time out are you passing to server.connect after a deep sleep?
Do all of your APs provide valid DNS?
I’m using 30s. I’ll switch it to 60s and repeat tests.
I’m using two wifi routers with independent ssids but connected to the same network, plus my android phone operating as a mobile hotspot. Other imps in the office connect to these access points (on powerup) without a problem. I’ve also been monitoring connections on one of the access points to see if the mac of my imp ever appears on its list of connected devices. It doesn’t appear until after an imp reset.
What settings are you using in server.setsendtimeoutpolicy()?
Peter
I’m currently using the following
server.setsendtimeoutpolicy(RETURN_ON_ERROR, WAIT_TIL_SENT, 10.0);
But, I may settle on a higher value than 10.0. I’m just using that because I’m resetting my wifi test units many dozens of times per day. As part of that, I get the units to power-up with known-bad wifi details.
I am making progress on this issue through the support channel at the moment (#1174).