We have a project with a couple of constants that we would prefer to not have in our code - it makes it easier for us to share the code with other organizations. It also makes it easier for us to change those constants in all of our devices without having to reflash the code OTA. Imagine that these constants were the login credentials to some service. We could put them in our code, but what if our service provider changes the credentials on some regular basis?
Our thought was to put the constants in the return template of a webhook. When our firmware starts up it will Publish to trigger the webhook and retrieve these constants for use.
It works well except that the webhook has to have a URL configured. If I put in google.com the process works, but it would be nice if I didn’t have to do that.
If I could configure a webhook without a URL, then I could call it to retrieve these constants from the Particle cloud without having to tickle google.com.
Sorry for the imprecise semantics; I’ll try simpler terms.
We do not want these values to remain on these devices through a reset.
We do not want these values to be in the code for our firmware.
We would like our devices to retrieve them from a cloud source. We are using a webhook today, and that webhook uses google.com as the URL. We wish there was an enhancement to webhooks that would work without requiring a URL.
In terms of scaling, we store the values in a JSON string in the webhook response template. Seems like that will work for our needs.
I agree that one would typically store the individual sets somewhere. I’d like to store them in a webhook in the Particle cloud and hit that as the source for this desired info.
This would mean you'd require a dedicated webhook definition for each set of devices while they all would listen to the same event name.
This would require a separate account "owning" that webhook and all the devices of that group.
While this is possible, it doesn't seem very scalable IMO.
Thanks for the idea. We’ll have about 50 units so keeping the device notes up to date would work, but be a burden.
I’m not sure about scruffR’s issue on scalability. We do intend to have a separate account own the devices, but even within that account there will be two groups of devices. We’ll have two webhooks, one for each group of devices. Seems like it’s going to scale just fine. If some issue develops I’ll report on it to this thread.
Would still like the enhancement of not needing a URL on a webhook.
So I use a solution based on particle cloud and thingsboard.io - this allows me to retrieve attributes from the thingsboard profile for the device and in that i store all sorts of config variables to do just what you need - it uses mqtt. My setup gets device site name, time zone offset, lat, lon etc and can be updated manually or from an api call from another system - I find it compliments the particle cloud well - plus you can also visualise data on dashboard if you need to. SO now I have a device management path (particle cloud) and a data management path (thingsboard) that can operate somewhat independently of each other.