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.
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.
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.
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
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!
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.
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
