Webhooks integration to IFTTT stopped working today

[guags99]

I have quite a few Network Resources setup to trigger devices via IFTTT.  Some of these have been setup for years with barely and issue.  However this morning none of these Webhooks calls are triggering my IFTTT routines.  The Key works fine because I can test it via a browser window, and all is well.  However when testing each Network Resource via the ISY Interface from the Network Resource screen, I sometimes get a "Request Failed" pop-up, and sometimes I get no error, but they still do not fire my IFTTT routines.  

 

Anyone else?  I made no changes in the past few days.  I have reached out to IFTTT, but have no response back from them yet.  Just strange if it is just me.

 

Thanks

Edited November 30, 2021 by guags99

[ldb]

I'm having the same problem.  Just checked again and no go.  The error messages are meaningless to me so can't tell where the issue is.

[MrBill]

16 hours ago, guags99 said:

The Key works fine because I can test it via a browser window, and all is well.

If the same thing works in a browser window (i assume the entire URL the NR is calling, not just the key) then the problem is on the ISY or local network side.  Check the error log of the ISY and see if there are more clues there. 

Have you restarted your ISY?  if not, by all means try that.  Also your modem/router.....

[MrBill]

10 hours ago, ldb said:

I'm having the same problem.  Just checked again and no go.  The error messages are meaningless to me so can't tell where the issue is.

If my reply to the OP doesn't also help you, then we need much more information about your setup and what's happaning.  Are you in-fact making calls to IFTTT via webhooks?   "Me too" posts are often not at all the same thing.

[ldb]

Thanks for reminding me to try the simple solution (rebooting) first.  Unfortunately it didn't resolve the problem. 

The Event Viewer shows the following:  Net-Resource: Failed connecting to maker.ifttt.com.

Attached images from UD Mobile and one of my Resource Editor items.

 

Hopefully this info is responsive to your request.

Thank you.

[Michel Kohanim]

Connection error = ISY cannot connect either because of DNS, the Server is down, or SNI. Please try with SNI checked and increase the timeout.

With kind regards,
Michel

[MrBill]

@guags99  Same info from @Michel Kohanim likely applies to you... perhaps timeouts are the issue for you as well.  I don't use IFTTT anymore but I can remember that issue in the past.

[rohmerg]

I am having the same problem all my network resources have been working fine and simply stopped running after the last run on 11/29/2021. I can trigger the network resources via the web browser but they simply will not execute via the ISY program. I have rebooted everything and have checked SNI and increased the timeout from 1000 to 1500. When I use the browser the IFTTT response it almost instant.

[rohmerg]

I do have a few IFTTT buttons that work fine. They are incoming to the ISY, but my outgoing network resources to IFTTT webhooks still won't go'

[ldb]

I checked the SNI box and increased timeout incrementally up to 6000 to no avail.

I also informed IFTTT and they acknowledged fixing a webhook problem but it didn't fix mine.

I too can initiate an applet via IFTTT website but not from ISY program.  The timing of reported failures around midnight 11/29/21 is curious.  I'll stay tuned for further info.

Regards to those trying to help!

[MrBill]

@rohmerg and @ldb

Keep in mind that the ISY error log exists.  (Tools > Error log)  for each failure you have, there will be one or more specific lines that match up and give more clues about the failure.

[rohmerg]

Interesting, thanks for the update. We now know where to start looking. Perhaps IFTTT's webhooks maintenance didn't fix your problem, it's the cause of it. I'm thinking the fix is on the webhooks side. 

[guags99]

Thanks for the engagement on this.  Everything others have posted are consistent with my experience. I have rebooted and checked logs. The errors I have seen are consistent.

I too have incoming requests from webhooks that work fine, however outgoing to IFTTT do not.

[MrBill]

32 minutes ago, rohmerg said:

Interesting, thanks for the update. We now know where to start looking. Perhaps IFTTT's webhooks maintenance didn't fix your problem, it's the cause of it. I'm thinking the fix is on the webhooks side. 

18 minutes ago, guags99 said:

Thanks for the engagement on this.  Everything others have posted are consistent with my experience. I have rebooted and checked logs. The errors I have seen are consistent.

I too have incoming requests from webhooks that work fine, however outgoing to IFTTT do not.

So what are the error log entries associated with the failures... please feel free to copy and paste!

[Xathros]

Hello all,

 

I'm seeing the same thing with all of my outbound maker network resources.

Get, Post, URL Encoded or not, SNI or not, they all fail.  Every failure results in the same error in my error log - example follows:

Wed 2021/12/01 04:45:49 PM	System	-170001	<s:Envelope><s:Body><u:TestNetResource xmlns:u=	
Wed 2021/12/01 04:45:49 PM	System	-170001	[TCP-Conn] -256/-140002, Net Module Rule: 5

I can call the web hook just fine from a browser on my computer.

Any insight would be appreciated.

-Xathros

 

[rohmerg]

This is in my error log after attempting webhooks send

Time                          User         Code    Message
Wed 2021/12/01 04:59:43 PM    System    -170001    [TCP-Conn] -256/-140002, Net Module Rule: 8

 

[ldb]

Here is mine after a couple of attempts...

Time                          User         Code    Message
Wed 2021/12/01 06:01:19 PM    System    -170001    [TCP-Conn] -256/-140002, Net Module Rule: 4    
Wed 2021/12/01 06:02:14 PM    System    -170001    [TCP-Conn] -256/-140002, Net Module Rule: 4    

 

[Michel Kohanim]

@ldb,

256 = TLS negotiation failed. Only three options:

1. SNI
2. Timeout too low
3. In https Client Settings, you have the Verify box checked

With kind regards,
Michel

[ldb]

FYI, my status...

1.  SNI checked

2. Timeout set to 20,000 (the maximum)

3.  https Client Settings Verify box not checked

[Xathros]

Hello all,

I have tested with SNI checked and unchecked.  Timeout set to 20,000 - no noticeable difference in time to failure from timeout of 1000.  Where do I find the Client settings to check (or uncheck) the Verify box?

Seems like something changed outside the scope of the ISY for this to all of a sudden be affecting so many clients.  Probably something at the IFTTT host side but that'd just a guess on my part.

Thanks in advance for any guidance.

-Xathros

[ldb]

ISY994 Series Network Security Guide.pdf

[Xathros]

Found the dashboard - here are my client settings:

 

[ldb]

Checked my error log this morning and am seeing one of the following every 5 seconds:

Thu 2021/12/02 04:29:51 AM    System    -100    [DHCP] state=RENEW    
Thu 2021/12/02 04:29:56 AM    System    -100    [DHCP] state=REBIND   

[guags99]

I am not seeing the DHCP errors that you are seeing, but I did look at my Error Logs and the first instance I had of -170001   [TCP-Conn] -256/-140002    Net Module Rule: 14 is:

Mon 2021/11/29 11:04:46 PM    System    -170001    [TCP-Conn] -256/-140002     Net Module Rule: 14

This is CST, so just after midnight on 12/30 Eastern Time.  I assume this is consistent with others?  I am trying to determine if it started at the same local time, or all at the same instant globally.  I assume the latter, but wanted to check.

But even if that is the case, I am still not sure if this issue is on the IFTTT side since I cannot replicate the issue on any other platform.  I have an HTTP app on my Android phone that I can use the same POST configured as close to the settings as I have in my ISY and it work immediately.  No errors.

[Xathros]

Hello guags99,

My first failure was:

Tue 2021/11/30 04:23:52 PM	System	-170001	[TCP-Conn] -256/-140002, Net Module Rule: 2

Also CST and was the first time a maker event was called since the week before as we were away and the events would not have fired while we were gone.

I saw mention of 11/29 earlier in this thread as well so I suspect your right.

-Xathros