we are publishing an event through RESTful api like this:
new Promise(function(resolve, reject) {
var url = `https://api.particle.io/v1/products/${productId}/events`;
request(
{
method: 'POST',
url: url,
form: {
name: `${targetDeviceId}_${eventNameSuffix}`,
data: args,
private: true,
ttl: 60,
access_token: accessToken
}
},
function (error, response, body) {
console.log(error);
console.log(response);
console.log(body);
var data = JSON.parse(body);
if (error) {
console.log(error);
} else {
if (data.error) {
reject(`${data.error} ${data.error_description}`);
}
resolve();
}
});
})
The publish works and we see the event in the log for the product. The event device is tagged cloud
as you can see here:
However, our subscribe, and we have tried these three versions (separately of course):
Particle.subscribe(deviceID, deviceID_Webhook_Handler);
//
Particle.subscribe(deviceID, deviceID_Webhook_Handler, MY_DEVICES);
//
Particle.subscribe(deviceID, deviceID_Webhook_Handler, ALL_DEVICES);
doesn’t capture the message.
Any hints as to what is happening here?
Photon compiled at 0.6.1
1 Like
OK, so after pounding my head against the wall for a while, I started to experiment and ended up wiht a so-called “working” solution.
I publish using RESTful method like so:
var url = `https://api.particle.io/v1/products/${productId}/events`;
request(
{
method: 'POST',
url: url,
form: {
name: `${targetDeviceId}_${eventNameSuffix}`,
data: args,
private: false, //<<<<<<<<<<<<
ttl: 60,
access_token: accessToken,
device: targetDeviceId
}
},
function (error, response, body) {
** note the not-private flag
and subscribe using default:
Particle.subscribe(deviceID, deviceID_Webhook_Handler);
which is public by default.
The question remains though: are my events now visible to all, or are there partitions on the Product that prevent anyone from accessing these messages?
There is little (read: nothing) in the docs particle publish/subscribe on Products so some clarification would be appreciated. We’d like to understand if a) we did this correctly and b) if we are exposed now to public traffic at the wholesale level.
1 Like
So, while we are able to subscribe to a PUBLIC message on our Product we then lose the ability to capture other WebHook data that is private.
Can anyone answer as to the appropriate paradigm that we should be using for a publish/subscribe (in Product space) that can allow us to use the DEVICE_ID as the webhook prefix?
I guess my question is How do I subscribe to events from using the RESTful methods described in that post AND our webhooks.
The lack of any response tells me that a) no one has had to solve this problem or b) this may not be an easy one to solve… @KyleG, any suggestions on how to get this answered?
1 Like
It’s on my list for this week to write a document that describes what actually happens with various combinations of options, for both products and non-products, with publish and subscribe.
4 Likes
The answer is that you’re getting the expected behavior, but not the behavior that you want, probably.
When you subscribe to an event using MY_DEVICES on a device, it will only return private events from your devices or API-created events authenticated by the same user as the owner of the device.
The problem is that your product events are probably not owned by the same user as the device, so they’re ignored when using MY_DEVICES.
Unfortunately. if you use public events, then they really are public, even if you post them via the product event API.
What’s needed is probably something like a MY_PRODUCT, but currently the product event stream is intended to send data from product devices to the product creator, not the other way. Going in the other direction has been considered as a future feature, but I don’t have a timeline.
More tips here:
4 Likes
One alternative interpretation would be that one device might want to send data to its siblings - not only to its creator and also not to anybody else.
1 Like
Thanks,
We also thought about this problem and thought that we ought to be able to “target” devices from our server. I had asked about a “Product” access token, which doesn’t exist either.
Soooo…
As a workaround, if we want to maintain the proper MY_DEVICES tag to any device ID prefixed webhooks… we could then possibly create our own product level publish event with a PRODUCT_ID as a prefix and the DEVICE_ID concatenated to that event name, I suppose.
I’ll try that method and get back to you.
It seems like your track of creating something like MY_PRODUCT scope is needed (at least for us ;))
One followup question… Why would anyone ever want to subscribe to PUBLIC events unless those events are PRODUCT scoped? We cannot imagine a use case.
1 Like