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.
Have you been following this thread? @danielperna84 and @jmart518 have been working on an awesome solution:
3 Likes
I haven’t seen that! Nice! I’m currently using Codiad which is a web text editor, so it is a similar solution.
Thought this might be helpful if someone decides to implement the yaml configuration gui (more than the simplistic config gui). This is a paper on developing a python gui interface to a yaml configuration file. https://sea.ucar.edu/event/development-python-gui-interface-yaml-configuration-file-propagation-largely-identical
Using this method, each plugin would define their own YAML format. The Yamale python library (A schema and validator for YAML) might be useful for this https://github.com/23andMe/Yamale
Luckily, we already have schema validation for configurations, similar to Yamale.
Just an FYI…looks like there is a related PR by @danielperna84 that recently got merged (should show on the website soon).
I believe my configurator is not what this thread revolves around. Thanks for the traffic though. 
I would be interested in some of the work on a more robust GUI for editing things. I think a middle ground strategy when projects find debate around maintenance costs of a new thing is to expose the system for extensibility but keep the thing outside of core.
What I mean by this is the above merged configurator PR can probably act as a basis for an API that allows remote configuration management, of which one consumer is the ace editor based one. Then more robust client app has to manage state locally and then send an appropriately serialized message to this API. This can be done entirely in the client. It’s not an issue of JSON to YAML but “objects” to YAML which is a normal use case of a (de)serialization library of which there are ones that can run in JavaScript.
The other nice things about rich single page webapps is they can be “deployed” as a simple static reference (very simple packaging mechanics) and web components are pretty awesome - I can see the configuration grammar lending well to this.
There was one comment about devs focusing on other stuff but I must say, some people are just interested in different things!
I have returned to HASS after a fairly lengthy absence and its great to see both my suggestions, the validator and the GUI restart for HASS, mentioned in my post above, have since been implemented in the HASS.io install that I have just started playing with on Friday! 
HASS keeps going from strength to strength! Thanks everyone! 
2 Likes
I never see anyone mentioning domoticz, but its very easy to use and configure. The interface is outdated