Possible to create custom command line button or text input?
Use case; Currently, the built in restart option in home assistant doesn’t work so I have a shell_command in hass to restart hass or reboot the system. On occasion, a configuration change I make has an error and prevents home assistant from restarting. I can currently read the log with the still running hass-poc-configurator and correct the error but don’t have a way to remotely try to restart hass again. Would be great to be able to create custom command line options and it would undoubtedly open possibilities beyond my use. An alternative to static, preconfigured buttons would be a text input field for entering commands to be sent.
If this is already possible, sorry for my ignorance and it would be great to hear how.
Since sooner (or rather later) HASS will probably have it’s own configuation tool, I see “my” configurator only as an addition for the ecosystem. Until now I didn’t find the time though to make a proper documentation that can be added to the ecosystem-area of the HASS-site.
@Kbeesnees
Should be possible. I’ll create an issue for that in the repo. I think a texttual input will be the better way since it provides a lot more flexibility.
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.
Hi Daniel. Great work! I’m away with work so not able to update yet
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?
Thanks for mentioning it. Didn’t know about your work before.
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.
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.
Man that is so much easier than cloing the repo to local www dir
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?
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.
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.
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 , but then am redirected to a screen that says ‘File not found’ . Any ideas where I’ve screwed this up?
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?
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.
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.
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.