Simplistic configuration UI

Share your Projects!
122

Thanks @danielperna84 this is a lovely little tool and works great!

123

Seems as if editing posts has a limit of 15. Hence I can’t update the starting post anymore. :frowning:

Anyways, there’s a new version available: 0.1.6
What’s new? This:

Executing the commands provides a rudimentary way of reviving a possibly dead HASS. It’s just for executing simple shell commands. So nothing fancy like a tail -f foo is possible.

A minor change for the UI is, that we’re now using the same icons as HASS. While doing the switch, we’ve now also added an embedded browser (just like for the components) to search for icons you can use for your entities etc… So you now have all the available icons two clicks away. :slight_smile:

Hope you like it. :slight_smile:

5 Likes
124

Hi Daniel. Great work! I’m away with work so not able to update yet :frowning:
Wondered if you saw my index/browser for MDI icons specifically selected for HA usage?

I have selected and categorised ~200 icons that work well with HA. Maybe you can incorporate this list so people can save time searching the huge number of icons in MDA?

1 Like
125

Thanks for mentioning it. Didn’t know about your work before. :slight_smile:

I don’t think a pre-selected list of icons is what should be part of the configurator. Aside from adding quite a lot of code to the already huge configurator (the material design added a lot of weight), having the full list provides access to everything possible. What if I don’t find what I need in the selection? Then I’d have to check the official site to see if there’s an icon that didn’t make it into the list to make sure if there really isn’t the icon I’m looking for.
I guess this really just boils down to personal taste. Since the included list has a search box, people would still be able to find what they’re looking for quickly enough, even though there are a ton of icons. At least if you know what you’re searching for. :smiley:

Besides that, your work can be added to HASS so easily, that whoever wants to make use of it can do it. Actually even without pushing the file to the local machine. A pretty well kept secret of GitHub is, that HTML files can als be accessed in rendered form with a link like this:
https://rawgit.com/james-fry/home-assistant-mdi/master/home-assistant-mdi.html (only for developement)
Have a look at https://rawgit.com/ and consider publishing a release of your code to allow people embedding it via CDN. :slight_smile:

1 Like
126

Man that is so much easier than cloing the repo to local www dir :slight_smile:
I was familiar with raw access (needed to use it to get screenshot in the readme.md) but I had assumed that html would not be served correctly - i.e. would not pick up the other mdi css, font etc files
Thanks for the great tip! I will update the gh readme and linked post when I am back at home.

BTW I agree with you on having access to all icons - who am I to dictate what people want their HA to look like? :slight_smile:
That said, I found that browsing MDI site is pretty painful - search is slow, categorisation is limited etc.
I’m totally happy to have an icon browser separately. the only bugbear for me is that since both the configurator and my mdi index are both panel_iframes you cannot switch between the two - need to open HA in two browser windows. Not a big deal.
Looking fwd to checking out your new version at weekend.

1 Like
127

Hi Daniel,

I’m running HA in a docker. The docker has a config folder which is mapped to a permanent folder on my SSD that has all of my yamls. So two questions:

  1. Is it possible to map configurator.py to be located in folder on my SSD so that docker updates do not delete it? If so, how/where do I do this?
  2. I’d like to do the same with settings.conf, is it a similar process to #1?
128

You can run configuration.py from the same volume as your config yamls are located. Works great for me using ha on docker

129

for me this is my config yaml:

panel_iframe:
  configurator:
    title: Configurator
    icon: mdi:wrench
    url: http://192.168.1.9:3218

And I am starting configurator.py from the same dir as my configuration.yaml file, which is the /config mapped volume in docker run command.

130

Thanks for this. I finally got around to updating the GH readme to include your tip.

1 Like
131

Almost a month after the last release there now is a new version: 0.1.7
Here’s what’s new:

  • Fixed incorrect numeric state option
  • Removed check config option (HASS has changed, not useful anymore)
  • Added reload for groups, core and automations
  • Proper logging on the server side (useful for supervisor usage)
  • Update Materialize + UI fixes

Sad but true, I had to take out the check-config option. It wasn’t working for a while because HASS has done some changes with the way I used to integrate the service. The service is still callable, but it doesn’t provide any useful output, and the persistent notification it used to push to the HASS UI seems to have vanished as well. So for now there’s no was to verify the configuration is valid. -.-

However, you can now reload the core (friendly names etc.), groups and automations. Especially reloading the automations will probably be a big time saver and spare us from reloading all of HASS.

Hope this release works well for you. :slight_smile:

3 Likes
132

All we need now is a group config that works, as opposed to the one in the HA config panel! LOL

Nice work and thanks!

133

I installed and configured 0.1.7 this morning, and I am loving it so far. I can definitely see myself using on a regular basis. I have it working standalone via the Rpi IP and port 3218.

I am now working on getting it embedded in HA, and have run into an issue. I am using nginx as a proxy server for HA, and I set up Configurator to behave similarly, pointed to mydomain.com/configurator. Since nginx is taking care of SSL, I have left that section as is in configurator.py. When I go to mydomain.com/configurator, I am prompted for the Configurator username/password :+1:, but then am redirected to a screen that says ‘File not found’ :-1:. Any ideas where I’ve screwed this up?

134

Hhmm, I don’t have any spontaneous thought. How do you run the configurator? Having some log-output may be useful. I would compare the reuests nginx is serving to those that arrive at the configurator.
And does access still work from inside the network with just external access resulting in the 404?

135

I am running configurator via systemd. Internal is still working great, so actually, not having embedded in HA is certainly not a deal breaker.

Nginx logs are not giving me much useful info. I am not getting anything in the logs when I try to access the site. I may need to look into adjusting my logging settings.

Where can I find the configurator logs? I poked around, but didn’t see anything obvious (to me at least).

Based solely on the text in the login screen, my hypothesis is that this is due to the SSL configuration. When I access internally, there is a note that the password will be sent unencrypted. When I access via the domain, it says it will be sent securely. I am thinking that the site wants to be setup for SSL when accessed via https, but fails since it isn’t. But I don’t know exactly how to test that theory.

136

The configurator logs to stdout. I don’t know where systemd redirects that to. My suggestion. Stop the systemd service and start the configurator manually and keep the terminal open while testing. That way you will see what the configurator is doing.

Since you are talking about a login-screen I assume, that you currently don’t even get anywhere near the configurator. The authentication the configurator uses is the good old HTTP auth, which has no fancy form or anything like that, just a modal to enter the username and password. So what you see probably is still related to HASS itself, and upon login you should actually see HASS, not the configurator.

137

Did you consider creating a docker image with the configurator?

138

No. The installation is so easy that using docker for this kind of seems like overkill to me. Besides that, this could intruduce further difficulties since it would make everything more complex. But if you see value in a docker image, feel free to fork and implement it. :slight_smile:

139

Thanks for your help with the log location/advice. That really helped. After working with the nginx log, I figured out that the proxy settings were redirecting to 127.0.0.1:3218/configurator, rather than just 127.0.0.1:3218. So it was an error on my part with the nginx config. Fixed that, and I am now able to access externally.

Thanks again for helping point me in the right direction.

140

I need a little help setting up configurator. I am using All-In-One Installer and Let’s Encrypt and DuckDNS.

I managed to get configurator running and integrate it in HASS, but I am getting a warning in Chrome, that connection is not secure:

My mysettings.conf:

{
    "LISTENIP": "0.0.0.0",
    "LISTENPORT": 3218,
    "BASEPATH": "/home/hass/.homeassistant",
    "SSL_CERTIFICATE": "/etc/letsencrypt/live/XXXXX.duckdns.org/fullchain.pem",
    "SSL_KEY": "/etc/letsencrypt/live/XXXXXX.duckdns.org/privkey.pem",
    "HASS_API": "http://127.0.0.1:8123/api/",
    "HASS_API_PASSWORD": "xxxxx",
    "CREDENTIALS": "XXXXXX:xxxxx",
    "ALLOWED_NETWORKS": [],
    "BANNED_IPS": [],
    "BANLIMIT": 0
}

  1. Is HASS_API correct or do I have to give DuckDNS address?

  2. If I want to access configurator from the outside, I have to open port 3218. I already have open external port 443 to internal port 8123 (HASS). Now I need to forward external 443 to internal 3218?

141
  1. The HASS_API is correct if HASS and the configurator are running on the same machine.
  2. You can forward whatever port you like. To keep it simple, just forward 3218 to 3218.

I assume you’re using the panel_iframe. In that case you have to configure it to point to yourdomain:3218, where 3218 is the port you are forwarding to the configurator. Don’t forget to set up authentication. Otherwise external access to your configuration as possible for everybody.
In any case, you should also be able to directly access the configurator by browsing to yourdomain:3218 as soon as the port forwarding is active. Essentially the panel_iframe has to point to the URL that enables you to access the configurator directly from outside.