[Fixed] Webhooks callbacks are not reliable!

Hi @mayhew1955,

There is an bug in the core firmware, where it will stop listening for a particular event subscription. I believe this bug is fixed in the new photon firmware, and will be available to the core soon as we continue to upgrade our dev tools to target alternate firmware versions. There have been a few workarounds posted about the subscription issue on the forums, here’s one: Losing Spark.subscribe() connection/subscription

Thanks,
David

Hi @Dave,

Thank you for confirming that it is a known issue, it’s much appreciated, I’ve been trying workarounds but nothing is as satisfactory as the promised functionality.

What’s your approximate ETA on upgrading the dev tools? FYI I’m using the online compiler.

EDIT: Upon further testing, I have run into a different issue or limitation. I have:

void setup() {
    // listen for the hook responses to commands sent to gas boiler
    Spark.subscribe("hook-response/turn_on_heat", ioBridgeHeatOn, MY_DEVICES);
    Spark.subscribe("hook-response/turn_off_heat", ioBridgeHeatOff, MY_DEVICES);
    Spark.subscribe("hook-response/turn_on_pump", ioBridgePumpOn, MY_DEVICES);
    Spark.subscribe("hook-response/turn_off_pump", ioBridgePumpOff, MY_DEVICES);
}

Therefore my Core is subscribed to 4 events. I can always publish all four webhooks but only one replies back -> the first one in the list, whichever one that may be. My first issue was when even that one stopped replying back.

I was expecting to be limited to 4 events, I’m only getting one with my webhooks. I tried a workaround by subscribing once to hook-response/turn_ and that worked once but further testing revealed that to be very unreliable, responses arrive seemingly at random.

I’ve currently adapted my code to work without webhooks but that means doing without any feedback, I’m firing commands regardless of whether they are heard or not! Looking forward to that next version of firmware, let’s see if these issues are solved.

For completeness, the functions are as follows:

void ioBridgeHeatOn(const char *name, const char *data) {
    Serial.println("Heat On Response");
}

void ioBridgeHeatOff(const char *name, const char *data) {
    Serial.println("Heat Off Response");
}

void ioBridgePumpOn(const char *name, const char *data) {
    Serial.println("Pump On Response");
}

void ioBridgePumpOff(const char *name, const char *data) {
    Serial.println("Pump Off Response");
}
1 Like

Hey @mayhew1955, looks like someone had an issue with multiple Spark.subscribe()s and @Dave came back with a solution here.

But regarding webhooks, I’ve also had a similar issue with the data being pulled into my project, so I’m on the edge of my seat for the new firmware update!

1 Like

@Dave, I just wanted to point out that outside of the subscribe issue, when I look at the dashboard I find that my webhooks are not even firing it seems as I get no response payload showing up (independent of subscribe). Often, I have to fire the webhook several times before getting the expected response.

Hi @peekay123,

Hmm. If the response body of the web request doesn’t have anything, then the webhook won’t publish a message back to your device, but I’ll look into it!

Thanks,
David

I’m going to tentatively second this @peekay123 and @Dave
PK had helped me design a mustached parser here Cloud JSON Parsing
The problem is that it typically fails 1 out of 2 times when I start up my Core. Often, once I get a response, it will work with subsequent GET requests that I make shortly thereafter. Once (while I was giving a demo too), it wouldn’t work for 3 or 4 requests. Don’t really know why. It is a big payload and I thought it may have been getting dropped or refused or not prioritized at the server level. One time it worked but took a very long time 60 seconds) to get a response. The norm for me is either 10 seconds or nothing at all.

2 Likes

Hi @ruben,

That’s really interesting, you’re typically not receiving the 1st event or so on your subscriptions, is that right?

Thanks,
David

@Dave, I see this on my events as well. First event does not return a reply and often 2 or more events go unanswered before getting a response.

1 Like

That is really interesting. OK, if that’s the case, then I think I know what’s up. Might take me a little while to fix.

Thanks,
David

4 Likes

good to hear

1 Like

What do you think the issue is?

Just to chime in here, I too am struggling (recent phenomenon but I can’t tell you when it started) with:

subscribe( )

Like the others I can see the responses on the Dashboard and get affirmation on the CLI:

JimBrowcBookPro:~ browerjames$ particle publish gmail_count
posted event!
JimBrowcBookPro:~ browerjames$ 

I’m compiling on updated particle dev and it works for less than 3 minutes after I reflash, and then no more.

FYI I am only publishing once a minute only from my Spark Core.

OK, so I definately see a pattern and you can see it here:

The first "device came on line"on the far left is a hard reset… after a few minutes, I see the cyan breathing flicker for a short duration, and then the “device came online” appears again.

After that (and this is all in just three minutes) subscribe( ) stops functioning properly.

The funny thing is, a month or two back, my subscribe( )s were working perfectly well over the course of a couple weeks straight. Now, like you guys, it only works for the first couple minutes maximum.

Hey all!

So, there is an old bug in the core firmware where the subscribe request isn’t sent after the session is dropped and reconnected. If your connection is dropping frequently, this can cause your subscribes to disconnect. I believe this is fixed in the newer photon firmware which will be available for cores soon as well. I suspect that is what’s causing the frequent subscribe failures you’re seeing above.

Thanks,
David

@Dave, ok but this does not address the issue of webhooks not firing when they are called from CLI and using the dashboard to monitor the response. You did mention above that you may know what’s up.

1 Like

Heya!

Totally, I suspect that’s a separate issue. My guess is that if the very first event / response doesn’t come through, but subsequent requests / responses do come through normally, that could be a side effect of the internal messaging that hooks use. The workaround would be to test run, or run it again if a response isn’t heard within some timeout. I’m going to test that more fully and build a fix for it if that’s an issue, but it might take me a sprint or two to fix.

Thanks!
David

@Dave, I can’t vouch for the first event which often doesn’t fire but mostly for subsequent events which often don’t fire for several publish events. Mind you, I have not tested this on the latest firmware on my Core-based RGBPongClock.

@BulldogLowell,

any code for me to test? Webhooks is now my new toy :smiley:

I have some magic :eyeglasses: that allows me to see what might be the issue :smile:

2 Likes

My problem is that it counts as a hit every time I make my external API request so I’d rather not have to try multiple times to get a parsed response :wink: alas, I do not have magic glasses. Let me know if you need any other info from my setup.

2 Likes