Im close to finishing my design which measures temperatures and controls an AC plug. I wrote the interface using HTML5, Css, JSand built the app using Phonegap build to Android. Right now the core ID and token are hardcoded.
How would my customers claim their Core and use my interface. Will they use the Tinker code to claim it,copy the ID and token into my interface every time they use my app. That would be a pain.
There is not much info on how the Tinker app works or docs on how to take the Core to production without being an engineer expert.
Please help on whats the best approach to take.
Thanks
Hey @applefarm, great question!
The spark cloud is effectively a convienent transport layer. It makes it easy to talk to and from the SparkCore over the internet. Currently there is no really good way to do what you want to do with just the spark cloud as it exists right now.
Assuming you are selling this product then I would suggest that you keep all the cores claimed to your own account and implement your own cloud proxy of sorts. All new customers would do is configure the wifi credentials (using the Spark Android/iOS App to configure the CC3000), load up your Android app, and be good to go. Behind the scenes you would have some kind of server you controlled call the SparkCloud using your SparkCloud credentials. That way customer wouldn’t have your access tokens and wouldn’t have to worry about flashing code or anything. To them it would just be an android/iOS app.
Does that make sense? Probably didn’t describe it well enough. Feel free to ask questions
1 Like
Your idea would work I think for larger users. Setting up my own Cloud and managing it seems too involve, not mention is the network went down.
I like the Photon better with its Soft AP. I’m going to assume Spark will add more features so that an Android can talk directly to the Photon without Cloud or SSID device.
Ok putting that aside, I have another plan. Lets say the user host his own webpage that is password protected and able to communicate to the Core using its ID and token. I think I can get that to work.
However, how would my customer update her Core when I release new firmware for their device?
This might be a dumb question, I use Spark IDE to develop the code and flash it to the Core. Breaking this process, where do I get the firmware to flash to my customers? and do I send them my firmware updates?
Thanks again
I would suggest that you still keep the actual cores themselves under your own control. Perhaps you would have a process so that users could claim the cores themselves if they wanted but assuming all of your users were OK with have you manage the firmware updates the next question, as you put it, is to figure out how and when to update the firmware.
I would keep myself a development version of the device you are selling and also keep a few beta testers on hand. When new firmware is to be released you would test it on your own local core/device. Once it works then I would move on to the beta testers. From there I would do a slow roll out to all devices. This could be accomplished a few different ways. I would personally write my own script to do it but if you had a fairly small numbers of users you could use the SparkCLI. Once the firmware is compiled you could use the following command spark flash CORE_ID FIRMWARE_FILENAME for each core you needed to update.
Does that help? Let me know if you have additional questions
Let’s say I do keep the Cores under my control, how do they claim the unit to work with their WIFI network using their SSID/PASSWORD . I’m missing something here. Is there a difference in claiming the unit and keeping control of the unit.
Please explain the process. When I use SparkCLI, I need to login with my account to access my Cores.
If my product can takeoff, it has the potential to sell a 100 units/month. This could turn out to be a challenge to manage with my account…
These units are not as easy to put in production without more serious software development.
Maybe my efforts will help others with IoT development, who are doing the whole process themselves because they don’t have the money to hire a team of engineers, designers, and customer service.
Thanks for all the help.
1 Like
For a backend intermediary server check out some of the online options- like Heroku for instance. They take a good bit of the stress out of running a server when you’re one of the “little guys.”