I just started using Home Assistant a couple of weeks ago. I have a lot of things in my home which could integrate with an automation system, but never had a single system which could tie them all together into a coherent whole. This changed when I learned that Greg Badros was working on a Vantage module for Home Assistant. So I decided to play with the system, to tie together:
A Vantage lighting system, controlling all the lights and fans in our house
A Vera controller, which I had generating alerts from our door locks
Several zwave outlets, used primarily as zwave repeaters
A few zwave door locks
Google Chromecasts and Google Home devices
Sense electrical monitor
Enphase solar monitoring
IP security cameras, attached to a Synology
Elk alarm system
In other words, I had a lot to set up and play with. So Iām not the typical beginner user. (I also have a PhD in computer science, so Iām okay with a bit of complexity, if required.)
Iāve learned that Home Assistant is awesome. It supports an incredible number of integrations, and can do everything I hoped and a lot of things I never even thought of. I was blown away at how easy it is to get a Hassio build running, how modest its resource requirements are, and how easy it is to get a basic UI with your devices ready to be clicked on just working.
As Iāve been playing with it, Iāve also learned that it clearly is a work in progress. There are lots of things which are not done yet. Lots of things to do. And so I figured it would be useful for me to keep notes on some of the things which were harder than they needed to be as I got up to speed, so I can prioritize what things I might want to work on improving. Iāve made this list partially because it is easy to forget friction points once youāve learned the quirks of a system. Iām sharing it so I can learn about what things are already being fixed, and possibly so we can make easy fixes to the things which are easy to fix.
Note that this is not a list of complaints (Iām quite happy!). It is also not a list of questions (Iāve figured all these things out!). It is just a list of things I had to work through that took more time than is ideal for a new user, a.k.a. friction points.
If you use the Vantage component, it will import every light and lightswitch in your home as a separate Entity. For a completely wired home, this is a lot of stuff. The automatically generated lovelace UI gets cluttered very quickly (it doesnāt help that this pre-alpha Vantage component also generated a couple of hundred badges). The most confusing part ā lights and switches appear to be populated into the UI in random order, making them hard to find. Sorting them alphabetically would make it much easier to use.
The Automation Editor asks you to specify a trigger. For a new user it takes some digging to figure out that your first automation should probably be triggered by a change in state (say, a button being pressed) instead of an event. Once you figure that out, . But the UI and documentation offers little guidance on what valid values a beginner might put in the āFromā and āToā fields (such as telling you lights can be āonā or āoffā), or how to find out what valid states are for any Entity. Valid states do not appear to be documented ā and so they have to be discovered through experimentation.
If you choose āCall serviceā in the Automation Editor, it asks for āService dataā. There is no indication of what format this field is, either in the UI or the linked documentation. It took guesswork and Google searches to eventually figure out it was JSON, and not YAML like the linked documentation says.
The Automation Editor lets you add multiple Triggers, and multiple Conditions. But the UI doesnāt say (or make obvious) how these will be combined, either with an OR or AND operator. The linked documentation mostly clarifies this ā but implies that you can change from AND to OR using the right constructs (which are apparently not yet available in the Automation Editor. Ok).
The More Info dialog seems to be easy to get to to learn more about any particular Entity. Cool. When I was trying to figure out where I got hundreds of unwanted badges and switches, it would have been really useful if this dialog told me what component generated any particular Entity.
The Elk M1 integration by default generates hundreds of unused (and unwanted) sensors, switches and lights (presumably because the Elk system doesnāt tell it what objects are in use or not). It would be cool if the example configs in the docs disabled all this by default. (Iāll submit a PR.)
I liked that the !secret primitive lets me put my passwords elsewhere. I was disappointed to learn it didnāt work in the Automations Editor.
When playing the āwhy didnāt my automation trigger?ā game, I really wished there was an easily accessible stream of all state changes and events from the previous 5 minutes I could review. (I now notice that the āLogbookā appears to be just this ā but whenever Iāve played with it in the past it has taken so long to load that I clicked elsewhere. I guess this is just a performance optimization problem thenā¦ and perhaps a sign that I have too many motion sensors overwhelming this with data.)
Iāve not yet figured out what āAreasā are used for. My Googling implies that it is experimental, and may not have applications yet. Perhaps mark it as such in the UI so it doesnāt confuse new users?
Adding zwave devices is weird ā you click a button to add a device, but get zero UI feedback about it working or not. Once I figured out how to open the logs I got the feedback I craved. Perhaps add a sentence or two to the UI saying users should do this?
If I create a script using the Script Editor, it gets a random name like āscript.1569684654547ā. Add a way in the Script Editor of renaming this to something human readable?
The distinction between āScriptsā and āAutomationsā seems subtle. Is there a strong reason to keep this distinction? If so, can the difference (and when you should use each) be clearly documented?
As a new user, having to learn YAML, JSON, and Jinja2 to build automations is a steep learning curve. Is there a technical reason for having 3 different programming language syntaxes in use simultaneously, or is this just a historical artifact? Can we document what sub-combination of these three a user should be using to ensure maximum forward compatibility with future versions?
I know you said you werenāt looking for answers, but I thought Iād respond to:
A script is a sequence of steps, each of which can be different things (service call, delay, wait, etc.) The steps of a script are executed when the script is invoked (via a service call.)
An automation is effectively a script with a set of triggers, and possibly conditions, that can automatically execute the steps in its action section based on events and states in the system. In fact, the action part of an automation is effectively a script - it uses the same syntax/semantics, and is executed by the same code that executes a script.
home-assistant.log is your friend, especially if you set:
logger:
default: info
logs:
homeassistant.core: debug
Of course to find things in there grep is also your friend!
Indeed, and that is what I find myself using. I was starting from the assumption that a new user would try to use the UI, and not the command line (especially since the command-line is harder to get to if you are new Hassio user).
Iāve been using HA for about 1 1/2 years. When I started it was clear using the UI to create entities, scripts, automations, etc. was not very common. Most users seemed to edit YAML files. Only recently have I seen the UI improve in these areas, and yes, they still have a long way to go. Remember, HA hasnāt reached version 1.0 yet, although I believe there is a strong push by the core team to get there before too long.
Honestly I kind of wonder if I would ever use the UI for those things once theyāre updated. Iām so used to doing everything in YAML. The ZHA control panel and Lovelace card editor are really the only UI elements that I use, and even then, I find myself using the manual mode on the card editor anyway.
Iāve used other systems that have both UI and text based āconfigurations.ā When theyāre implemented well, and handle the scenario of the user changing one or the other at run-time, I find myself using whichever is easier in the particular situation. Oftentimes UIās can do a lot of the grunt work, saving time. So they can be useful, even to advanced users. But it takes a lot to get them to that point. And when theyāre not the focus of the development teamā¦
Oh I agree, UIs are definitely useful. I just happen to be content with editing YAML and using those few UI elements.
Being able to reload the config without restarting is a more important goal right now than the UI in my mind, but Iām not a developer so I donāt know which is more complicated.
Yeah, as far as the UI goes ā a dead simple fix to this friction point would be to put a message on that part of the UI saying āhey, work in progress here! Hereās a link to the docs for how most people do this!ā
That way new users know they are about to be doing something the āhard wayā, instead of learning through experience.
You just found what to focus on for your first HA PR!
But seriously, for a change like this to happen in an open source project like this, there has to be someone willing to spend their time to implement that, vs doing something āfun.ā And that person also has to be willing to get the core team to accept that change, which can sometimes not be very easy to do, making it even less likely that someone will go through all the effort to do something āneededā instead of something āfun.ā
Lol I wish I could help with development, believe me. I feel like a mooch. Been trying to help others as a way to give back though.
I also figured reloading the config without restarting isnāt something that would happen for a while. For the average user a UI is probably more important.
Iāve been using home automation software for about 4-5 years now; tried almost all open source. HA is my last choice, been using it for 3-4 months now.
My humble thought is that these home automation projects should focus on the stability first. As i see in almost all projects, the developers are trying to address both expert users who excel in computers; and novice users who are not so expert on software development and computers. And the result generally is non stable outcome in both directions.
I started with openhab, openhab 1 was working with config files and text processing and was stable enough. Then openhab2 comes out, supposedly working both on config files and UI settings. The result was, i was configuring half of the devices on config files and the other half on UI; because they were not working all in one. So, it was unstable on both terms.
Then i changed to Domoticz; way much easier to set up; almost everything on UI; but it came out with general stability issues and had to restart the service almost every day.
Then i moved to home assistant, since i was more confident on python and its stability. I am very happy so far on the stability side. But the documentation and samples are really lacking and hard to follow up. I tried to wrote a custom component for my own use on a device and it was the most challenging thing i did on python so far. Since there was very few details on documentation, i tried to follow up the existing component codes; trying to reinvent wheel all from scratch.
Anyway, again my humble opinion; the currently existing yaml and templates and automation and everything should stay the same but their stability should be increased. Like i have been trying to use multiple entities on data_template in automations for the last 3 days! Nope, just a simple light.turn_on with multiple entities under template doesnāt work and this is written nowhereā¦ The more style changes made on the HA code, the more useless it becomes on the community forum older solutions; either every change should be very well documented (which of course requires additional manpower), or we should stick with what it isā¦
Yep, I suspect you donāt know (because I donāt think itās documented, but you can find it if you can read the code ) the entity_id parameter, for the most part, accepts a comma separated list of entity IDs. So a template can result in a string like: entity_id1, entity_id2, entity_id3.
The use of comma-separated lists (or sequences, rather) is documented in the YAML specs, but I suppose that doesnāt mean it will necessarily work in Home Assistant too. They require opening and closing brackets too, at least in the specs. I think this is related to what weāre talking about here.
Thatās different. The āschemaā for the entity_id option will take a single string and split it around commas to create a list. What youāre referring to is creating a list in YAML, of which there are two ways (that I know of.) E.g., in YAML:
x: [a, b, c]
or
x:
- a
- b
- c
But you canāt do this in a single template, because YAML parsing is done by the time the template is evaluated at run-time. So, it provides the option of providing a single string with entity IDs separated by commas:
x: "{{ ... }}"
Where the template results in a string like: entity_id1, entity_id2, entity_id3
Sorry guys, my sample subject was out of context here; but you were right. I tried everything but commas in between; and it works now with commas. It doesnāt work with lines, or - lines. Now that i have to find an āelseā condition since all the additional service lines after that automation error line doesnāt work if the condition returns out an error.
If the sun is above_horizon, the light.turn_on gives an error and cover.open_cover never works.
This sample was just to give you an idea why we need solid documentation; and i am very sorry to take your subject out of context. Thanks for the tipā¦
UPDATE: I switched to using service_template instead of data_template; so there is an āelseā in the condition and no more error.
