Configuration GUI

Development
1

It comes up from time to time that many people would really like a GUI for handling the configuration file. It seems like a reasonable request, but there are a few hurdles that have to be jumped through to accomplish this. Namely:

  1. To load requirements for each component, each component must be imported. This isn’t difficult, but it may muck up the Home Assistant server process to load everything up.
  2. Changing the current configuration real time in Home Assistant is not currently possible and would be very difficult to safely add. Adding this ability would likely create more problems than it would solve.

Here is my current proposal. It is rough and open to all feedback. First, each component would have an associated json file created to live alongside it. So, for example, you’ll have wink.py (the wink component) and wink.json (the wink profile). In this profile will be a definition of the parameters accepted in its configuration as well as maybe the events it listens to. Then, an API endpoint would be created to expose this JSON data. API endpoints would then be created to expose the current configuration and allow a new one to be loaded.

I would then propose making a different frontend from the main one. Something like localhost:8123/admin. This would become the administration console. From here the configuration could be edited and saved. It could also have a command to reset Home Assistant, loading the new configuration.

Alternatively, the admin console could be embedded in the main frontend. This would be the alternative. I like the idea of keeping it separate as it would potentially allow the admin console to be turned off (by not loading the admin component) and it wouldn’t muddy up the main interface as much.

One big(ish) challenge would be to have a JavaScript based frontend create/read yaml files would be challenging. A conversion could be done server-side by Home Assistant while passing the data through the API. I’m open to ideas here. Another potential pitfall is that restarting home assistant would change it’s PID. This means that scripts running it as a daemon would lose track of the process. This could be fixed by also creating an API endpoint to expose the PID and using this when starting/stoping the daemon. I think the biggest thing would be to get something going rather than solving all the problems up front.

… and discuss…

5 Likes
2

Some thoughts of mine, not really organized:

We want to do writing the config through a component, with an optional extra password.

We want to preserve all comments that a user might have in their YAML file (requires migrating to ruamel.yaml.

It would be nice, but not required, if all new sections to the config would be automatically loaded.

For MVP, the frontend could just show a textarea with the config loaded, a save button and a link to the docs. No real config UI. No restart button for MVP either.

If we get a real editor config, the admin part of the UI would have to be loaded on demand. Should not be part of the initial download for users (easy since we’re using web components).

Restart button is not part of the scope of this project, could be a different project. Is also very difficult because a) we want to kill the full Python process to make sure we start with a clean slate (no stale sockets etc) and b) not change our pid if we’re daemonized. Can very well keep this for people to implement themselves for their environment using a script and the shell_command component.

To prevent loading each component into memory, we could migrate to each component having a configuration file containing name, version, dependencies, requirements, services. This will make distribution more complicated and not all in 1 file anymore. I actually do not like this idea. It’s fine loading it all into memory if the user is doing config upgrades. It will only happen if we would ever get to a visual config screen (instead of a textarea).

3

More thoughts from our discussion just now:

Once MVP is out, we could add things like:

Disallow editing certain sections like command_switch, command platform for switch/sensor so we do not expose the system.

Add an API to edit just 1 section of the config file, optionally try to preserve comments.

Split textarea into 1 textarea per section in config

Convert textarea to some bad add visual widget

4

I like this idea in the sense that it could open up Home Assistant to more people. As Home Assistant evolves, the more user friendly it gets, the higher the adoption rate (IMHO). I think it is still an application that some consider too technical for them to setup and run. Mr. Balloob, you and I have seen and responded to some of the same posts on other forums and we have both seen the discussion about the skills required to setup Home Assistant. BTW - I’ve been posting back that it has changed and is much easier and more documented now.

As an anecdote, applying to the above and what I have written below, it reminds me of an Algebra class I had in high school. The teacher taught the same class year after year. And had done this for many years. I believe he was unable to get into the minds of his class, and see the difficulties we had from both his teaching style, and the material. It was all so familiar to him that he just couldn’t relate to us. So we all struggled because he could not understand that we did not understand. Every night we had homework. It covered new material that was not taught to us in class. Then the next day we spent the day going over the homework and that is when he threw out the tidbits of teaching. But we all got bad grades due to his backwards system. If he related at all to us and our ignorance, he would have taught us the concepts before giving us the homework. Rather than given the homework, grading it, and then teaching the material, after we all struggled to figure out the assignment the night before…

Here is where I see value in the GUI. One, reducing typos. It could catch improper indentation, forgotten ‘:’, forgotten ‘-’, those types of things. Two, it could expose what options are available per device/component/group type for automation. This is where I need help. I have yet to fully tap into the automation potential of HA due to my lack of understanding what elements are available to me, and how to implement them in the config. I’ve become a bit frustrated in this regard. I’ve brought this up multiple times and I am pointed to the existing documentation. But as I have said before, my use of automation stops where the examples stop. Honestly, I just don’t know what options are all available per component or group, and I also sometimes don’t know when I need to use a particular form of formatting. If this was a class, I would be failing this section.

Finally, I think this sounds like a large amount of work to produce this GUI. And more to maintain from here on out, and greater complication on the backend. A standardized system, as mentioned with the included ‘.json’ file with the device type is a great idea. I’ve never been a fan of the configuration system in HA though. For me, using one file creates a messy, disorganized lump of information. I know essentially there is nothing wrong with a single config file, it is just something I feel like could maybe use re-evaluation. For example, how about a folder called ‘config’ and any ‘.yaml’ file inside there is read for config information? One could have a ‘groups.yaml’, an ‘automation.yaml’, a ‘scenes.yaml’, a ‘script.yaml’, etc.

A GUI could be used to allow for the creation of groups. Fill in a name, check the box next to the members, and save. Then the admin console could list the groups and the group’s members. Another thought is each automation element could, on the backend, be built, defined, and have requirements to determine if it is applicable to the component or group. Then when building the automation, a list of applicable automation types could be visible for the component selected and only those that are applicable to the component are accessible. When building an automation, the user selects what they intend to apply it to, and the list of available automation elements is listed to be plucked and linked to their selected item.

Regarding debugging, for the less technical, or the ignorant, this can also be frustrating. I again am without my WeMo Insight switches once again. This has been a recurring problem for me. I have not posted it on here because it seems like I am a skipping record and the busier you get, the more annoying these ‘please help me’ requests must become. The error I am getting is similar to what has happened in the past. I’ve tried to fix it myself based on what I see in the error but I have not been successful. I would love to know how to better debug HA so that I can fix it without having to ask for help. Maybe in the documentation there could be some added guidance on troubleshooting errors yourself. Like what to look for, what to do to get better information on the error - like when you get an error some options for outputting more info to the terminal or a log file.

I am curious about the JavaScript frontend idea. It seemed kind of out of the blue. Are you saying that would make for a better frontend or are you talking about offering HA in more than one language? Just curious.

Thanks,
tobias.

2 Likes
5

Thanks for the feedback. A quick answer to your last question. The current frontend is also JavaScript. It is the language used for client side scripting in websites.

6

Hi Ryan,
I see. Thank you for the clarification.

Regarding this comment:

If configuration is to be moved to GUI and API, I understand this would be a big leap, but wouldn’t a potential solution be to start using .json for config information and stop using yaml? I assume this would require full commitment to a graphical interface for configuration, but should not be an issue for javascript or python to read/write json.

I guess the potential issue here is for most there would be no more text editing of config. All would have to use whatever is created to managed the config. I realize some would know how to manually edit their json config but it would be a lot different from a file intended to be manually edited.

Regardless, it all sounds like a lot of work.

7

GUIs for hierarchical configuration files are hard. I’ve worked on some projects like that in the commercial space and they were nightmares - for the transform between configuration file format and Javascript objects, general maintainability as the underlying configurations evolved, and handling of types/default values/labeling/validation/etc.

To support all possible configurations, you have to have a lot of controls and a lot of options. You either end up building a generic YAML/JSON/XML editor, or a really complex GUI. Sure, we could make a GUI that configures things like devices pretty easily, but imagine the GUI necessary to configure an automation with a script, for example.

8

Agree. Keep it mean and lean. I watched Drupal go from a swiss army knife to a bloated tool for less technical users. But in doing so many compromises were made, and if it broke, you still had to know your stuff. Remember the UNIX philosophy - lots of small well defined tools.

I do have a query about capturing simple config params for a sensor via the GUI. But I am very new so probably have just not found it yet.

9

Ace Editor might work well. It supports yaml and python and there already appear to be some web component wrappers for it.

Couple this with some UI to list, create, and delete files in the HA config directory and it would enable a decent experience for full configuration of HA. The ability to edit the config in-app plus a default config that is more self documenting with lots of comments and links might make things a lot easier for new users (and more convenient for experienced ones).

10

As someone who has had brief exposure to some programming languages but has never really written a program (unless “Hello World” counts) and is thoroughly enjoying getting HA to work, I find the YAML configuration and and testing a constant PITA.

I’m sure there are some well informed reasons for using YAML files that I’m just not experienced enough to appreciate but I am constantly fighting with it to get it to work.

If I am understanding @imagio’s suggestion correctly, its to include a validator/editor in the app to decrease the likelihood of syntax/formatting issues, which I think is an excellent idea! :grin: Like he said, easier for new users, and convenient for experienced users.

Another welcome addition would be to able to reload the config from the GUI without having to restart HA, if possible. Or failing that, restart HA from the GUI.

I have really enjoyed watching this project develop since discovering it 6 months or so ago and am looking to contribute in any way I can. Keep up the good work @balloob!

1 Like
11

My 2 cents.

I would never vote for a ‘Configuration’ GUI. It is a lot of work to build in the first place and even more to maintain it. I rather have the developers use their free time to make improvements to the core instead of a configuration GUI. Configuration should be a ‘one time’ thing, then it should just run. I want the running part to be as stable/fast/best as possible.

I can live with YAML, actually i’m rather fond of how it works now. My configuration is stored in neat files with comments (very important) and is sent to github/bitbucket for safe keeping. There is no question about what configuration is running, since it is all in one place.

The only ‘gripe’ is that sometime when i have typos in my YAML the feedback is less then i would want.

1 Like
12

Just to give an idea of a GUI for automations, check out

They have a graphical rule editor that is much more powerful than IFTTT.

Having something like this to define rules would especially help inexperienced users to try HASS.

13

I am currently beta testing conradconnect and the rules ui is from WayLay.

It reminds me a lot of Octoblu’s Designer

14

I created a quick POC of the ACE Editor in browser for YAML. Will look at folding in some kind of lint in the future.

1 Like
15

neither of the links you provided are still working in the github post. 404 not found @SyncroVox

16

Thanks for letting me know. The two links in my gist comment have been corrected.

17

I think, at least for a good while, the config GUI shouldn’t actually change anything within Hass, but instead generates YAML and display it in the browser. As an example, you pick your automation trigger, conditions, and actions in a menu that shows you the available options given the entities you have, and it generates and displays the automation block to paste into your config.

The primary issue with config files is that discoverability is basically nil. They tell you absolutely nothing about what you can do, unless you’ve already done it; you’re dependent on external documentation, which may be old or wrong, is usually incomplete, and in any case cannot give you context-sensitive information specific to your particular system. A config GUI, first and foremost, acts as a sort of browser, directly communicating your options. So, a config GUI that does nothing more than generate YAML and show it in the browser would fulfill the bulk of the need.

In any case, a settings menu cannot be avoided entirely, because some platforms (particularly Z-Wave) expect Hass to read and change settings within the system the platform manages, things that due to their design would be unreasonable to read from a config file every boot. And we still need a place for configuration and setup actions like adding devices that require a special pairing process (again, mostly Z-Wave).

18

As a recent member to the community I have been investigating HASS for suitability not just for my home automation but for use in a solution for others. The frontend GUI is great. But the thought of editing config files just makes me want to barf (sorry for the candidness). I’m a software engineer and days of editing xml files are torturous. yaml is a bit better but its still the same effect. I get that using yaml files in the beginning allowed development to focus on other more important aspects of the system. But if this system is to grow this is thing that has to change. Saying that it is a one time thing is not correct, as you may add new automation rules or add new switches etc and it overlooks the main pain point, ie. that it is not easy to use.

In comparison, Openhab has habmin, an addon UI that simply allows you to edit openhab configurations in the browser. This would be similar to using the ACE Editor as proposed above. This could be a MVP, but it still relies on yaml in the back which may not suit if the end goal is somewhere else. The newer Openhab 2 also has a new Habmin 2 interface (github.com/openhab/org.openhab.ui.habmin). One of the big differences is the addition of a graphical rules editor

1280×628 184 KB

Conrad connect takes this to another level with a nodered https://nodered.org/ style configuration and saved IFFT style recipes that you can add and edit with just a few clicks. It looks amazing.

Configuring devices and adding automation rules are the clunkiest thing with most open source home automation systems and if HASS is to grow, this is the one area that needs to evolve. (note the absence of config files with commercial products)

There does however appear to be some serious technical obstacles as mentioned above such as reloading configuration vs restarting HASS and creating GUI’s for hierachical configuration files. Note that Openhab automatically reloads updated config files, but still uses convoluted config files. Also worth thinking about is that if there was a config gui, there may be less support for people having configuration issues.

Sorry for the continued references to openhab, its just been something that I’ve been looking into recently. Openhab has some nice points, but also a lot of negatives as well (its using 10x the ram in my test environment)

2 Likes
19

As a recent adopter of HA I can only use my personal experiences as a benchmark - which is probably a good thing in terms of feedback for these types of discussions. A set of fresh eyes so to say.

My background is in Software engineering and systems architecture and in my opinion user experience is extremely important when it comes to successful implementations or building a market presence.

I am finding the learning curve steep and frustrating in terms of getting a home configuration up and running. Modifying config files, learning the pre-requisite structures and required syntax, formatting etc - it’s low level techy stuff. How the system chooses to store config is one thing but how users are expected to tell the system what they want it to do is a completely different story.

I agree with the need for prioritisation of developer effort but we need to remember that all the trinkets under the sun are of no use if the system is too difficult for people to work out how to make them work.

I think the community may need to think of user skill levels and knowledge when trying to use a system. Not everyone knows or wants to know how yaml works or how to run vi or how to run scripts to restart.

Moving into a usability discussion helps open up the market and helps grow the user base. Taking a system out of the hands of technical folk and moving it into the hands of user experts is crucial in tapping into the real opportunities.

Just my 2 cents worth.

Sorry … lots of words but I feel a config tool would be a very good thing.

7 Likes
20

Just an spontanious idea: HASS is doing config-validation using voluptuous. So internally HASS already knows how a valid configuration has to look like. So in turn it might be possible to develop some helper, that turns all the config-schemes defined for the available platforms and components and turn them into simple HTML-widgets to display in the HASS UI. For the beginning this could just output yaml which could be pasted into the config-files. Maybe a small first step, but beginners might appreciate that.

1 Like