Webhooks Not Working in WebCore, but are in another Instance?


#1

I have two instances of WebCore (two different SmartThings hubs). Each of the instances of the WebCore leverage a webhook to an endpoint.

One instance successfully posts to the endpoint, every single time, the other one does not. The pistons are literally clones of each other. I made them so stupidly simple on the one that doesn’t work (light turn on, post to endpoint) and it simply will NOT post from one of the instances. I can put the end point in the browser and hit it every time - even on the same network as the SmartThings hub.

Which makes me think it’s a network config problem? Or something is preventing the one instance from posting successfully? Thoughts? Places to look? Things I can check? Any other details I can provide that would help?


#2

snapshot of both pistons?


#3

Also which version of webCoRE on each instance? Especially if they are different versions.


#4

I’ve tried switching the Webhook endpoint too, essentially the Webhook just simply does not work in one of the instances. Piston is identical in the other. Happy to get you the other one, but it’s exactly the same. Even the most basic webhook won’t go through. It’s like it’s being blocked? But the webhook endpoint works just fine in the browser / on the same network.

Thanks for taking a look!


#5

It should be the same version(?), it’s under the same account? I have two hubs, I consistently update to the latest version.


#6

thanks. please turn on full logging for both pistons and post the logs.


#8

=== Piston #1 (the one that doesn’t work) ==

10/8/2017, 7:04:09 AM +855ms
+1ms ╔Received event [Office Lamp].switch = on with a delay of 98ms
+71ms ║RunTime Analysis CS > 17ms > PS > 37ms > PE > 18ms > CE
+78ms ║Runtime (38936 bytes) successfully initialized in 37ms (v0.2.0f9.20171007) (76ms)
+79ms ║╔Execution stage started
+90ms ║║Comparison (enum) on changes = true (0ms)
+92ms ║║Condition #32 evaluated true (6ms)
+93ms ║║Condition group #29 evaluated true (state did not change) (6ms)
+106ms ║║Sending external web request to: maker.ifttt.com/trigger/test/with/key/XXXXXXXXX
+160ms ║║Executed virtual command httpRequest (60ms)
+163ms ║╚Execution stage complete. (84ms)
+170ms ╚Event processed successfully (170ms)


=== Piston #2 (the one that doesn’t work) ===

10/8/2017, 7:05:21 AM +744ms
+1ms ╔Received event [Notifier].switch = off with a delay of 40ms
+59ms ║RunTime Analysis CS > 11ms > PS > 33ms > PE > 16ms > CE
+66ms ║Runtime (36267 bytes) successfully initialized in 33ms (v0.2.0f9.20171007) (65ms)
+67ms ║╔Execution stage started
+77ms ║║Comparison (enum) off changes = true (0ms)
+78ms ║║Condition #32 evaluated true (5ms)
+79ms ║║Condition group #29 evaluated true (state did not change) (6ms)
+87ms ║║Sending external web request to: maker.ifttt.com/trigger/test/with/key/XXXXXXX
+142ms ║║Executed virtual command httpRequest (56ms)
+145ms ║╚Execution stage complete. (78ms)
+151ms ╚Event processed successfully (151ms)


I can copy the endpoints and put it in a browser, and they both do the expected actions, it’s like Piston #1 / Hub #1 is being blocked? Makes me think it’s a network / hub config issue?


#9

Well, I think I figured it out. I’m embarrassed to admit it, but I completely forgot I had a Pi-hole running/assigning DHCP and I think that was my issue.I switched back to my router DHCP and voila. It worked!!

Thank you guys for forcing me to really troubleshoot! Didn’t even notice the logging feature in the piston! Thank you @ipaterson and @bangali.

I feel guilty for documenting this post as the solution? Haha


#10

sure thing.

never happened to me. ever! whos @c1arkbar? :wink:


#11

Whaaat?!


#12

thats what you did for me. :smile: