I deployed my first commercial embedded core today. Not as easy as I was expecting because I could not set up a new wifi (via the App) until I went through the full reset factory process. Not exactly convieniant when the core is deeply embedded into the delivered item. Is this the norm?
- did you use your user code and replace the factory reset image?
Wireless setup for Wifi credentials is not foolproof since it depends on the network environment and TI uses their proprietary protocol to perform this handshake…
Is this a general product or specifically used in an application?
Not sure I understand your question. I took the completed unit and installed it. Once powered up the core light was flashing green (no surprise because it was not signed into the local wifi). Next I started up the Spark Core app and tried to assign/claim the core onto the new wifi. This did not succeed. Only after I had stripped the unit out to be able to access the Mode and RST buttons was I able to get the core into some sort of mode where it was happy to accept the new wifi credentials.
I had not taken a laptop for the install because I was expecting to be able to add new wifi credentials purely through the App. Also I have not provided access to the two buttons, or usb, from outside the casing - this would be very difficult to achieve. My pre-check was to ensure that the wifi was using a channel below 12 and had a conventional security regime.
Hopefully my initial expectation is correct and it is possible to add wifi credentials solely through the app. Otherwise trying to reconfigure through buttons or any thing else complex in a busy public space is going to need more consideration. In this case the ideal would be to preconfigure the core with the target wifi credentials.
What @kennethlimcp is asking is whether you replaced the standard factory firmware (Tinker) with your own. I’m going to assume you have not.
Blinking green means that the Core is looking for a known wifi network, which is a blocking process. If you want to enter credentials with the app, you’ll have to be in listening mode (blinking blue), by holding the mode button, or through firmware by using this: http://docs.particle.io/core/firmware/#wifi-listen
Alternatively, you could program your credentials in code beforehand: http://docs.particle.io/core/firmware/#wifi-setcredentials
So he could either wipe the credentials before it ships forcing the unit to look or be in the mode for new credentials but could still run into a problem if the custom ever changes a password or SSID. The best solution could be to have an I/O pin that could be scanned and if held down call the wipe credentials function call?
Thought I had replied earlier but somewhere it got lost.
Sounds as though my best solution right now is to include a reed switch to allow reset without opening the box. This is a short term fix to a general problem - how to survive changes to wifi credentials. In my market the customers tend to subcontract out the provision of their wifi services so repairs or changes can be made sometimes without full appreciation by the local staff. Maybe I have to drop the wifi approach completely and switch to SD card distribution or use Electron (new bunch of issues?) instead.
I have never used Tinker. I put my own software onto the device via the IDE. To my old-fashioned mind firmware is whatever underlying functionality is put onto the device to enable the basic functionality my software draws on.
I’ve been struggling with the same chicken/egg problem. There has been a few discussion threads about soft AP’s, multiple wireless creds, etc.
Some problems are:
- the TI tt3000 process doesn’t appear to have a method that can be driven by a web app. It needs java / node / ios etc, which is not available on the new hybrid apps.
- Requires pressing the buttons to configure credentials. It’d be better to try current credentials for say 2 minutes then for a minute go to accept credentials mode.
I’d personally like for it always run its own AP, ie ‘[coreid]-setup’ whenever its wireless AP is not available. It could run a simple webserver that accepts json (user/pass/wifi type and your per device access token) so that you could run a simple hybrid app on your phone to configure the core. Your phone app would pass the core id to the your cloud service requesting the access token, your cloud would decide whether to provide it (ie via workflow approval to third party), and then would send it to the phone app to pass to the local AP. This same app could claim unclaimed cores if they were sent direct from factory to client and hadn’t been flashed.
Secure, easy. Please poke holes in my theory!
edit: Its unclear how the photon would know its in soft-ap mode. Is it always in that mode?
Some good ideas there, but alas not without issues:
-
the CC3000 / Core doesn’t support SoftAP mode, so that cannot be part of a solution on the Core.
-
Having SoftAP setup mode always available on the photon could be a possibility, However, we also plan to open up AP mode for user control, and allow for a custom SSID name. This would break the SoftAP setup process at present, which requires the name to be Photon-XXXX.
1 Like
What I forecast would happen is now happening. One of my customers is planning to change the wifi setup in the location where his device is operating. I think this is going to mean adding a new wifi server. Assuming he will be changing to a new ssid and password how can I prepare his device for the changeover. I need to be doing this remotely.
Hey @goingalong,
It is a problem. I had the same problem with the Core and I added a function that check if the WIFI is connected or not, and if not, you can enter the wifi credentials with CoolTerm terminal. I think it is an easy solution if you can connect USB from your device to the computer. Another option is to burn program with WIFI.SETCREDENTIALS() and then change the wifi.
I hope with the photon and the softAP it will be easier… I’m still looking for the solution.
If you still have connectivity, you could flash it with the new credentials by using wifi.setcredentials() (check the docs for the exact syntax). You could even add a function so you could change them by calling a function.
1 Like
Thanks for the replies. I cannot go with itayd100’s USB solution for a couple of reasons. Firstly customer staff are all doing their own jobs with no time for playing with computers (plus there is no USB connection outside the unit). Secondly the unit(s) are remote from me and I am trusting no-one. Consequently I guess that Moor7 has the best approach.
I have another unit in build so will try it with Moor7’s first. Once I know what the new parameters will be I can remotely flash ahead of time, which will mean that the unit will be out of action for a bit until the wifi is up with the new credentials. Of course once changed I cannot then revert back remotely if there is a problem!
I am beginning to think I need another solution. Maybe a cheap bluetooth unit tucked away and connecting to the net via ethernet and acting as a bridge to my functional unit. At least that way everything is under my control. Hmm.
Actually, the Core can store up to 7 different credentials, which it will cycle through until it finds an access point it can connect to. Entering the credentials is on a First in, First out basis, if I'm not mistaken. That way, you can enter the new credentials, but it will keep working with the current one until that disappears. It will then check if any of its other credentials is a match (hopefully the new ones).
1 Like