Hi.
Quick question to see if someone has a good solution:
I am trying to do a project that requires an iPhone pairing to a SparkCore… Multiple SparkCores can pair to multiple iPhones. (Many to many). However each iPhone has to know the spark device name and the spark device has to be in pairing mode to be added to the iPhone app…
Here’s how it works in a nutshell:
You put the Core in a special mode using a button (Pairing Mode)… When the core is in that mode, you are allowed to add it to your app for quering and controlling some features of my firmware…
-The paring sequence goes like this:
Put the core in pairing mode.
Go to the app and type the core name and then press pair in the app.
You are done!
I am handling this right now with logic in the iPhone… Where the iPhone asks the spark core if its in pairing mode… If it is… It will add it… if it’s not… It will tell the user that the core is not in pairing mode. All iPhones share the same usr/pass spark cloud account of me the developer… (I don’t know if this is a good idea for a small batch deployment [50 or so devices], but I don’t know how else to…)…
Here’s the issue: In my view… this is not safe! Anyone can query the spark device even if it’s not paired. Because only the iPhone app knows its not paired. (When I say anyone, I mean anyone with access to my spark cloud account, which is unlikely… But still it doesn’t sound right)…
Since we don’t have access to the spark core server to add some middleware logic… Does someone have a better idea for me to implement this feature?
Another idea would be for the spark to remember a token from the iPhone app when initially paired… but this will limit (maybe only in theory) the amount of iPhones that can be paired, and it would require writing to the persistent memory. (This is a feasible solution in my view, but maybe there’s another!)
Another way is some custom server (local cloud) implementation of my own… Or maybe a way for my clients to have their own account in spark cloud… Which I don’t want them to go thru the hassle of registering their personal information just for pairing… Specially if they have to go to spark site to do it!..
I want a quick… Press the device pairing mode… Go to the app, type the device name and Boom… it’s paired!.
Is this only over the internet or in your local network (wifi router)?
What if more than one Sparks are in pairing mode when you try to pair through the iPhone? Will only one of them get paired or will all the Sparks get paired?
Edit : Make that 3 questions
Do you want it to pair with the iPhone Device (with its unique ID) or do you want it to pair with a User-ID (that means I can use your iPhone and use my Username Password and I will get all the Sparks that are paired with me)
No problem. Because I need the spark device name… I envision claiming my devices and naming them with a serial number of my own. (Unique). So the person has to have the device in pairing mode AND know the device unique name (serial number).
I would rather pair it with the iPhone. So users won’t have to go thru the hassle of registering a new account with spark.io only to claim their devices. Plus! one SparkCore can be paired to multiple iPhones. So in that case the users have to share the same user/pass… Which seems like a not so elegant solution… At least from my thinking… maybe in practice this won’t be as bad… But it’s an extra step and takes time. Il rather ship my iOS app with a pre configured user/pass and my spark devices with a unique ID and claimed to my account… (Unless you recommend otherwise of course!)
I broke my head trying to figure out how to pair the iPhone and the Spark without using Access Tokens being stored on the Spark and also without using any extra custom Server. I got a semi-amateur solution but it is not feasible because it under the assumption that the App will never have its data cleared or be uninstalled. If they do clear the data, then they have to re-pair with every device again. I don’t think that is the use case right?
Access Tokens - I really dislike storing access tokens on the Spark. Flash memory has limited endurance, long look-up times, and flash memory is easily hackable.
Cutom Server - I’m tending towards having a Custom Server (which handles only user registration, access tokens, sharing sparks) for one major reason. If your App is uninstalled or has its data cleared, then the only way for you to get the list of paired Sparks for your iPhone device (on re-installation) is from a nice database stored on your custom server.
Additional advantages:
You won’t have to rely on iPhone device id and can maintain Usernames and Passwords instead for not being limited to one device.
Access token implementation is a lot easier and better
Let Spark Server handle the functionality related communication between Spark and the iPhone.
I am not liking the idea of having multiple servers… Too many points of failure. If this is a feasible route, I would go with local cloud customized for this… But the code is very extensive and robust that it would be difficult to extend without braking future releases…
Right now in my corner, the best option in my mind is the token in the core… A simple reset should not erase this and a hard reset will most likely be a wanted behavior to reset even all access tokens…
How many write cycles do we have?
Can the memory in the CS3x chip be accessed thru the core?
Thoughts?
I had been thinking about this and I think you are right… Yet I don’t know if the best thing would be to run a version of the cloud extended by modules or something… Or two servers… One for pairing and such, and the other as the cloud.
However just wanted to let you know that I think you are right.
I think you should start off with the simplest, fastest and safe way by hosting a server for Pairing and User registration etc and let Spark Cloud take care of communication for you.
This way the custom server that you will host is quite simple and should relatively be bug free and you don’t have to worry about the Spark Cloud having issues at all. Also you don’t have to “share” your cores or your “spark user ID” with anyone.
In the future you can move onto hosting your own Private Spark Cloud separately and then finally you can merge your Private Spark Cloud with your custom server.
Access Tokens : Two kinds of access tokens
First, is the access token that Spark Cloud generates for you “frlobo”. All your iPhone Apps will use this access token to gain access to your Spark Cores without you giving away your username and password (Just like any app that uses Facebook will require a Facebook developer’s access token to be used in the app).
Ideally this access token should be hard-coded into your app and you must never reset it.
Please read: https://community.spark.io/t/when-is-access-token-changed/2086
Otherwise you will have to store the latest access token on your custom server and send it to the iPhone App whenever the user logs in. (This should be really secure)
Second, is the access tokens that you will generate for your users. You can use any way you like to generate this access token but preferably use the same way the Spark Cloud generates the access tokens so that merging the two servers in the future becomes easier.
All this is under the assumption that you will be buying the Sparks under your name and then distributing it to your customers with your Firmware. But if you intend for your customers to buy their own Sparks and be able to use your App and your Firmware, then that is a whole other level of fun!
Perfect sense… My thinking is that the server will be a rest server that will interact as a gateway to my spark. It will listen to spark generated events and it will talk to the spark cloud. It will also listen to rest API calls by my iOS app… My iOS app will only talk to my middleware server and my server will take care of the com to and from the spark.
Ahh, OK! I haven’t thought about it that way. Your approach is slightly more complicated and your server will be doing double the work but this way it is sooo much more safer!
Now that I think about it, your way is actually less complicated since your iPhone App will be doing lesser work since it communicates only with your server and won’t have to cross check anything.
Something tells me Spark is going to launch this User-Management and Spark-Sharing service within the next year since they recently got funded and have big plans. I could be wrong
Im finished writing my first take at node.js server that
Listens to events from the spark cloud.
Relays messages from paired hosts to spark cores via the cloud.
Handles the pairing.
Now. I am studying in detail the spark cloud software to see if I could add this functionality to the cloud so that I can contribute. The thing is I am learning node/js and some practices I need to learn before contributing code
Just for brainstorming… This would be my ideal cloud server.
Apart from all the functionality that we have right now… I would add the following to allow Apps to control the spark core thru simple pairing without requiring all the authentication requirements. This will simplify apps talking to cores, and cores talking to other embedded devices…
For structure, I would in the cloud server philosophy:
Create the concept of a ControllerApp, which will be defined as any device that requires LIMITED interaction with a SparkCore.
A ControllerApp can be paired with the SparkCore, IF AND ONLY IF, the SparkCore, sends a message to the cloud that it is in Pairing Mode. In that message the SparkCore will create and send to the cloud server a temporary 4 digit code, which the Cloud will accept if its unique and tag it to the core as in “PairingMode”. The cloud will then allow X minutes to do the pairing, otherwise it will return the core to normal mode.
Once the SparkCore is in Pairing mode and the cloud knows the temporary 4 digit code, a ControllerApp can request to the cloud to be paired with a SparkCore. For that to happen It has to attach a SparkCore generated random 4 digit code. If the code is correct and the SparkCore is in pairing mode… The cloud will associate both devices.
Once paired… The ControllerApp can :
Send messages to the cloud so that the cloud relays it to the spark core.
If the spark core is offline… It will enquee the message for later submission.
The SparkCore can:
Send events to the cloud for relay to the ControllerApp.
Relay to controller apps can happen in three modes, depending on the state.
Via Push Notifications (iOS/Android).
Publish/Subscribe events if the ControllerApp is a (Web Apps).
On a queue that will be transmitted to the controller app upon request.
Request unpairing of all ControllerApps.
The user can:
Send a REST API request to the cloud for unpairing of a certain ControllerApp.
List all paired Spark/Controllers.
Unpair all Controllers for a certain device.
At least this is what I am thinking… Any other ideas welcomed!
I am making slow progress on it since I have other work duties to attend
However I don’t want to re-invent the wheel and the local cloud seems like the ideal way of implementing this functionality, however the code is not easy for me to read since Javascript is not my go to war gun.
