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.