Hass Configurator with DuckDNS and SSL on HA

So I have HA configured with DuckDNS for GA and works fine at https://mydomain.duckdns.org:8123

If I access http://mydomain.duckdns.org:3218/ it works fine (configurator opens up)

If I access https://mydomain.duckdns.org:3218/ it says “ERR_SSL_PROTOCOL_ERROR”

I have put http://mydomain.duckdns.org:3218/ in my configuration.yaml for HA and when I click on “Configurator” it just has a blank page (no error) in the frame

I can access all the above via local IP as well… same issue

I am accessing it locally and have port 3218 -> 3218 (not sure if I need this) and 8123 -> 8123 forwarded in router.

What am I missing here?

Basically, want the configurator to work with my duckdns URL and in frame.


Any help guys!!!

Did you set SSL to true in the add-on configuration and restarted the add-on?

You must also use https://… in your configuration.yaml as add-on url as embedding http in an iframe of https isn’t allowed.

my HA yaml has https

    title: Configurator
    icon: mdi:wrench
    url: https://mydomain.duckdns.org:3218

But what all to change in hass config settings.conf ? I have the default

    "LISTENIP": "",
    "LISTENPORT": 3218,
    "BASEPATH": null,
    "SSL_CERTIFICATE": null,
    "SSL_KEY": null,
    "HASS_API": "",
    "HASS_API_PASSWORD": null,
    "CREDENTIALS": null,
    "BANNED_IPS": [],
    "BANLIMIT": 0,
    "DIRSFIRST": false,
    "SESAME": null

SSL_CERTIFICATE & SSL_KEY must be configured to use the same cert as the one you are using for hass itself.
HASS_API should link to https://mydomain.duckdns.org:8123/api/
HASS_API_PASSWORD must be configured with the password you are using to log into hass from the outside


I have a feel something is not working as I am using docker that could be some config issue as well

So for configurator I can open via http://domain:3218 but https://domain:3218 doesnt work…


I have mounted the hass config directory as hass-config inside which the SSL cert resides… Maybe its not reading it properly?

    "LISTENIP": "",
    "LISTENPORT": 3218,
    "BASEPATH": null,
    "SSL_CERTIFICATE": "/hass-config/ssl/fullchain.pem",
    "SSL_KEY": "/hass-config/ssl/privkey.pem",
    "SSL": true,
    "HASS_API": "https://XXXX.duckdns.org:8123/api/",
    "CREDENTIALS": null,
    "BANNED_IPS": [],
    "BANLIMIT": 0,
    "DIRSFIRST": true,
    "SESAME": None

Sorry, I’m of no help when it comes to docker configurations. @flamingm0e might be able to help here…

You did restart the configurator container after changing its configuration, right? Are there any logs available that may help to pin down the problem?

Sorry for late reply…

There is no hass configurator log and nothing in HA logs for error…

All containers were restarted several times…

I have a feeling… Do I have to forward 443 or something to container?

On check docker logs I see wierd stuff

INFO:2018-03-19 09:52:22,067:main:IPADDRESS - code 400, message Bad request syntax (’\x16\x03\x01\x00É\x01\x00\x00Å\x03\x03\t%HzWÚ«xõ9ä\x99w9\tÿþf§]Z\x00×Ï\x07I\x1dw¬beî\x00\x00\x1c’)
INFO:2018-03-19 09:52:22,067:main:IPADDRESS - “ÉÅ %HzWÚ«xõ9ä™w9 ÿþf§]Z×ÏIw¬beî” 400 -

To me this looks like your configurator is not using SSL, and the request you are makin is encrypted. Please check the paths to the certificate and key to ensure SSL is working properly.
You can also test basic functionality by accessing the configurator directly. The domain is only needed to not get warnings about the certificate. But if you are aware of that there’s no problem going to to just check if it’s running.

I dont get what is wrong… I have copied the same private key and full cert to a mapped location… pointed another mount to same location where original cert is… same location being used by HA docker and SSL works there…

Got into docker with exec command and it can see and read the SSL files… https:// simply fails… http:// works

Has to be something to do with permission… tried changing that as well for all files but to no avail

Since you know how to view the logs, have a look at what it says when the configurator starts. If it’s successful with loading the certificate it will say something like Listening on https:/.... If it doesn’t say that, then it had trouble opening the certificate. On the other hand, it actually shouldn’t start at all if it fails at that state. Reverting back to plain http is not what should be done. It should rather raise an exception and terminate. With that in mind it may be that there’s something wrong with your options-file.
Looking at what you have posted earlier, there is indeed an SSL: True in your config which shouldn’t be there.

Edit: please post your current config-file. Looking at it further it’s definitely invalid. Sometimes it says None, sometimes null. One is the Python way, the other is JSON. You can’t have both. So that’s why actually nothing you have configured can be working.

Thanks… I seem to have it working… I think it was permission issue to SSL folder and it unable to read… My setup is that mounting the SSL directory on both HA and hass-config dockers… this way dehydrated script can renew the cert in the SSL folder and maintained in single location… Also able to share the certificate with other dockers as needed…

Current config - please let me know if anything wrong (previous post config was changed a while ago)

    "LISTENIP": "",
    "LISTENPORT": 3218,
    "BASEPATH": null,
    "SSL_CERTIFICATE": "/ssl/fullchain.pem",
    "SSL_KEY": "/ssl/privkey.pem",
    "HASS_API": "https://mydomain.duckdns.org:8123/api/",
    "CREDENTIALS": "someusername:somepassword",
    "BANNED_IPS": [],
    "BANLIMIT": 0,
    "DIRSFIRST": false,
    "SESAME": null

One query… How does configurator behave with default file open? will it do the last file? or can we set it in config to open a default file everytime?

ALso in this setup http:// doesn’t work and https:// does ?? intentional ?

This config is looking good. This should be able to load without problems.

Answer 1: The last file that has been edited will be re-opened, assuming you are using the same browser. The storage of the browser is used to save such data. So on another system that never has used the configurator before it should open with no file open.
Answer 2: Sort of intentional. That’s how all webservers work. They are either encrypted or not. You can’t have both at the same time while only using one port. If you want both you need another container (which more or less equals two webservers) which at least externally uses another port. Within the container of course it can remain at 3218.

So just a question. Configurator working ng correctly however when I open a file it is on a grey background and I have to click a few times to be able to actually edit it. On my iPhone it’s a nightmare getting to the point I can edit a file. What am I doing wrong?

There’s on open issue for that problem: https://github.com/danielperna84/hass-configurator/issues/79
I’m however not an UI guy, so I’m dependent on the help of others.

In general it shouldn’t be a problem on your phone. Instead of tapping you can simply swipe. And when there’s more space on the screen, you just have to click on the left of that hidden line you’ll have to find. If you know where to click it’s working reliably.

I’m getting no auth header received on both my iPhone and iPad at the moment. On my PC I removed all allowed networks…

Just logged in.

I can swipe on the screen anywhere but I can’t get rid of the list on the left. The file I opened is on the right but it’s greyed out and tapping, swiping does nothing…

Tried again and it seems a tap on the dividing line but on the bar at the top (or maybe just on the line) but a tap (not swipe ) on the bar seems to work…

Technically it should be like this:

  • Tapping works on the left of the imaginary vertical line
  • Swiping works on the right of the imaginary vertical line

On mobile there’s usually not a lot of space. When I have the filebrowser open I only see a very slim grey area. In this case I have to swipe from the edge if the screen ti the left. That’s because only the grey area ist “listening” for the swipe. swiping above the filebrowser does not work. Which is totally counter-intuitive because that’s where everybody would expect swiping to work. But sadly that’s not how it is.

So to sum this up: yes, hiding the filebrowser can be annoying. So if anyone experienced in UI could have a look at the issue posted above I’d really appreciate it.

So stupid question - but which direction should I swipe? (I’m also getting the no auth header received error - how do I resolve that? This is in the app on my iPad - chrome is ok)

To the left. Like swiping the filebrowser out of view. It’s on the left, which is also the side from which it slides in. So to bring it out of view it should be swiped back to where it came from.

I don’t know about the app because I don’t have any iOs devices. The message you get is a result of the app not providing the required credentials to access the configurator. So it may just be, that the app does not have the ability to ask for credentials or pass them automatically in case you have set them in the URL in the panel_iframe configuration.