I am wondering the best way to manage storing light customer specific-data (Phone number etc), on each of my “Product” devices. Currently my product fleet is < 10 devices.
Each device needs to be able to text it’s customer for certain events. The customer phone number must be stored on the device to be used properly with my text web hook.
Before I created a Particle “Product” to manage these devices as a fleet, I would hard code the client phone number as a constant value in the code before flashing the device. Obviously, that is not ideal or built to scale.
It is not possible however, when managing the product as a fleet, as each device is updated & managed running the same code version.
My current work around is exposing a cloud function that allows me to specify the client specific phone number, then it stores the number in the EEPROM and persists until I change it again or flash new code / update my fleet. I think this current method can carry the fleet for a while, but I’m looking for the best long term solution.
My long term idea, is to use a simple database that can accept some key stored in the device hardware (likely device ID) and return the associated client data.Then anytime I create a new field device, I simply would add the device ID and customer phone number into the database. On start up, the particle fleet-wide code would make a call to this database with its own unique device ID and receive the customer data, then store it in the EEPROM as it currently does.
Does this sound like an appropriate solution? If so, do you have any recommendations for which database would best fit this application? I was thinking Firebase, but haven’t put much thought into it.
I would appreciate hearing all of your input on this topic, if you have dealt with something similar, or what you suggest is the best course of action.
Just for the sake of your actual request it might be good to add a TL;DR sentence at the top of your post. You are elaborating rather long what you don’t really want and only the last but one paragraph tells us what you are looking for
I’d say Firebase is fine, so would be mySQL or really any other DB you can hook up with a webhook.
There is a great way to achieve this using thingsboard.io. This IoT product allow you to send telemetry from your device to it and based on rule nodes transform and save the data was well as output it to dashboards, email and many other targets. Importantly though it supports a concept of shared attributes. These can be set on the server (per device) and will be automatically retrieved by the device once set. So if the device reboots it automatically gets the latest version of a particular attribute. I use this for a small fleet to set things like timezone, device name and many others.
They have a free version that is very good and a paid for version that supports full customer and device hierarchy.
What you’re wanting is pretty simple on firebase and google cloud functions. Probably about 2 hours work to setup, write and test.
Simple schema that you post a job to. /jobs/deviceID/timestamp. Setup permissions that don’t allow public reads, but allow public writes if the data doesn’t exist already and if the data contains a known shared shibboleth
Secondary schema at /phonenumbers/deviceID/ with your simple data on the phone number / name etc. You can input it by hand at the start easily. No public read/write, just admin access.
Hardcode a shibboleth into your firmware. Post to a single particle webhook that has your firebase admin secret as a query param for the outgoing webhook call to firebase. Your webhook will take the deviceID prefilled value, the shibboleth and any data you have on the actual event and post to the job queue
Google Cloud Function listening to /jobs/{deviceID}/{taskID}. Pickup task, validate shibboleth or even a secondary shibboleth, process call to phone texting service, delete task.
All the logging, security, storage, processing all handled by GCP. It’ll cost you nothing until you’re well into a few thousand devices, and even then will cost you a tenth or less of that thingsboard.io. Save $500 a month till you scale and have taught yourself how to fish with firebase & cloud functions, which is a life skill in this industry.
Now that’s exactly what I’m going to do. I do happen to have experience with both Firebase & also GC Functions, so I can relate as to how cheap and easy it is to get going. Glad to hear those skills are so universally applicable.
I really appreciate all the explanation you have written.
Dillon, I am not sure where you are based and therefore what data privacy rules you need to adhere. In the EU any storage of customer personal data (name and telephone number) will fall under GDPR legislation. I would rather not spread the storage of such data onto each device as you are opening up more attack surface for a hacker.
it stores the number in the EEPROM and persists until I change it again or flash new code / update my fleet
BTW, flashing should not change data held in EEPROM.
I am based in the US. I will definitely be careful about storing personal info.
The only real customer data is phone number, everything else is arbitrary "client_id’ types of values for my convenience, so I know what hardware number corresponds etc. I will look further into regulations for personal info like phone numbers, however.
Also, I did not realize the EEPROM does not automatically reset after a new flash.
