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.
A setup function which stores the value in EEPROM would be my first way to go with that.
A webhook will always try to hit a server and never just report back on its own.
However, you can have a dynamic URL sent from your device as event value.
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.
Hi Jim,
if I needed to do something like what you describe, I would give it a shot at using the device notes. You can access them via the rest API, and perhaps one can configure a webhook to hit them and get values even per device, if needed: https://docs.particle.io/reference/device-cloud/api/#add-device-notes
You get the notes of each device with a get request to the device info API, I believe.
Good luck!
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.
oh, in that case, you can just use the notes of one device to control all of them. I can even be one test device.
Anyhow, this would be another hack. Good luck!
