Well yes, that’s the idea to help bullet point 2, working on it. I’ll try to tackle it a bit today
2 Likes
I would like to be able to do this without the end user 'claiming' the core. It needs to remain 'owned' by the product company so it can be updated remotely and controlled by a central management server communicating with the cloud.
That’s how it should be setup (in my opinion).
The process goes like this:
- Company receives SparkCore
- Company claims SparkCore (which requires them to set it up to their wifi)
- Company installs SparkCore into Product
- Company flashes the SparkCore with their firmware
- Company clears the wifi credentials (can be done using the MODE button I think)
- Company ships product to consumer
- Consumer powers on device and configures the Wifi (this step is slightly unclear)
- Everyone is happy.
I’m working to make Step 7 easier
3 Likes
@harrisonhjones
One more question - is there anyway to get the MAC address of a core w/o having an internet connection? Everytime I try and get the MAC address from the core with the WiFi either off, or not connected I get 0:0:0:0:0:0. For customers that use MAC address filtering there is no way to add a core to their network 
I guess one solution would be to pull the MAC while the core is on the company network (prior to shipping) and print that onto a label for the end user to use.
Hi @mtnscott
The MAC address shipped with the core is in a TI owned block but that MAC address is writable and for a product I think you should own your own MAC address range and set that address in the “factory” for your product. That way you can also track it more easily.
You don’t see Apple or Android or HP products with Broadcom MAC addresses 
2 Likes
No it does not.
The customer’s ap communicates through the cloud to access data. That ap uses the accessToken and the coreID. So if the token is good for 6 month, how do I update the token if it’s hardcoded into the ap?
Thanks
I guess I’m a little confused on what you are getting at.
There are multiple potential areas here. Which are you interested in?
A, getting a core online in a production environment? (setting a customer’s WiFi credentials)
B, communicating with a core in a production environment using a custom android/iOS app
C, something else?
Harrison you nailed it perfectly. This is EXACTLY what we need. Also you are right the reset of wifi is very simple once its flashed with firmware
Yes. communicating with the core using a custom android app.
Basically,my core measures, temperatures and humidity, and controls a relay.
The app collects these values and displays it in a chart. I was using the spark cloud for communications.
Should I do this another way?
Thanks
What are you getting at? The WiFi credentials have nothing to do with the core’s cloud account. Setting the WiFi credentials using a USB connection currently does not require the access token. So what we are looking for is a sample app that will let an end user configure the WiFi AP such that the core can get online. The core is still ‘owned’ by the company and the company still has all access to the cloud reference of that core.
Maybe I am not understanding your concern?
2 Likes
I have an android app for my personal spark stuff. I didn’t feel like hard coding my credentials into the app to allow it to automatically get a new token when the current one expires, and I’m WAY too lazy to constantly update my app with the new token… So instead I just use Google Cloud Messaging, and a local server.
My local server stores the current token, and the expiration date. Whenever it gets close to that date it requests a new token, and then sends that token out to my app via GCM. The token is just stored in shared preferences. The app can also ask the sever for a token update at any time as well, and that info is sent in the same manner.
You could probably do something similar. All they would need would be to setup an account on whatever your server was.The whole thing could probably be rolled into whatever “step 7” improvements @harrisonhjones or someone else comes up with.
This was my idea for makers who want to integrate the spark core into their hardware and have the user flash the core with what is needed :
Good suggestion but its not for me. I am building a standalone product and need my own app.
Thanks s…cites,
Now that makes since. You kind of worked around the token renewal using GCM as a backdoor. This way your app remains constant.
Sorry but I think, I just got it.
I was thinking of the spark cloud as having a different function.
The S.cloud is used by the manufacture to control it’s core’s, maybe even to update the firmware and should not be shared with the customer’s app.
Yes, that’s usually the case given the security issues with embedding tokens in customer apps
I know a bunch of people have mentioned these ways i various places, but I thought I’d state them all together here. I ran a little test pretending to be a customer. This is how they could set their wifi (
First I loaded my program on the core, then I wiped the wifi credentials. Then I “shipped” the “product” to my customer. I reset the wifi these three different ways:
-
I used the serial terminal connected over USB. Not that hard IF the user is ok with serial. You could write a small program to do that for you.
-
I used the spark.io app to “claim” a core. Once it connected to the network, I just canceled out before trying to claim the core. This worked fine but is a pain since the “customer” would need to create an account for the spark.io app.
-
I used the TI app. This worked fine as long as the customer was able to follow the directions and enter in key and the device name. If the device name did not seem to be important. This process could be made pretty easy with your own app using the TI libraries. Supposedly TI has a web interface for this too.
So something that would be really nice is for someone to write a simple web app that could be branded to allow people to have a simple “app” to do #3.
So something that would be really nice is for someone to write a simple web app that could be branded to allow people to have a simple "app" to do #3.
That's what I'm trying to do when I find some free time
I am not sure where this ended up. It seems that the only problem is that the Spark app first asks for your account credentials and then for your wifi setup. Why not just reverse the order? Have it first ask for wifi setup and then it can connect and see if that core is claimed and if so, you are done. If not, it will ask you to login or create an account. Maybe that is what is being proposed… What is a reasonable timetable for getting this done? Also, will the Photon be compatible with the solution?
Tom
1 Like
It's a little more complicated than just switching the order unfortunately.
The Photon will use a Soft Access Point mechanism instead of TI's SmartConfig, and they've said that there will be an SDKs for Android, iOS, and even Cordova, for integrating that functionality into your own app. So no, the Photon will not be compatible with this solution.
+1 for hearing how the work on the app is going