Do these webhook responses in red below consume any bandwidth traffic in the case where NO devices are subscribed to the webhook responses in the firmware they are running?
Do they consume any data operations under the same conditions: webhook configured in the cloud to emit response, but no device/firmware has any subscription to them?
Thanks Manuel.
What happens in the case the device is using a third-party SIM card?
I know from your statement that Particle does not count these bytes, but if this particular device is using a third-party SIM card, what happens?
Does the webhook response get sent via the CoAP to the device or not, while the device has NOT subscribed to the webhook response?
The events appear in the event stream, but without a subscription on the device, the events are not sent to the device, so they do not consume data or data operations, regardless of SIM card.
what is the overhead in bytes of the webhook response when it travels to the device?
Let’s say now the device subscribes to the webhook response event, and the interesting parts of the remote server take 10 bytes.
How many bytes does the CoAP overhead add to those 10 bytes? I imagine the deviceId and the event name they all add up to those bytes.
This is so I can calculate data traffic/bandwidth impacts. Thanks again!
if one wanted devices to react to error scenarios only, can the devices just subscribe to the hook-error event stream? Are there any downsides to this?
Will it also fire if the request to the remote server times out?
I was able to test that it fires up on HTTP error codes like 500, 404, but not yet the timeout.
The goal of all this is to react to potential webhook outages. Not wishing for any, in fact, knocking on wood now.
Yes, you can subscribe only to hook-error, and that will also be generated for timeouts.
Also make sure you include the device ID in the hook error topic, otherwise an error will be sent to every device in the product or claimed to the same user, which is probably not what you want. Also, this will use one data operation for each device that receives the subscribed message.
Each request has a 20 second timeout to the external server for the initial HTTP error code. You can have a request that takes longer than that, but you must return a HTTP result code even if the data isn’t entirely ready yet.
There’s also the more complicated scenario when “sleep” is occurring because the server hostname has had numerous errors recently (for any user, not just your webhook). That’s described here and is basically 1 minute.
So it could timeout in as little as 20 seconds but it could take longer than that.