I tried to get remote access working and found a lot of the guides to either be a bit outdated, or not applicable to me. Most examples use Duck DNS. This is because you’re going to want to use HTTPS, which means you need a SSL certificate, which means you need a domain to certify. That’s what Duck DNS will do for you; it provides you with a domain that you can certify. Of course, you also need this domain so that you have a reliable address to connect to since you likely have a dynamic (changing) ip address.
But I already had a domain from freedns and didn’t want to do the Duck DNS route. The difficulty I had was that the Duck DNS addon method somewhat automatically seems to take care of a number of other steps for you, with Let’s Encrypt etc., so it’s not as simple as skipping the Duck DNS part of these guides.
So, if you’re like me, and don’t want to setup a new hostname with Duck, then follow along. If you don’t mind using Duck, then by all means use that addon and those guides. It’s probably easier.
Get a SSL certificate with Let’s Encrypt Addon
- Install the “Let’s Encrpyt” addon. I’ll assume here you are running Supervised HA and have the addon store. This is going to generate you a certificate for your domain name (that you already have).
Starting this addon runs the certbot program to reach out and get you a certificate. Before you can start it, you have to enter in the config.
Options
- The challenge option can be http or dns. The dns option is a bit nicer, but only supported by certain services (not mine)
- Enter your domain, your email
Network
- Here you need to define the port you plan to forward to from the outside for generating the certificate. My HA server already had something on port 80, so I set it to something different
- Forward port 80 on your WAN side to the port you defined here
- Start the addon and go over to the logs. Keep refreshing to see the progress of the cert generation. If you’ve forwarded the port correctly, you should get a successful result and the addon will shutdown. It says that certbot will have to re-cert periodically, which you can do by setting up an automation (not covered here). Also, when starting the Let’s Encrypt addon it will check for recert, and exit afterwards.
Port Forward your hostname to your HA Server
You’ve already now port forwarded port 80 for the cert bot, but now also port forward your WAN IP to your HA server’s ip, port 8123 (standard HA port).
Test this worked by going to http://your.domain.com:8123 in your browser. At this point, your HA server is still using regular HTTP, so the work you’ve done with Let’s Encrypt isn’t coming into play yet. So if you have problems connecting via your domain it is because your port forwarding isn’t working, or your domain isn’t resolving to your ISP IP address.
Enable HTTPS on your HA Install
Home Assistant needs to be told to use https, which you can now do since you have a cert. To do this you have to add the following to your configuration.yaml:
# enable https
http:
ssl_certificate: /ssl/fullchain.pem
ssl_key: /ssl/privkey.pem
You must restart your HA server for this to take effect. Once you do, you will no longer be able to connect with regular http:// connections. Locally, you have to use https://your.domain.com:8123, or https://yourlocalipaddress:8123.
Configure your Companion App
You’re likely doing this so you can access HA from your mobile phone, so you’ll want to configure your phone’s App. Go into the Configuration | Companion App menu and update your internal and external addresses to both be your domain address with the port. Note that this means when you’re on your local network using your phone, it may be connecting out through the www first, which isn’t efficient. You can correct this by re-directing. I’m using AdGuard (excellent pi hole alternative), to do a DNS rewrite, which tells my internal devices that when they’re trying to resolve my HA hostname, to point to my internal IP.
If you do not give the companion app the hostname, and give it your internal IP instead, it will tell you the certificate is not valid. This is normal behavior because the certificate is for your hostname only, and cannot be for your internal IP address.
There you have it. You can now connect remotely using your previously created dynamic hostname.