This is a request for clarification. I’m using the following code in my imps:
if (server.isconnected()) {
local newBssid = imp.getbssid()
...
}
I do plan to update the deprecated call at some stage with the appropriate reference to imp.net.info
In the meantime, I notice that my test at the top only filters out some situations where the connection is lost. I still get instances where server.isconnected() returns true, yet imp.getbssid() returns “0000000000”.
Is this simply due to the concurrent nature of the the wifi interface? Any test of .isconnected() is only guaranteed for that exact moment and no point after it?
Should I instead query getbssid immediately before the isconnected test and discard the value if the test fails?
server.isconnected() is focused on asking whether the device is connected to the server, which is not quite the same thing as asking whether the device is connected to the WLAN. The device waits 60s after receiving no data from the server before it actively attempts to get a response. If that request is ignore for a further 45s, only then will server.isconnected() return false. So after a disconnection, there’s 105s during which the device will return a router BSSID of "000000000000" but server.isconnected() will return true.
when WLAN loses beacons, it may start indicating no BSSID immediately. However, it doesn’t tell us the link is lost immediately as it tries to reconnect.
as soon as we get link lost, server.isconnected goes false, the imp starts background reconnect attempts (from the ground up - ie reboot wifi etc)
what I believe should be 60s after isconnected going false, if a connection hasn’t been re-established, the ondisconnect handler is called.
However, the bssid behavior is not tested specifically and so we wouldn’t be able to guarantee consistent behavior across different devices.
I’ve been struggling with that as well, but wasn’t aware about the getbssid() behaviour. Will that be the same with the new imp.net.info calls (ie is that returned table just a remapping of the same underlying logic ?)
If so, it may serve as an early warning that a connection might be lost which in turn allows to do some caching of information to be uploaded in anticipation. If then eventually the connection returns within the retry periods (and the .ondisconnected handler isn’t called) we can still do a bulk sync of that cached data. That’s better then relying on the .isconneced call which may or may not be valid within the retry periods resulting in data loss.
Very short Wifi outages do tend to happen frequently (especially if you’re bridging an outside region and it starts to rain) but only very few of them really mean a complete and longer term break of server connectivity, so it’s good that the disconnected handler is not too sensitive. That would result in a lot of false positives, giving our customers the impression the solution isn’t stable.
Would it be an idea to define a formal ‘connection loss warning’ handler based on this, or is the behaviour of getbssid not consistent enough for that ?
If the BSSID has gone to all zeros, then the link is pretty much gone - it’s just the wifi chip has not officially declared that yet (it’s still trying to find another AP on the same SSID to roam to).
As I said, this behavior is not tested and so may not remain consistent.
I don’t really understand what the early warning is for though? If the data is valuable, then you should be holding it until it has been ACKed by the agent (or an upstream service) in all cases, not just when you think the connection is going to go away. We have a class that helps with this type of scenario, but it doesn’t seem to be published right now. @ppetrosh might have a pointer to it.
In my case, it’s about maximising uptime and reducing time between ssid switches. If an imp is connected to a mobile hotspot, we want to switch to another ssid the moment it detects that the hotspot has gone.