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.
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.
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.
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.
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.
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.
@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)
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.