Thanks for letting me know. The two links in my gist comment have been corrected.
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).
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
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
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
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
In my view there are two main areas to cover in terms of configuration GUI:
- Configuration
- Automation Rules
In terms of configuration I think it is a little painful to do using a YAML file but still doable for most of the people who try out the HA.
However the biggest challenge is to actually get the whole automation thing easy to create. While I am able to turn things on and off around the house, my devices are really dumb and I need to be able to make them smart easier than painfully working my way through with the YAML automation config.
There’s an interesting post about using the node-red with HA: Node Red integration - maybe it is worth going down that path? I mean without reinventing the wheel but making these two work together, or reusing some part of their software?
While we would love to build the perfect beast, in software there is never enough time to do everything you want so there is always compromise. The front end UI is used more often and it is what is put in front of the users. It should get most of the focus but the current configuration must improve if we are to reach more users. As many have stated so well above, the current process of starting with nothing, you copy sample code into a single config file and restart to test it, is severely lacking. If you copy your sample incorrectly, you can break everything. Any change that at least helps point you in the right direction would be a big help.
I like Tobias’s thoughts above about multiple yaml files in a single directory. Rather than giving you just a sample to copy, it should actually provide what is needed for that feature. An editor with a form of Intellisense would help to know what options are available. If an individual option can be reloaded without a restart, that would be great. Should you have to restart everything to reset a timer? To debug an automation? Changing any simple option? Any new feature should be able to provide the keywords needed for that option. HASS knows how they should be formatted within an editor.
I said somewhere else that the route to go in the beginning is for a GUI that creates the YAML as it is at present (and indeed until all the requirements of the GUI are solved). This allows existing working YAML to continue to be used (and developed). Allows new users to easily create and play with HA without needing to know about YAML. In the beginning it ought to be possbible to develop the GUI such that the basics are created in the GUI (and not being required anymore to be configures in YAML) Lat/Long and some of the simpler HA functions. In this way as the GUI encompasses more functionality direct creation of YAML is not needed (but tweaking would be possible whilst YAML is an intermediate step.
Online configuration changes is a step too far, most USERS would live with things as they are at present especially if it became impossible to create YAML through the GUI that didn’t work. Preset choices as part of configuration is a more important must have.
This has to be a must and top priority if HA is to get USERS.
Hi, I’m a newbie to HASS and I was surprised there was no interface for something as simple as creating rooms. I really like the capabilities of HASS, but as someone that has been programming HA systems for a long time, I have to agree with the comments above. Even just a yaml generator of some kind would be a big improvement.
Since it hasn’t been mentioned yet:
There’s a JavaScript library that’s capable of converting between yaml and JS objects: js-yaml (demo).
This might be helpful since within the UI it might be the easy route to just create JS objects and then dump them into yaml.
1 Like
You can use groups in the UI to create rooms easily enough - I have seen several HA systems that insist on showing a graphic of the floor plan as if it is a major feature - IMO it doesn’t add much and clutters the screen especially if you are on a tablet or a phone, the HA interface works great on either as well as a full browser.
Although having better config and a nicer GUI are highly desirable - that’s not how Open Source works. In a highly collaborative venture like Home Assistant, things get done because people want to scratch itches. I built AppDaemon, HADashboard and SceneGen because they solved particular problems or needs. Since I was solving a problem close to home, I was willing or even compelled to spend 100s or perhaps 1000s of hours working on these projects, had enormous fun and got a great sense of satisfaction, and at the end, I was happy to share the results and I am really gratified that other are finding it useful. Would I have wanted to spend 1000s of hours of my spare time on weekends and evenbings building something I didn’t need? Unlikely …
The fact that no one has built a config UI yet means that no one has felt the need to scratch that itch yet. I don’t disagree that it would be really cool, and a huge asset to HA, but statements along the lines of “This HAS to be done so that HA is taken seriously” miss the point of how it got to where it was so fast. What if the top devs burned themselves out building a UI that they didn’t want or need, and abandoned the project as a result?
We can all hope that soon, someone with great UI experience and a burning desire to bring that to a HASS UI will come along, or that an existing dev gets a bee in their bonnet to build it, but until then I am happy to make do - Home Assistant is incredibly functional in all other areas and only getting better.
10 Likes
Hi, point well taken, I was just reacting to my initial experience. On the positive side I was able to get really good help immediately.
1 Like
That wasn’t aimed at you specifically - I quoted you because of the comment about groups which might have helped 
This is a very friendly group of folks, hope you stick around.
Oh, no offense taken, it really was a good point, and I can see that things around generating the interface will definitely move forward in time.
There are many, many things about HASS that I really like, not the least of which is the Python 3 language, the enormous body of device support, and the very helpful forum.
Being able to control RF and IR via the Broadlink hub was a huge benefit for us, and I was so glad that I did not have to resort to the Android bridge for that. I find Android to be really creepy, it wanted me to grant all kinds of private permissions before I could do anything with Tasker. Mongo not like.
Hey, cheers, I’m all in!
1 Like
Aimc - while I haven’t had a chance to use them yet, the components you built could go a long way to help with home automation. You saw a need “an itch” and built things to scratch that itch. You didn’t just build them for yourself but put in the extra time to build something that you hoped would be useful to others. I believe most people believe when it comes to configuration there is a very big itch but how to relieve that itch is the question. There could be several people investing their time right now to address this only to find out someone else builds something a little bit better or gets accepted before they complete their work. That is one of biggest reasons for open source development burnout. Another issue with open source is because everyone is working independently you end up with 27 different ways to do the same thing and the common goal gets diluted and fragmented.
What if you had support and input during the development of AppDaemon to define exactly how it could be integrated directly into HASS and input scenarios? Would that have given you more encouragement? The ability to restart apps is a big plus. As you state home automation should not require human intervention. I am looking at automating server operations (i.e. power on external drive, backup partition, power off one drive and fire up the next one and continue the process). What if AppDaemon was a plugin that could be directly integrated into HASS rather than copying data from HASS? What if it could be called from HASS with parameters? A single dawn to dusk app could be written with HASS passing the switch data.
Having a collaborative effort focused on a single UI would go a long way towards additional adoption and mass acceptance is the ultimate goal.
Point well made, ‘itch’ isn’t the way a lot of us ‘users’ would describe YAML and configuration. My metaphor is ‘brick wall’ because there seems to be no way to convince the existing enthusiasts that there are almost certainly 1000 users lurking for every developer. 999 of each of these ‘lurking’ users will never make a contribution to the development of HA, except to complain. BUT that should be where development effort should go, not into yet another niche interface to solve an issue for the existing audience.
So for Open Source to really work, development should be collaborative. It means doing things that are for the ‘greater good’, following a clearly defined and supported plan as well as embracing perceived ‘user’ problems rather than dissmissing such ‘users’ as uneducated, lazy etc, 'cos as potential users we are exactly that. I totally agree that this project will burn out because this project will be rapidly passed by as another development becomes the latest thing to have, unless development tackles the ‘real’ hurdles to adoption by idiots.
I just downloaded OpenHAB again to find out where it has got to and I was surprised to find ‘a configuration front end’ under development. AND they want and encourage feedback!
OpenHAB2 just came out… will install it later and test it out… I think that without a GUI for configuration HA will never be the bigger platform… just because the masses will demand it 
2 Likes
@rjstott What would you like to do in your graphical front end? Set up devices? Groups? Or create full fledged automation rules?
I don’t think it’s possible to even start considering a GUI without some realistic use cases that the GUI should solve.
2 Likes
At last a reasonable response. Having just restarted my OpenHAB exploration exercise I was delighted to find that what I have been asking for here is seriously underway in OpenHAB. Suffice to say that I would only ask for what OpenHAB is already doing. In brief this is nothing more than allowing the basics to be created without resort to YAML or any other text file YET still allowing such files to be used by those in transition or where the GUI interface is yet to be built.
AND accepting that a GUI mechanism to setting up is the only way to embrace USERS I am sure that as I explore OpenHAB I will find mechanisms for doing Groups, Frames, Automation etc. One of the clever things I see in OpenHAB is the automatic collection of Devices and then processing what is discovered into actionable Items. For example, OpenHAB found my two Logitech Hubs and discovered the devices connected an controlled by them. It also automatically related those things together.
Considering automation, as a simple User, I don’t want a lot, turn on some lights at Dusk, present groups of lights in rooms and allow their on state to be set by a predefined scene. Remotely operate those things that can be remotely operated without a load of fuss. Present the current known state and a history of state changes. At the end of the day I would probably love a local implementation of IFTTT or similar, is that fully fledged?
Hope that helps, lots to learn about the new OpenHAB, sorry!
1 Like
I completely understand that if the devs don’t feel the need for a UI, they will not start developing it. Nevertheless, I think that if someone starts it, more people would start working on it.
In my opinion, the GUI should allow to setup devices, automations, scripts, customisation, etc. Basically everything should be available for setup trough a GUI (some more advanced stuff could be excluded ofc.). For things that could not be easily done in a GUI, there should be a way to edit the yaml as text, but trough the interface. For example, I could select an automation, press the “Edit as text” button, and an text field for that automation would open instead of the normal GUI editor.
I also think that the text mode editing (with suggestions/auto completion) would be a good starting point for development, before the actual GUI configurator.
I’ve recently talked with a some work colleagues that told me they won’t use HA because it is too cumbersome to setup, and now that OpenHab has a setup GUI, they will look that way. I must mention that they are developers, so it’s not for a lack of tech knowledge.