There may be situations, especially when enabling offline operation, where local WiFi has failed and a customer needs to access his Imp-based device for start-up or configuration. In some cases, the customer may be using an iPhone app to interface with the device. In the absence of normal WiFi, the customer could enable their iPhone hotspot to allow the device to connect to the Internet (assuming the customer is near the device). If the Imp could remember two WiFi configurations, it could then connect to the hotspot rather than its normal WiFi for temporary communications.
Multiple wifi configs is on the wishlist (also good for: cars that join wifi at home and at the office)…
A coworker and I were just discussing this application today. It could be a car starter and more.
also I take my projects home and back to work.
even one added configuration would be huge.
Poke! Any ETA on this, Release 12? Would be invaluable for my application.
This is further out; not likely for a couple of months yet. The “running with wifi off” bits are due much sooner.
I there a date when multiple WiFi setups will be possible?
With release 25 you can save multiple wifi parameters (within a function). Example, have it try the normal one, then upon failure try a second one (stored in a table or even just the logic). I hope to implement this soon!
I want to try this also. But how do you detect when the new wifi config paramaters succeed or fail? Do you need to use a timeout and poll the connection status?
I am going to try answering my own question.
I will use imp.setwificonfiguration() then server.connect()
But this presumes I am disconnected in the first place.
When the imp first powers up, if it can’t find its existing wifi connection will it ever quit looking and start running old code? I think it wont right? So I need to make sure I start connected and then never lose power after that? What if my Imp does lose power? Is there anyway to remotely recover? or is a local blinkup the only way?
Server.isconnected will tell you if you are connected. You can change the WiFi params while you are currently connected.
No remote recovery. Must ensure WiFi params are correct or else will have to blink up. From cold boot must connect to server to run code. Future release will allow code to run immediately (Hugo has stated in other posts).
@duppy the next big release has “run code from cold power up”, whereby the imp will run stored code even without wifi from a cold power up.
Currently, it’ll run code on warm boots only - on a cold boot it MUST talk to the server first to verify the code is valid.
If I configure electric imp with some X Wi-Fi network, then I try to use it with another (Y) Wi-Fi network, will it work or does it need to be configured with new Wi-Fi network (Y here)?
If you wrote some logic with the Y network ssid and password stored on the imp code before you tried to connect, yes. You have to write a function to notice the network disconnect and then try previously stored ssid and passwords.
You can’t just blink-up on X network and bring the imp from X to Y and have it connect to the server. Yes the code can still run internally, but will not connect to the server.
Would it be possible to setup the imp to connect to any open WiFi signal? This would allow the imp to be mobile across multiple WiFi connections without needing to be configured for each possible link. I can see an app where you may want to get information from the imp/device but it is not in one of the WiFi sites you have setup. Just a thought
There’s an wifi scan API coming in the next big release, which would allow you to do this.
Is there a ETA for the next big release??
New Question (but very related). If the Imp loses power, when it is powered again it must connect in order to get code.
What SSID will it scan for? The last SSID received via blinkup or the last SSID used with imp. setwificonfiguration() ?
My wish list for cold boot behavior.
- imp attempts to connect to last succesfully blinked up SSID. (this is existing behavior, I am including it to document existing behavior, right?)
- if that fails, imp attempts to connect to last blinked up SSID that made a succesful connection. Example, it is possible that blink up succeeds but that the imp never connects to that SSID. Imp should remember the last SSID it succesfully connected to.
- Remember more than 1 last succesful SSID and try those in order.
- Remember last (or longer history) SSID set with imp.setwificonfiguration()
- Add an API to specifically write a prioritized list of SSID + password to NV memory and try those in order. Blinkup would always be able to override. Last blinked up could always be at the top of the list.
Any ETA on next release?
It will connect to the last wifi configuration - either set by blinkup or the setwificonfiguration (setwificonfiguration updates the config page entry in the imp - it’s not a temporary change of wifi settings).
We only support one SSID in the connection list right now.
Next release is going to go out to people who volunteer to test it in the next week I think; we’ve been testing the major parts of it for a month or so now but want to get some last bugfixes in there for things that have been discovered recently.
Sign me up.