Webhook Integration - Sleep

Cloud
1

I have about 20 Electrons active right now, happily publishing data every hour. Just now (30min. ago) 17 out of 20 devices conencted to the Cloud, published the data, but the webhook Integration I have with Ubidots simply shows “sleep”. No request/response log is shown, just the event log (which appears to be 100% fine to me).

What does this mean? From what I understand the main results are “success” and “error” - in which case there’s usually a detailed error log. But what does “sleep” indicate? My devices connected + published fine, the data just didn’t appear in Ubidots.

Is this a Particle Cloud issue, or an Ubidots issue?

EDIT: All devices connected again + submitted data to Ubidots for the next check-in. Still, I’m curious as to what exactly happened here, particularlywhether the issue pertains to Ubidots or Particle Cloud.

2

See here:

It's my understanding that Sleeping Webhooks are usually beyond Particle's Control. It's the Endpoint.

I have an Electron Gateway that sends a lot of publishes a day to ThinkSpeak from my private Mesh.
On the pic below, ThingSpeak was having some problems that day and the Webhook graph showed 19 Sleep Events:

image

3 Likes
3

So the Sleeping webhooks usually are the results of an Error coming from the Endpoint? My devices all publish at the exact same time so it would make sense, but in this case I haven’t had any Errors for the last 5 days.

4

I think you need to think at a grander scale.
Do you know how many concurrent requests hit the Ubidots endpoint, from other sources than your few devices, at the very moment and can you exclude the possibility that Ubidots may have degraded QoS due to maintenance or things like DDoS or stuff.
If it’s a one-off, I’d leave it for the time being - especially since it seemed to self-heal -, but if it keeps happening repeatedly you may want to contact Ubidots.

5

Is there a way to get a return code indicating success/fail/sleep?
cc’ing @rickkas7, @ParticleD, @KyleG too.

6

Where and when would you expect that return code to be delivered to you?
Success and failure on the remote end are already reported via the respective webhook response events and - if I’m not mistaken - the cloud now also provides a response (including possible reason) when a webhook was muted.

Your device just needs to subscribe to these evens.

1 Like
7

I can see how the webhook response could work; haven’t used it before, but the Particle console shows the xml response for success and failure, but not for sleep. Console only lists the event that triggered it.
Is that how it suppose to work?

8

@ScruffR, I haven’t been able to obtain the html (or xml) response on my device. Can you spot anything wrong with the setup below:

  1. webhook response topic
{{PARTICLE_DEVICE_ID}}/hook-response/{{PARTICLE_EVENT_NAME}}
  1. webhook response template (same response if left blank)
{{{PARTICLE_EVENT_VALUE}}}
  1. setup()
Particle.subscribe(System.deviceID() + "/hook-response/twilio3",    tw_response_handler, MY_DEVICES);
  1. response handler
void tw_response_handler( const char *event, const char *data ) 
{ 
    Particle.publish( "kbnape/almmon/debug",  
        String::format( "twilio3 event: %s\ndata:\n", event, data ),   PRIVATE);
}

I get the response below:

twilio3 event: <device id>/hook-response/twilio3/0 data:

On the console, it shows the full endpoint response.

HTTP/1.1 201 CREATED
Date: Wed, 08 May 2019 15:48:27 GMT
Content-Type: application/xml
Content-Length: 884
Connection: keep-alive
Twilio-Concurrent-Requests: 1
Twilio-Request-Id: RQ96d2b3781b8b43fda353de82f2b68bb3
Twilio-Request-Duration: 0.144
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Accept, Authorization, Content-Type, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since
Access-Control-Allow-Methods: GET, POST, DELETE, OPTIONS
Access-Control-Expose-Headers: ETag
Access-Control-Allow-Credentials: true
X-Powered-By: AT-5000
X-Shenanigans: none
X-Home-Region: us1
X-API-Domain: api.twilio.com
Strict-Transport-Security: max-age=31536000

<?xml version='1.0' encoding='UTF-8'?>
<TwilioResponse><Message><Sid>SM2f22c85eadf449da9ee59a5b1c6a038e</Sid><DateCreated>Wed, 08 May 2019 15:48:27 +0000</DateCreated><DateUpdated>Wed, 08 May 2019 15:48:27 +0000</DateUpdated><DateSent/><AccountSid>ACCOUNT_SID</AccountSid><To>+19999999999</To><From>+19999999999</From><MessagingServiceSid/><Body>sylpsi 1.0.1</Body><Status>queued</Status><NumSegments>1</NumSegments><NumMedia>0</NumMedia><Direction>outbound-api</Direction><ApiVersion>2010-04-01</ApiVersion><Price/><PriceUnit>USD</PriceUnit><ErrorCode/><ErrorMessage/><Uri>/2010-04-01/Accounts/ACCOUNT/Messages/SM2f22c85eadf449da9ee59a5b1c6a038e</Uri><SubresourceUris><Media>/2010-04-01/Accounts/ACCOUNT/Messages/SM2f22c85eadf449da9ee59a5b1c6a038e/Media</Media></SubresourceUris></Message></TwilioResponse>
9

I’d not subscribt to System.deviceID() + "/hook-response/twilio3" but rather only to
System.deviceID() + "/hook-response/"
Also double check that System.deviceID() and your obscured <device id> match exactly.
I’d put the subscribe filter prefix into a string and print that out or expose it via Particle.variable() to check.

And since your do get a <device id>/hook-response/twilio3/0 response I’d suspect there are also some <device id>/hook-response/twilio3/1 ... n responses that also need to be used.

It’s also not advisded to Particle.publish() from a Particle.subscribe() handler

See here
https://docs.particle.io/reference/device-os/firmware/photon/#particle-subscribe-

image
image791×409 23.1 KB

1 Like
10

@ScruffR, got it working.
Here’s what did it:

  • removed the Particle.publish() from the event handler, as you pointed out and is documented
  • removed {{{PARTICLE_EVENT_VALUE}}} from the response template

I also implemented a moustache template per @rickkas7 excellent webhooks intermediate tutorial and the appropriate response data is easily retrieved for use by the electron.
The assistance you guys provide via the forum and tutorials/online docs is awesome.
Thanks for the help!

2 Likes