Hi,
I am new here and created a forum account because I can’t find a nice solution for this problem after days of research.
I have a product using Electrons which has a Product ID and push version updates via this.
The product is sold previously to just one customer.
We are using Ubidots for visualisation and alerts, and push events to Ubidots using Webhooks.
We also in parallel are creating our own web app on our own server, and push the same events to it using webhooks. (to eventually replace Ubidots)
This first customer runs his own Azure IoT hub and we push events to him for Azure using Azure integration webhook from our product devices.
Now we have a second customer who is purchasing the same product and in the future there will be (hopefully) many new different customers.
If I add a device to the same product, then the Azure webhook will publish the event of the 2nd customer also to the first customer.
I want to have the device firmware identical in the same product so I can’t use different event names for the same events just to control the web hooks.
The only way I can think off is to create a new Product / ID, but the device is really the same “product” and future firmware upgrades would mean multiple deployments. We also have to setup new webhooks, and this would occur for every new customer. - New Product ID plus new Webhooks for each customer who has his own IoT platform.
It seems the solution would require that the Webhooks in web console have a Device selection option, instead of just “all”. So for example in the Azure integration you can choose the devices to webhook for instead of “all” in the Product.
This would also be useful I guess for standard webhooks as well.
Alternatively the particle server needs some sort of “Customer” or “Organisation” grouping structure as well as Product grouping?
Looking for feedback if I am actually using Products > Webhooks correctly, or if I am missing something?
Surely this would have come up before?
I’m not aware of a perfect solution. Will hopefully see improvement in the future.
For the interim I would suggest configuration and saving of a customer specific prefix in your firmware. For example, you might have a default publish to TEMP but after configuration that might become CUST1_TEMP, CUST2_TEMP, and so on. Then setup a separate webhook for each prefix that forwards on to the matching customer endpoint.
This is a great question! I’m in a similar situation and haven’t found a great solution yet. I think that the idea is that you eventually develop these types of functionalities through your own Web App, but I’d be very curious to hear from the fine folks at Particle to see what might be in the works.
Thank you for your reply, and at least confirming I am not being dumb and missing something.
Having different firmware for the same product for different customers I think would mean we would have to re-create multiple firmware upgrade versions for each customer which is not ideal.
I guess I could have one firmware with commented out declarations per each customer to set the “prefix”, but then we still have to manage pushing group product upgrades.
I don’t think it would save much work by instead just having a 2nd product, with the same firmware (but different product ID) and new product webhook associated.
The only way I can think of doing it autonomously would be to check with our own web server on device boot up, subscribe to a variable, push the coreID and in our DB store the customer “prefix”, supply that to the device which then adds the Prefix to the publish variable. Quite messy way to achieve it.
Be great for Particle to add it to the list of potential future improvements.
BTW, without Particle we would not have our products up and running so quickly, great product thank you!
seems like there could be like an array of customers with actions required within the code and the specific customer is identified by device id. but maybe i’m misunderstanding that you are not looking for a code solution but a console solution.
Thanks a lot for the reply, I guess there are many ways to skin a cat. So far our plan was to keep the device hardware as simple and identicle as possible and do everything apart from local control and event pub in the cloud.
I can publish directly to our web server and then webhook to each customer’s IoT platform but then I loose all the cool integration and debug the particle console gives.
We will setup multiple “products” in the console and that will get around it for now.
There is an EEPROM on the device. You can create a Particle.function and during initial device setup send down an Event Prefix (based on customer) and save that to the EEPROM. Load Event Prefix from EEPROM on boot. Adjust published event names based on current Event Prefix.
Don’t need additional products. Don’t need separate firmware builds.
Do need one more step on device setup. Do need separate webhook for each customer prefix.
That’s a really great idea, thanks Joel. I normally stay away from using the eeprom due to the flash read/write limit but this is the perfect application where it’s only seldomly written to.