IFTTT troubleshooting... Maybe duckDNS and let's encrypt issues?

Configuration
1

Hi,

I’m starting to feel a bit stupid, but after days of googling, reading, trying, modifying, and re-trying, I think I’m going to have to ask for help.

I’m trying to set up IFTTT to send to HASS. I’ve successfully set up IFTTT so I can run a script in HASS, and this works fine. But when I try the other way, nothing happens (I just test from “within” the IFTTT applet, using the “check now” button).

What I have in the maker (then) part of the applet is:

URL: https://MYDUCKDNSURL.duckdns.org:443/api/services/light/turn_on?api_password=MYPASSWORD
Method: post
Content: JSON
Body: { “entity_id”: “living_room_lights”, “flash”:“yes” }

(I have also tried leaving body empty, or only using { “entity_id”: “living_room_lights” } with different groups or specific switches/lights, etc.)

The only thing I could think of that I did different than the guide (https://home-assistant.io/components/ifttt/) is that I setup the duckdns together with let’s encrypt. Is there any issue with that? I use 443 as external port, it forwards to my internal HASS ip and port 8123. But can there be issues with IFTTT not being allowed because of the let’s encrypt certificates? And if so, is there a way around that? Sorry if it’s a stupid question, but I’m not really an expert (at all).

2

Try removing the port number in the URL. Assuming you have already forwarded traffic from 443 to 8123, you shouldn’t need to specify the port in your URL. All you need is https://

3

Thanks, but no luck. I can connect through a browser to https://MYDUCKDNSURL.duckdns.org:443 (and you’re right, regardless of whether I put “:443” or not in the browser, it finds my HASS).

Just for the heck of it, I tried typing https://MYDUCKDNSURL.duckdns.org:443/api/services/light/turn_on?api_password=MYPASSWORD into the browser (not sure if this is supposed to work or not), and got this message (regardless of whether I kept the “api_password=MYPASSWORD” part or not):

405: Method Not Allowed

I did also have the notification in HASS saying “Login attempt or request with invalid authentication from MY_PUBLIC:_IP”. If any of this helps in any way? But I’m guessing that’s just from the attempt without the password part?

4

You won’t be able to see anything with that URL since HA expects a POST (and loading directly in your browser is a GET).

I assume that you did indeed set up a password and that you get prompted to enter it when accessing https://MYDUCKDNSURL.duckdns.org from outside your network. Try from your phone and turn off Wifi to access from mobile data.

Does IFTTT show a log? Can’t remember from back when I set mine up.

5

Just set this up to test. I used SMS as my trigger. Below is my webhook setup. Worked like a charm.

ifttt.png440×872 25.1 KB

6

Accessing HASS fro outside my home network? Yes, this works fine from phone (on mobile) or laptop at work. As you say, I did have to enter my HASS password the first time i connected from a new device.

An activity log, yes. But only for logging when the applet runs (or is modified), not any downstream issues. That is, I can send a test message from e.g. tasker, and I can see that the applet ran. But I can’t see why the Maker-to-HomeAssistant part doesn’t work. Not AFIK, at least.

7

Weird, I don’t really see a difference. Are you also using letsencrypt? You didn’t do anything else to give IFTTT access?

8

I am. I’m also using nginx instead of HA ssl but I don’t think that should matter.

I also added spaces in my JSON {$“entity_id”$:$“light.desk_lamp”$} ($ represent where i put spaces)

EDIT: I see you have your JSON also spaced out in your screenshot.

9

The “check now” button only seems to be checking the status of the applet, last run, etc. Edit: It doesn’t seem to do anything.

I actually have to send an sms (the trigger i chose) to ifttt for my light to turn on.

10

The spaces shouldn’t make a difference. I’m using LetsEncrypt and IFTTT (without nginx) and it’s working fine for me. It’d be nice if there was a record of an error from the IFTTT Maker channel.

Also - is “yes” a correct value for “flash”? Looks like valid values are “short” and “long”

11

I agree i was just pointing out anything that i had done differently. IFTTT works for me as well. The “check now” button however does nothing, which I believe is what @Aephir is using to test his applet. Does that button do anything for you?

12

I have this exact same issue - with both IFTTT and API.AP (that returns a Webhook call failed. Error message: Webhook response was empty error). I am on v 0.40.1 and cant for the life of me get this working.

Only difference in my config is that I’m using a non-standard port https://MYDUCKDNSURL.duckdns.org:61443/api/services/light/turn_on?api_password=MYPASSWORD

I can browse to the above URL and as expected get a HTTP 405. I can also access the hass web gui via https on my non-standard port as well.

I have tweaked the baseurl in http to add/remove the non-standard port to no effect.

Will keep an eye on this thread, but will start one of my own for api.ai.

13

FYI found out my problem. Whilst all browsers seemed to be happy, a tcpdump revealed that IFTTT and api.ai were rejecting my letsencrypt certificate. A bit more digging around showed me that I should have been using fullchain.pem (including intermediate letsencrypt certificates, which you can concatenate onto your cert file if your ACME client doesnt do this for you - mine didnt). Bang. Works great.

14

You’re right, I don’t think the “check” does anything. I tried activating an applet from external (autoremote in tasker); I got the activation notification fro IFTTT but still no lights. I’ve tried with different lights (just turning on, nothing ‘fancy’ like flashing). Still no luck.

It looks like you’re right, I just copied the “flash”:“yes” from this page: IFTTT - Home Assistant. But I have also tried other versions, just specifying the lamp, and nothing else. (like { "entity_id": "light.hue_lightstrip_plus_1" } ), or an empty body (or only the empty { } brackets).

Sounds good. But… Ehh… Do you mind expanding a bit (explain it like I’m 5 yo :slight_smile: ). I do have a fullchain.pem and a cert.pem file here: /etc/letsencrypt/live/MYIP.duckdns.org/. How do I check if my ACME client does this? And if not, how would I go about doing this manually (and would I have to do this every time I get new certificates)?

15

I kept it simple, just appended the contents of cert.pem into fullchain.pem and used the updated fullchain.pem file.

cat cert.pem >> fullchain.pem (note the double >> or you will lose contents of your file).

Never append your private key to this file.

Give it a go…

16

Thanks, and sorry for the alte reply, I’ve been out of the house the last week.

First off, it seems to work now, so thanks for the suggestion!

I’m not quite sure I understand one part though. I started by just looking at the cert.pem and fullchain.pem, and saw that the cert.pem has one certificate, the fullchain.pem has the exact same certificate, followed by another certificate. Then I appended as @acs recommended. Now the first and the last certificate are identical, with another one in the middle. Is there a reason for this? It seems intuitively weird to me, that the same one needs to be there twice? Or does it just have to be the last one?

In any case, thanks a lot!

17

@aephir - you dont need duplicates in the fullchain.pem file. Just your public cert and the intermediate.

18

I can’t seem to cat these files at all, even running sudo. Is there some step that I am missing?

pi@raspi1:/etc/letsencrypt/live$ sudo cat cert.pem >> fullchain.pem
-bash: fullchain.pem: Permission denied
19

Can you manually open, edit and save the file?

20

Yeah, did it with notepad and that seemed to work.

How will this effect renewing the certs with certbot though?