Simplistic configuration UI

Hey - thanks for sending that. It made me notice what I didn’t change out of the template: the “/etc/homeassistant” portion (I had it pointing to “/etc/homeassistant/.homeassistant” which was clearly the issue). I also wasn’t running it as root.

As suspected, it was a dumb mistake. I wonder, though, if a couple of different templates for systemd files could pop into the GIT to prevent these sorts of dumb errors.

Props and thanks.

Yeah, the path of course depends on where people put the file. I have it in the homeassistant folder, but the guy who made the template obviously does not. Having multiple templates in the repository doesn’t appeal to me though. And since this is the first time this issue came up I believe it won’t be a problem most of the time.
And yes, I do run as root since I also use the configurator to edit other files on the system. That’s not best practice though. I have my setup pretty secure since I’m rather paranoid. So for me it’s not a problem. Usually though it would be better to run as the homeassistant user.

Hi,
trying run this great tool within a password protected hass gui on a same domain as hass itself

my setup is:

  • homeassistant listening on hass.mydomain.com with proxying, SSL offloading and http->https redirection done via nginx
  • hass configurator running nicely while accessed on internal network via [internal_IP]:3218

what I would like to achieve is hass configurator running on hass.mydomain.com/hassconfigurator

I’ve tried to do the proxy redirect on nginx for that but it fails due to /api/whatever calls from the UI.

Basically UI loads, but when i tries to call it’s backend it ignores the URL path where it runs. Seems it expects that it is always accessed from the server root.

Is there a way to set the baseURL for the hass-configurator itself, so it calls its APIs on a correct URL? Or isn’t it enough to just call “api/whatever” instead of “/api/whatever” (relative path, not absolute to server root).

just as a note, it’s quite a fresh install so everything should be at it’s latest versions.

This should be working. First thing that hits my eye: append a / to the path you have configured. When using a reverse proxy (which is what you want to do), a path always ends with a /. Leaving away the / would reference a single resource like a single html-file or image or whatever.
So edit your nginx config to include the trailing slash and access the configurator with that updated path.

1 Like

You were right! I’ve updated nginx rule and everything works as expected! Thank you!

Time for another update: 0.2.8

What’s new?

  • Updated CDN libraries (Ace Editor, jQuery etc.)
  • Cosmetic improvements
  • Added event observer

A brief description of the event observer:
Inspired by this thread I implemented a simple WebSocket client that subscribes to the event-stream via the HASS API. If it connects successfully, all events that happen on HASS’ event-bus are printed in their raw format for you to analyze. If for example you have a new button-device and want to figure out what kind of event it emits, just follow the output of the event observer.
This is basically the same as running HASS in the debug log-level and following the log, minus everything that’s being logged that’s not event-related.
The configurator tries it’s best to guess how the API can be reached on its own (basically at the same location where it accesses the HASS API itself). This should work pretty well if you have the HASS_API option set to your external host (like when you expose to the internet). If it’s set to localhost because it’s running on the HASS host, then of course this can’t work because you usually don’t have HASS running the client-machine. In this case you have to manually enter the correct URI.

Hope this is useful for some of you. :slight_smile:

1 Like

Thank you por the update. This tool just makes configuring (pun intended :grinning:) so much easier.

1 Like

Hey Daniel - this is still not available for Hassio addon yet. It’s still 0.2.7 - when will this be updated?

It’s not available? It should be. The PR has been merged a while ago. I wasn’t aware of this. Oo

nope - not available. 0.2.7 still showing as current.
image

You are right. I just checked and realized, that my PR has not been merged. The notification which I believed was related to this seems to have been for something else.

no worries Daniel. Glad I asked.

My PR has been merged. It should show up as version 0.3. Apparently there has been a switch in the versioning scheme, which is why the add-on version is now out of sync with the configurator version.

The docker container haven’t been updated either, since 0.2.6. Is it no longer maintained?

Docker isn’t maintained by me. I’ll ping the guy who does that. Thanks for mentioning it.

Thanks Daniel - 0.3 this morning.

@danielperna84 Hi, do you know how I could add the configurator as a panel_iframe to homeassistant and have it authenticate automatically? I tried to set the url to https://username:[email protected]:3218, but it just shows a blank page when clicked on (that port is accessible from the interwebs)

Just to clarify: the URL you use works when directly pasted in the address bar, but not when used in the panel_iframe?

It does without the authentication bit (https://mydomain.duckdns.org:3218).

It should work with the authentication bit though. You have to use exactly the string you have configured for the credentials parameter, followed by @… The hass api password is not a part of this.