Handling a backup or second WiFi network details versus default blinkup settings

I have come across various examples in the forum that explain how to handle multiple WiFi networks, but just seeking some clarification on how the wifi details obtained through the blinkup process is handled.

For example when I use the blinkup process to set up a wifi network how / where is the wifi password stored as could not find a function that gives me the info and do these details get overwritten if you then change the wifi network details using any hardcoded information I have stored in the device code to cope with the disconnected state and then using the RETURN_ON_ERROR process.

How do I revert back to the default settings as per blinkup settings when my device disconnects from backup wifi network and then “sees” the default wifi network again.

Right now, you can’t do this. The SSID passed via blinkup can be read, but you can’t read the password for security reasons (otherwise a malicious device could share your wifi credentials externally).

The details get overwritten when you reset them manually.

We’ve discussed ways to implement multiple credential storage (via blinkup) and automatic network selection, but it’s a really complex thing to do right - hence why at this point we leave it up to user code.

Hmmmm. I think that is because you are treating both methods as the same. Blinkup should always be the default position and at the moment you are storing those details in pre-allocated memory which cannot be accessed via code.

The way I see it is that at the moment the blinkup process allows the wifi details to be stored on the device in special non volatile memory which stores the values and which can be accessed even after a device has powered down and then powered back up again. I would have thought then that with the other manual wifi connection methods you do not overwrite this data but place the new SSID and password in a special NV table which lasts as long as the device is powered. This way if the device is powered down it reverts back to blink up mode first and then in the code the logic can handle a switch over if that is required. Surely this can implemented or is there a catch with my logic.

A temporary ssid/password can be useful. I definitely see applications where a device may want to switch to a temporary ssid to perform some key operations before returning back to its default (blinked-up) ssid. Perhaps an arrangement when imp.setwificonfiguration(ssid,pw,save=true) accepted an optional 3rd argument, which, when false, ensures that the setting is not to be stored in non-volatile memory. However, all subsequent calls to server.connect() will use the temporary ssid/pw pair until the device restarts or imp.setwificonfiguration is called again.

Yes certainly like the above comment of having an optional 3rd argument which would determine whether the new parameters are saved and used permanently or temporarily.

Another option which may work is to allocate permanent non volatile (flash?) memory for storing any wifi details using setwificonfiguration method and then add in a new function which is used to tell the device what to do which contains both a flag (as suggested above) to tell the device whether to treat the new details as a permanent or temporary change and then also a pointer to either the blinkup wifi details or the setwificonfiguration wifi details stored in non-volatile memory. The question is whether this small reduction in flash memory to handle storing additional wifi details would cause a problem when uploading device code.

And wouldn’t it be lovely if the imp on startup could poll across several wifi details held in flash and pick the first that has a connection?

We have plenty of nv storage for parameters, but we don’t want to implement half a solution.

Temporary overrides are all well and good, but the holy grail is really the ability for the imp to be able to store several and select amongst them automatically. This is pretty complex, though - eg what if the strongest signal network fails associates and DHCPs fine, but fails to connect to the imp service? This should automatically be marked as down (for some period, at least) and alternate networks should be tried.

That’s really what we’re aiming at here.

Great to know that is what you are aiming for, and to know that when it comes it will be well thought out and robust.

@Hugo, we spent a few months tinkering with various strategies and arrived at the conclusion that favouring the one with the strongest rssi was not the way to go. I agree that you shouldn’t implement something rigid if it doesn’t cope with all scenarios. I believe electric imp can leave the AP candidate selection to the developer, but offering the ability to easily swap ssid/pw parameters gives us more flexibility.

That’s good input, but we have some scenarios where squirrel is not running (eg: firmware update) which we need to be functional in. Maybe multiple credential storage, with management by squirrel when squirrel is running?

I would not be in favour of automated switchover without some form of developer control on settings within the agent/device code. A workable solution would need to cope, and perhaps behave differently, with a momentary loss of wifi network connection compared to a permanent loss of a wifi network connection. As such I would think that a parameter such “number of retries” or a “retry timeout” would be needed in this case as I may not want my imp system to be flipping from one network to the next just because of a momentary dropped connection. Of course we may want to think about a hot swap scenario (e.g. based on signal strength) but I think that makes things way too complicated.

We really need to focus on the end user (as in a person who does not have access to the imp code residing on an imp) and how they can add in different wifi networks versus how a developer (as in a person who does have access to the imp code) can do it.

With end user in mind, I can only see two options at the moment, which is via blink-up or via an agent driven html page – which is what I am trying to do at present – which then sends details to the device.

With developer they of course have the option to also hard code wifi ssid and passwords directly in device code to get something connected. In this context they have the option to override blink up without too much problem, knowing that once done this will be a permanent change which overrides blink up details.

With end user, the developer has to set up a controlled process of managing the additional wifi details via html (if that is the only way to do it) but also a developer would not have the means of knowing what end user blink up details were. This is the dilemma for a developer as end users often want to be able to switch networks without having to resort to blink up.

Hence to make this work I would want to treat the blink up method as being the default network which can only change via another blink up. Then any other method of obtaining wifi details, such as through html page or via hardcoded parameters, should be treated differently and stored elsewhere. The question is why complicate this part by allowing a developer/user to store multiples of network details. Surely having one alternative wifi network connection details stored is a huge step forward in giving imp more flexibility. I would always advocate little steps to improve things otherwise you get extended delays trying to implement something quite complex.

The only other context to worry about is then how the imp manages its connection and how it deals with a loss of connection on the basis that it does not have foresight as to whether to keep trying to reconnect with same details or to then switch over and try connect with the new network details. Having more than two network possibilities then would only make life difficult as you would need introduce some form of pecking order with trying the next set of network connection details.

Then my take on temporary versus permanent deals with the imp power up scenario. With a temporary network change scenario, the imp would return to using its default “blink up” network when the imp device powers up. With a permanent network change scenario, the imp device would use last active connection details prior to power down when powering up.

Finally I don’t quite understand @hugo’s point about firmware upgrades and squirrel code. Surely when a firmware upgrade takes place the server only knows that the imp device is online and it does not really care which network the imp device is attached to.

Some good points raised. It’s my understanding that the broadcom chip already attempts to reconnect once a connection is lost. It seems to take up to 2 minutes of retrying after loss of connection before squirrel gets a chance to change ssid through server.onunexpecteddisconnect(). It’d be my preference to be able to control (in squirrel) how long the chip retries before giving up. NOTE. This situation is not the same as the timeout on server.connect().

Additionally, the broadcom chip (or electric imp’s interface to it) doesn’t appear to offer us any control over bssids. The chip switches to the strongest bssid regardless. We can’t blacklist troublesome APs.

We support multiple ssid/pw pairs and we have to convince customers that we have no interest in their passwords and that they are simply stored in the device (and nowhere else).

I’ve always thought it would be great to store up to 4 ssid/pw pairs in the ATSHA chip. One of those pairs would be the default pair that the imp uses on powerup.

@coverdriven the retries are actually within impOS; onunexpecteddisconnect() fires after 60 seconds of retries at an OS level. If you want to catch a disconnect before that, server.isconnected() will return false as soon as retries start. We have a feature in the queue that would allow you to step in at that point if necessary though, which would then allow you to work out your own retry strategy. The reason for the retries are that loss of a TCP connection is a fairly regular occurrence in the real world and this makes the recovery seamless for most applications.

We can force the chip to only attempt specified BSSIDs, but this is not exposed to squirrel at this point. However, once connected we then don’t have much control over whether the wifi chip will attempt to roam. We can set roam RSSI thresholds to prevent roaming altogether, I guess. We also have features in the queue which give you much more fine-grained information about the connection progress.

As only imp001’s have ATSHAs, this isn’t really a valid place to store credentials - also, credentials are bound to the imp vs the device. This isn’t a problem though as we have plenty of config area space within the imp’s flash.

@gerriko the issue here is that if an OS upgrade is in progress, and the AP being used goes away, the bootloader must be able to select an alternate set of credentials to complete the upgrade otherwise the device can do nothing but wait for the first AP to come back.

@Hugo. If onunexpecteddisconnect() is firing after 60 seconds then as far as I am concerned this is where I would want to handle wifi network changes within my code as this rules out the momentary loss scenario. It would be great if you could add in a 3rd policy to “setsendtimeoutpolicy” which would provide a controlled condition to make a wifi network change based on user defined ssid and password details (rather than through blink up method).

One positive to draw from your comment is that credentials are bound to imp and you have plenty of space on the imp flash to handle another set of wifi network details within the config space.

Regarding OS upgrade, I don’t see it being a major issue to simply wait until network recovers. You already have to deal with issues such as if the user unexpected powered down the device during an OS upgrade.

So the big question now is to ask when can we expect this backup/2nd wifi network functionality to be included.

You can’t register a handler with setsendtimeoutpolicy() because code would be running at the time a timeout kicked in, and the VM is not reentrant (eg you did a server.log, and during the process of trying to send the log to the server an issue was encountered).

This will be a future release; it won’t make release 32 for sure. Later releases are likely to add this in pieces, eg we are likely to provide granular connect status first, then specific BSSID joins, etc. Multiple blinkup credentials are likely quite a way off.