WTH Do I still need to be a rocket scientist to get things done in HA

That is good to hear. I hope they expand on the ways they engage with users beyond the annual survey. It sounds like this entire WTH should be brought to their attention.

… they are running the wth, unless you’re speaking about this specific wth. That’s where the votes come in play.

1 Like

Interesting. I never thought about it, but the complaints about how Home Assistant works from new users could mean that what long-time users consider optional (that may not be the right way to put it) are actually things that are considered essential parts of the user experience because that how other systems do it.

2 Likes

If the automations/logic are created in the UI, it doesn’t matter what the storage format is. I’d almost suggest JSON or YAML because from a machine perspective it is perfectly reasonable to store configuration.

From a user perspective, YAML is an insane way to create programs leading to much confusion.

YAML is a perfectly good way to define a configuration (ie. configuration.yaml). That’s what is designed to do.

It is a terrible way to create a program (automations.yaml) because it was never designed to be used that way. It is completely counterintuitive for the purpose.

1 Like

I would probably say “low priority” rather than optional. But yes, there is frustration because things new users consider “basic” and “essential” are not available in the graphical interface and do not seem to be on any roadmap to add.

On the other hand there are a lot of advanced things in Home Assistant that other systems cannot do easily if at all, but are of no interest to new users. For example: Home Assistant Geeks seem to be obsessed with charting things and there are tons of tools for doing some very advanced charting. I can almost picture an advanced Home Assistant user proudly showing visiting friends the detailed chart they made of temperature fluctuations within their refrigerator… only to wonder later why those friends don’t drop around much anymore.

1 Like

I’m curious what you’re talking about that’s not on the roadmap?

Most of your comments have been about automations, which is currently on the roadmap, and there will likely be sweeping changes this year. (Additional ways to automate on top of the current method)

2 Likes

Most of the things I have in mind are ones that I have already mentioned either here or in other WTHs but it would not be a bad idea if there was a place (and maybe there is?) where a list is kept of “things people want to see moved into or added to the graphical interface” (as opposed to features they just want added to Home Assistant generally).

I already mentioned the ability to insert entity states or values in TTS message fields without dropping out of the Visual Editor into YAML.

Another one used often on other platforms is a simple time accumulation helper with output formatted for easy use in TTS or other notifications. This is just a timer that counts up from zero and makes its current value available in 00:00:00 (rather than total seconds or whatever is used for charting things) and is started, paused, or reset from within automations.This one has been requested going back to the last WTH but it immediately gets shut down because it gets confused with things like History Stats, (which is linked to a specific entity instead of controlled in automations, requires a defined time period instead of just accumulating time, and dumps its output as a single integer of total seconds OR minutes OR hours but not in a good 00:00:00 format for use in notifications).

I guess you are right that all my comments are about automations because that is kind of what an automation platform is, so what else would they be about? I’m suggesting where I see challenges that new users who come to the platform are facing to get their devices to do basic things using the graphical interface before moving on to more advanced areas where they should expect some knowledge of YAML will be required.

Sure, YAML/JSON is the storage method, and it is ideally created through a UI which a user can use much more easily. I think that is the end goal for most purposes, but it is nice to have YAML to be able to do things not yet supported in the UI or which are easier in YAML, like mass renaming.

It is unintuitive if you view automations as a purely open system that can contain any possible programming logic, but if you are just composing different available predefined actions and conditions it is probably the best solution. It can be created via a UI (or even LLM agents) and you can much more easily test that everything works as expected.

Again, it’s not perfect, but from my experience it’s the best solution for these kind of use cases. I’d love to hear about alternatives as I have to create and maintain similar systems professionally and there are definitely pain points with YAML.

1 Like

the pain points with yaml are WAY overblown.

you only need to remember three concepts in yaml

  • indentation levels
  • key:value pairs
  • dictionaries and lists

everything that is at the same indentation level belongs to the same key:value dictionary, list or list of dictionaries.

there is no way that can be harder than learning a full blown programing language.

I find it way easier than using the UI because of all the point-click-drop-down-click-type-repeat tedium involved in the UI.

It’s OK for configuring one-off integrations/devices but further than that it’s mind numbing.

and I dare anyone to try to share how to set up even a mildly complex automation via the UI.

There’s a reason why literally every single time anyone asks for help troubleshooting an automation (even if they’ve created it via the UI because that’s not fool-proof either) that they always get told to post it in properly formatted yaml.

NO ONE wants to try to look at a screen shot of an automation created in the UI. Let alone trying to correct an automation that was created via the UI. yaml is hands down easier to read and skim thru to find errors in logic than even a fairly basic screenshot of a UI created automation.

Even if it’s an easy fix then it takes more words to describe what is needed in the UI than to fix it easily in yaml or you need to open your own UI editor in HA, create the automation (clickety-clickety) then edit to fix the error (clickety-clickety) then paste another screenshot of the fixed automation back and hope the original user can figure out how to re-create it in their system (clickety-clickety).

or you can easily and quickly copy/paste/edit/post the yaml.

But again the point that everyone seems to be missing in all of this is that…

…we have options…

if you like the UI then there it is
if you like python then use pyscript
if you like JSON you’re in luck so just use it.
if you like that which shall not be named then use that
if you find the clickety clickety click of the UI tedious like me or you’ve outgrown the UI and reached it’s limitations then use yaml/jinja (EFP)

it’s good to have options.

8 Likes

I fully agree with your point of view that rephrases my own post a little above

Yaml is not admittedly not a programming language as such. It is for storing configuration settings.

I tend to think of it this way:

  1. Don’t be afraid of indentation. You downloaded a python program (home assistant). Python is indentation based. Don’t be surprised if yaml is there too.

  2. Yaml and json are interchangeable, except json hates comments, so the comments are destroyed when you shift between the ui and pain text. Don’t be surprised to find json all over the place, like in .storage

  3. HA has a programming interface.

  4. The settings for that programming interface are stored in yaml. (Could equally be json, use an online converter if the reality of json cf yaml offend you, or vice versa.)

  5. Jinja is also closely aligned with python. Again, you are working with python, don’t be surprised if Jinja rears its head.

  6. If you think the programming interface of HA is inadequate, or you can’t be bothered learning the paradigm, use python, or node red, or whatever.

  7. Get over it (whatever “it” is pissing you off) or do better.

3 Likes

I don’t think the disagreement is so much if people should learn YAML but rather at what point it should be required to do so.

Folks keep saying you can use the UI if you want to but the whole point is that there are too many things that force you out of the UI and into YAML. The request is just to fill in the UI gaps a little more.

I don’t really follow the argument that it is easier to read or find logic errors in YAML vs an automation listing presented in the UI. I have been using point and click UI logic systems going all the way back to my JDS Stargate from the 1980s and it is much easier for me to follow a listing of nested IF-Then-Else logic than to parse through a page of syntax laden special characters in a markup language. If this is truly a challenge in the Home Assistant UI then maybe the UI formatting just needs a refresh?

I don’t think it is helpful to characterize people who are struggling and looking for more functionality to be moved into the UI as somehow lazy or “pissed off”. WTH month is an opportunity to talk about what folks would like to see. Even if you don’t agree with their point of view there is no point in criticizing them for asking.

2 Likes

It’s much easier for me to read yaml, which is why I’ll always want it.

The UI itself needs work. There needs to be a universal method that allows users to change any field that accepts templates to swap to a template.

All the options available in yaml should also be available in the UI. I constantly see decisions being made to exclude functionality from the UI under the guise of “it will make the UI complicated”, when we really just need to make it easy to use instead of another dropdown. Many of these one-off oddball parameters could easily be hidden in expandable menues or inside 3 dot menus.

4 Likes

I think it’s more a matter of long-time users of Home Assistant considering certain features to be advanced ones, whereas new users are coming from systems where those were considered standard ones. Once you find a way to convince them of this, you’re likely to get them to support making the changes needed to implement the improvements you want.

1 Like

So you have to be a hard core atmel assembly programmer, and file your tax return in hexadecimal, is that what you say?

sort of agree with the topic starter. I have both homey and ha linked with mqtt and webhooks, orchestrated by azure functions. Comparing these 3 i found thst ha really has a very steep learning curve. Man, to understand and implement mqtt auto device discovery or get a webhook using post method towork. Also via ui creating an automation , but still have to code the yaml.

Things i can do in homey in 10 seconds cost me hours of trying in ha, but in the end it works beautifully.

I really like the performance of ha.

Best of both worlds, homey + ha

2 Likes

At the end of the day you can accomplish anything you want by manipulating registers in assembly language. Maybe even providing a YAML interface is too much hand holding… It’s all a matter of perspective on where to draw the line!

I think your point about combining Home Assistant with other platforms is probably the approach many folks end up settling on. I don’t use Homey but I do have a plugin in Homeseer that lets me pull entities from Home Assistant into that platform. Like you, I find that I can do stuff in 5 minutes in Homeseer that would take hours to work out in Home Assistant so I just use that platform to get it done and get on with my life. That said, I don’t think running multiple automation platforms is for everybody so it still makes sense to request that some of the UI gaps get addressed to make Home Assistant more accessible to a wider audience.

2 Likes

This. Every ha beginner should understand the basic concepts like device vs entity vs helpers vs automation vs scripts, addon vs integration. The yaml file structure.
I am still struggling when to reload script, quick restart, full reboot, when to use. Its a bit cumbersome to reboot the system with each minor (in my view that is) change.

2 Likes

New-ish (but not really) user of HA and Esphome. I have looked at both of them over the years, but mostly settled on Tasmota, Node-RED, InfluxDB, and Grafana almost a decade ago. I keep looking at HA and Esphome to see what advantage I can get from it.

Last year I decided to use HA because I got a Zigbee Thermostat for my heated floor and I wanted to have some automation for it (turn down the temperature when it was unlikely to be occupied). Setting it up was harder than I would have liked and required learning a fair number of concepts, i.e. understanding what is the way to do this in HA. It worked okay, but I find the data on the thermostat incredibly hard to understand with the default visualizations. I have an item on my personal backlog to figure out how to get the data so I can see it in Grafana the way I want it. I am pretty sure that will be possible. I am also pretty sure it will take me several hours to figure it out fully, so has not been high on my priority list.

I started using esphome in earnest this month. I tried it earlier this year for my gas meter, really just a pulse counter. It was pretty easy to get something going, but I know that I really didn’t understand what I was doing. That was both good and bad. Good in that I could get something going without too much work. Bad in that I really didn’t understand what I had done, so fixing things was going to be hard. After several months I noticed that the counter would reset sometimes, which meant long term data would be harder. I know HA has something to deal with that, but don’t recall if I set it up that way or not (remember I didn’t really understand what I was doing).

Since I have WAY more experience with Tasmota, I checked in on it again and noticed that they had made improvements to the counter and supported changing the debounce timing. I converted the node to Tasmota and it has been rock solid for a month or more (longer than the longest time esphome was stable). Tasmota also (by default) remembers the value so doesn’t typically reset the counter. I am pretty sure there is a way to do that in esphome (but I didn’t know that then and it wasn’t obvious that I could from the documentation or the examples I found).

This month I decided to get serious about a monitoring system for my automatic standby generator, since it did automatically start at the last outage. I had an m5 atom matrix that has an MPU in it. I thought that might make a good vibration sensor, but did not find any examples of anyone using it for that. So I bought a Zigbee one. Based on the data it presents, I could tell that it is using an MPU in it, so challenge accepted. I started with Tasmota. It has Berry and the example they provide is for the MPU6886. In a few hours I had it working. But, the thing that would be harder is providing the config for it.

I remembered esphome and I said, “how hard could this be?”. Turns out to be a lot harder than I imagined. There is a built-in component for the mpu6886. Getting it configured was fairly easy. The thing I found not well described was how to handle config in an extensible way. The Easy Button™ that esphome starts with leads you down a path that includes secrets and everything in one file. This works for the “hello world” example. What I found missing were the instructions/guides/best practices to move beyond “hello world” to something better. This, of course, requires a lot of thinking, mainly along the lines of “what do you want to make easy?”. I did see some examples of using a secret file (but the pathing on Windows does not seem to work well, only works if it is in the same folder, doesn’t handle relative paths). I also discovered substitutions in some examples, but the documentation on substitutions is fairly incomprehensible to me even now: Substitutions — ESPHome

As I played more with the mpu6886 component I realized that it was just wrong on the values for acceleration. Since I know how to read a datasheet and had done an implementation for it in Tasmota, I was pretty sure it wasn’t configured correctly. Tasmota uses the default 8g range, but the esphome component attempts to set the range to 2g (no option to change it). Sure enough the values were off by a factor of 4.

So, now it is time to learn how to do an external component. There is fair amount about custom component, but not so much about external ones. I did figure out how to do by spending several hours on it (not really unexpected, just harder than I would have liked). Then I had to figure out how to do what I wanted, which was harded since I didn’t understand the mental model one needs to understand to develop a custom component. The docs were not at all helpful for that, since they basically say that is outside of what we can explain.

How validation works is out of scope for this guide; the easiest way to learn is to look at how similar components validate user input.

Okay, fair enough (you have to be at least this tall to ride this ride). One thing that would help is a table of common things and the implementation(s) that do them well. As an example, I needed to do this:

  • add a sensor to an existing component
  • add a way to adjust a threshold for the component

The difference between a sensor and a binary sensor was not clear to me, okay doesn’t have to be binary, regular will work. Okay vibration is a good choice. esphome doesn’t like that, turns out vibration is only supported for binary sensors (not documented, but Use the Source Luke and you will learn all).

To be clear, I actually like esphome. I think it does an excellent job of making the development process fairly easy and I LOVE the way it does OTA and logging remotely. This is THE reason I moved from Tasmota for this set of projects. But, the learning curve is very steep. Part of that is because this is a complex code base and what I am asking it do is not simple. What I see from a lot of the documentation is the WHY and enough examples to understand how I can make use of this. It took me a long time to figure out a good pattern to use to provide a runtime configurable threshold. I did a lot of searching on the internet to find examples. This seems like a common intermediate level task. In fact this seems like a fairly basic requirement to me, figuring out the good way to do that should not be that hard, should it?

1 Like

I came to HA from a platform called HCA. HCA was a one person shop as near as I could tell. She shut down support so I came to HA. One thing I miss from HCA is the visual programmer. It was a really good way to visually build home automation scripts. So, I can see the need for a more visual way to build more extensive automations.

If I had the time, I would build a visual programmer. It would do most of the things that people want to do. But I would not try to address everything. My visual programmer would generate and run Python code. The user could ignore this code. But if they wanted to do something more complicated they could use it as a starting point.

In summary, my approach is to have a consistent layered solution. The bottom layer is HA and it is written in Python. The next layer is Python being used to automate or orchestrate HA. The top layer is a visual programmer that generates Python based automations.

As I see it everyone thinks what they used to have was much better and want to have this in HA too.
But whatever you used to have was not easy from start, you had to learn it, so in reality the issue is that people don’t try to learn. They give up and say it’s hard before even attempting.

Yes yaml and jinja wasn’t easy for me either when I started but the more you use it the easier it gets as with everything else.
I doubt anyone found yaml/jinja easy from the start but most people has learned it just like any other second or third language.
Using any connect the dots automation gui also has a learning curve.

And since you can make about 90% of the automations without yaml/jinja in the gui

4 Likes