As the number of deployed devices grow, I am looking to accomplish the following:
Share a common codebase across all devices that deliver the same function - “a visitation counter”
Standardize Webhooks using Ubidot’s Drive Types to properly group devices on the back-end
Provide a select group of customer admins / development partners access to devices at the intersection of the device function and the customer set. “a visitation counter for NC State Parks”
Note: in my model, I retain device ownership of all devices in the fleet.
I am a bit torn on the best approach here as I see two ways to make this work:
Use multiple products to segment both function and customer set.
** Pros - segmentation of access and visibility - ability to point Webhook to Ubidots Device Type
** Cons - Difficult to share common codebase across multiple product groups as PRODUCT ID will be different for each. Proliferation of products can make finding devices harder (no search for Device ID across products for example).
Use a single product for all devices that share a function but use product groups to manage access:
** Pros - Much easier to maintain and publish a common code base. Easier to monitor fleet using Product fleet health tools and a common activity monitor. Device access/ visibility set by group.
** Cons - Must use a common Webhook (no way to tie Webhooks with common name to different groups). Device Type list must be bulk-uploaded to Ubidots - one time effort.
I am fully aware that I may be missing something that would change the pros and cons above - comments welcome. I would love to hear about the choices / experiences anyone else managing growth could share.
I am not sure if I fully understand what you are after but one idea might be to programmatically use a different Particle.Publish() event name based on what group the device belongs to. That way you can setup different webhooks for all devices in the fleet but what is different is the event name is changed. Something like this:
Then just create a different webhook for each event name. You'd have to still find a way to programmatically set groupNumber though. This could be through a PubSub event that occurs when the device first connects to the cloud? I do something similar but to change the "Mode" of a device. This allows me to keep a single code base for devices with slightly different functionality. I just use different event names for one device vs another and I send it a "modeNumber" to tell it what type of device it is and then what Particle.Publish() to call.
If it was me, I'd put a lot of weight on keeping a single product especially if the product does essentially the same thing.
For my setup, I default it to the most common mode of operation. The first thing the device does when it’s powered on is connect to the cloud and publish an event. The response from that event then sends back a “configuration” parameters which includes “mode” Boron Solar Charging with 1.5.0-rc1 - #60 by jgskarda
So in your case, the first time a device powers up, it could send a publish event and the subscription to that event could then set the group number that device belongs to. As explained in that post, I use a one up number that is initialized to 0 in setup so when that message reaches the cloud, I know it needs new configuration parameters to send down to it. You could probably even make it expandable/generic and use the subscribe event data to set the event name of future publish events or even just concatenate a string with an integer value for “groupNumberX”. This variable is then the event name in particle.Publish(). This way you wouldn’t have to update the device firmware at all if you wanted to go from 5 groups to 10 groups to 50 groups. The event Name just updates automatically based on the response of the first publish event after being powered up. If that makes sense… I haven’t done this myself but is likely the approach I think I’d take or at least try first.
Great question here. I think there’s definitely an opportunity for more analysis on the functionality here. We’ve kicked off a conversation with our internal Product team to dig into this one further.
I have a proposal for a bit of a workaround today though, specifically for your second proposal.
On your second proposal, what I would consider is having a script to fetch and store metadata about your devices, specifically their associated device group stored on the Ubidots side.
My thought process is that before firing events about a device, you should check its associated group. If you have no records stored, you can do an API call to Particle’s infrastructure in order to fetch and store the device type.
This is a bit more work up front, but would be an autonomous way of handling future device additions on the Ubidots side since it should be self-updating at that point.
If I make a different product for each customer, I end up with a challenge with managing essentially the same codebase (only the Product ID different) across a number of products.
If I have all similar devices in one product, there is no way to segment access for developers / admins by group within the product.
Before I make a suggestion / request, do I have this right?
However, there is another option: As of the Tracker One launch, as long as you pre-add your device IDs to your product, you no longer have to code the product ID into your firmware. Thus you can now use the exact same firmware across multiple products without having to edit the product ID in the source.