Hook-response traffic/data operations

Hi,

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?

Device firmware does NOT have any subscribe to the response of the webhook, even though the cloud is configured to emit it in the event stream:

Thanks!

Hi Gustavo,

The answer to both questions is no:

  1. No “data traffic” is counted towards your usage for Cloud side events.
  2. No data ops are counted towards your usage if no devices subscribe to the response.

Hope this helps!

Best,
Manuel

1 Like

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?

Thanks again.

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.

1 Like

@morduno-particle , @rickkas7 follow-up question:

  • 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!

Assume around 130 bytes plus the length of the payload for the event and the ACK.

1 Like

Hi,

another follow-up question:

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.

Thanks again.

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.

1 Like

Can you please tell me what is the duration of the timeout? 30 sec?
Thanks again

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.

1 Like