Webhook - sharing

I’ve written my firmware so that the Photon publishes a call to a webhook to get the configuration for that particular device (cloud APIKEY, component name, scan period, etc.) Just before it publishes, it subscribes to the webhook in order to receive the response. It all seems to work fine, except…

When the second device publishes a request for its configuration, both the first device and the second device receive the configuration that’s intended only for the second device. Is there a means by which you can subscribe only to requests that a particular device publishes?

The webhook response does include the deviceID, so I’m considering using it to decide whether or not to ignore responses as they come back. However, I’m a bit rusty on string comparisons and I don’t know if this is a good tact to take or if I’m making this too complicated.

1 Like

Something like this?

// Subscribe to events published from a specific device
Particle.subscribe(“motion/front-door”, motionHandler, “55ff70064989495339432587”);

https://docs.particle.io/reference/firmware/photon/#particle-subscribe-

I thought of that, but I would prefer to only have one webhook to handle the configuration request and one to push the response to whatever Photon requested it.

Actually, I ended up adding some code to the function I use to handle the subscribed webhook and it checks for the device ID I’m returning from my configuration program.

It seems to be working properly now with multiple Photons.

Thanks for taking time to offer your thoughts!

1 Like

What your doing sounds interesting.

Are you willing to share an example and the code of how you got it working when you feel its reliable?

Sure. It’s working now, but let’s let it run for a couple of weeks just to see how it behaves over time.

I used a similar approach with Electric Imp, but utilized a MySQL database to store all the configuration information. That system works very well, too, but my current approach is simply to use a PHP program with some IF statements to accomplish the same goal, but in an easier fashion (though a bit more crude).

1 Like

You found a working clean solution, but just for completeness (although you might be aware of it already):

Since the “event name” you are subscribing for is in fact only a prefix-filter for actual event names, you could also do this

// subscriber
Particle.subscribe("multiDeviceEvent", handler);

// event source(s)
Particle.publish("multiDeviceEvent_HOME_", "Hey home device!");
Particle.publish("multiDeviceEvent_CAR_", "Hey car device!");
Particle.publish("multiDeviceEvent", "Hey everyhody!");

All of these events will be triggering the above handler, and inside that handler you can evaluate the suffix to judge who you want to react.

This way the behaviour of the app is not dependent on the device (Device ID) but only on the code you flash to whatever device (e.g. conditional compile - home code can by on any device as long e.g. #define MYPURPOSE _HOME_ while any other device could be a car device with #define MYPURPOSE _CAR_).

@ScruffR–thanks for the post. I was not aware of the “prefix-filter” aspect of the webhook name. I guess I’ll need to dig into the documentation a bit further. I never saw any mention of this, but assume it’s in the documentation area describing webhooks?

What you’re proposing is somewhat the opposite of what I need. I have a common code base shared across many Photons and I’d like them all to use the same webhook to retrieve their configuration from the singular PHP script I have running on a server.

That being said (and assuming I understand your post accurately), I will investigate this further, as the functionality you describe may come in very handy in the future.

Thanks!

I guess you understood me correct.

But this way’d open some more freedom (also without code changes).
Since Device ID is “hard-wired” to your device it’s easy to dedicate a device for one purpose but if you want to repurpose the device or need to change hardware you need to change the code on the publishing side (if cross-talking on multiple devices).

On the other hand with the filter option you won’t need to go the conditional compile way, you could also add some way to set the purpose of the device from the outside (e.h. via a Particle.function() in combination with EEPROM). So it’d be easy to repurpose a device or replace a bust device by just flashing unaltered code and a one-time init.


BTW: That’s the info about Particle.subscribe() that explains the filter

Interesting dialogue! I can easily swap a device in the field and/or repurpose it with my current approach–no firmware changes. The only thing I need to do is change one line in a PHP program that offers configuration information should the device’s firmware request it. The line of code simply identifies the device’s ID.

I may move this to a database driven scheme, similar to what I have working for my Electric Imp devices. That way, I only add/change one record in the database to commission a new device. It’s a bit more elegant than changing a line of code.

2 Likes

Obviously I didn’t understand you right (or did just read with half a brain) then :blush:

I thought your publishing/triggering side was a Particle device too - my bad :sunglasses: