WebHook Subscribe not reliable

Firmware
#1

I’ve got a fairly simple program that sends data to a web endpoint via publish (works fine) and subscribes to the response (CallBack set up in setup()). I was having problems with it losing the subscribe over time so I modified the code to subscribe just before the Publish() and unsubscribed at the end of the CallBack. That “seemed” to fix the problem, but apparently not… The Events console shows the data in the hook-response, but my CallBack is not always firing. This was the case for multiple iterations and then (no new flashing or any other environmental change), it’s again hitting the CallBack (i am monitoring on the cli console). There doesn’t seem to be any reason why my CallBack works, then doesn’t, the does again. I’ve read several (older) threads that seem to be similar to my problem, but they all appear to resolve with later firmware versions. I am using 2.0.0-rc4.

My question is; Are there still issues around subscribing to a web response? And am I correct in unsubscribing and re-subscribing as I’ve described? Not sure what best practice is for this. Thanks

#2

There should be no need for subscribe/unsubscribe procedure as you describe and I’ve not really seen subscriptions just “die”.
Hence it may be related to your connection and/or your code but there is not enough info to say anything definitive.

There have been some changes in the strategy when subscriptions are registered that aren’t yet documented, but in general there are no known issues with that in general.

I’d say no.
While this may work around some other issue, the actual solution would be to find the cause and eliminate that - but it’s most likely not on the Particle side as we’d see a lot more similar reports if it were.

#3

Ok, well that’s helpful. My Particle protocol is to connect to the cloud, send my data, wait until either 10 seconds have elapsed or I receive the server response and then unsubscribe and disconnect from the cloud. The cloud disconnect is necessary (I think) because even though I only send data to the server every 15 minutes, there’s some handshaking going on that drives up data usage (not from my app though). When I disconnect and then reconnect before sending data, the data usage is very low - and it works. So, I’m assuming that’s a common solution to control data charges? Even when my callback isn’t activated, the console shows the hook-response event, so I know the Webhook is receiving the data response from the server. I’ll dig through the code and see if there’s anything that could keep the callback from getting called. I don’t use any delay()'s anywhere. I also have a Serial.print as the first statement in my callBack so I know that I’m not even getting it called.

#4

This shouldn’t be either. The Boron uses UDP as communication protocol and as such doesn’t keep an active connection for exactly that reason to save on data. No “handshake” will be exchanged as long your code actively communicates with the cloud at least once every 23 minutes (providing you are using Particle SIM and don’t set Particle.keepAlive() in your code). If your code fails to do so, the device OS will issue a short “keep alive” transmission for “UDP hole punching”.

On the other hand when you actively disconnect and reconnect (especially when also unsubscribing/resubscribing in the process) the expected data consumption would be higher than staying connected permanently.

When your devices in deed does communicate with the cloud without your code initiating that it would be interesting to see where that comes from.

Could you run a LOG_LEVEL_ALL log handler and catch the logs when such unwarranted “handshakes” appear - while staying connected?
If that doesn’t reveal anything interesting could you flash this and see what that may tell.

1 Like
#5

That was my understanding too (having actually read the documentation). But I left a unit running for several days while connected to the cloud, but with no data being sent/received by my app and monitoring the usage in the console. It hit the 3MB mark pretty quickly - which is why I adopted the disconnect/connect strategy (which shows very little data usage - extrapolates to about 2mb per month. I am using Particle SIM and do NOT use keepAlive. I will do what you suggest as well as write a small sketch that simply connects (cellular and cloud) but has no other code in it and leave it running for a few days - just to confirm my earlier observations.

1 Like
#6

Would be good to also log the RSSI and any connection loss which will potentially cause extra traffic.
Poor signal quality would of course have more chance to impact an “always on” device.

#7

I have several devices out that sit connected all day long. I send a publish twice a day. Maybe 4 times out of the month it might make an additional publish or so. My usage is usually below 1mb.

#8

That’s interesting. My devices are all remotely deployed as well and publish every 15 minutes. The boron is replacing the adafruit FONA as our cellular solution (most of our network uses WiFi). I haven’t had time to go back and setup a simple do-nothing app yet to see why I was clocking up higher-than-expected bandwidth, but should be able to by the weekend. However, with my not-best-practices approach of connecting/disconnecting from the cloud, I’m at about 1mb after 10 days. That’s reporting every 15 minutes with about 400 bytes of data.

#9

I’ve been having this issue on and off for months. Most recently today I connected a new Argon (A2) and flashed it with an application that works fine on my first Argon (A1).

Initially I flashed device os 2.0.1 to A2 and found that hook-responses were not firing. So I downgraded A2 to 1.5.2 to match A1 but the issue persisted.

I have also tried deleting and re-creating the webhook at https://console.particle.io/integrations/webhooks, which has worked in the past but not this time.

Like the OP, I am trying to subscribe to the hook-response from a webhook that returns data from my web application server.

I’m sure the events log viewer in console.particle.io used to display hook-response events when they were triggered but it doesn’t seem to anymore for any of my devices. Is this correct? With the hook-response events not showing in the events log viewer I am not able to detect if the problem is particle is not actually firing them or if my device hasn’t actually subscribed to them successfully.

Any pointers? I’ve spent a good number of hours stuck on this

#10

Where in your code do you subscribe and publish the event that would trigger the webhook.

#11

Thanks for asking that question. I’m sure you’ve asked it a million times in this forum!

Subscribing and publishing is done in the setup function of my config class… bEarthaSensor/src/config.cpp · master · livesource / beartha-firmware · GitLab

Which is initiated from the setup function in my main .ino file: bEarthaSensor/src/bEarthaSensor.ino · master · livesource / beartha-firmware · GitLab

Should be fine, right?

#12

Unfortunately not.

In one of the recent device OS releases Particle.subscribe() handlers will only come into effect a short while after setup() has finished. So publishing from setup() (directly or indirectly) will emit the event before the handler will be ready to catch it - that is for SYSTEM_MODE(AUTOMATIC)

See the discussion starting here