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

[djaychela]

@Hellis81

It still has 5800 views. That is significantly more than 26.
And why would there be hundreds of thousand of installations updating every month if it was so hard?
Do you see the illogical with what you are saying?

Not really. My point still stands - the people who are here and voting are those who are the survivors for the most part.

@Hellis81

But there are sample codes on each endpoint.
REST API | Home Assistant Developer Docs

You’re confusing the REST API with the API of HA’s YAML. I’m talking about the acceptable YAML code - for instance, what tap_action: takes as a variable is shown in the page here [1] but there’s no detail as to what’s actually acceptable for any of the options it takes, such as perform-action or a link to it. So then you have to find out either by trial and error, or by a lot of searching of forum posts. Which is much higher-friction than it should be, IMO.

And with a YAML API which seems to have had breaking changes over the years it means you often end up with code that worked in 2021 but doesn’t any more. I’ve had that happen more often than it didn’t (last time was yesterday afternoon, in fact).

@Hellis81

Combine the API with yaml? Why? If you use the API then that is for use outside HA? Or are you using the API inside HA? Why?
It just don’t make sense.

I think you’ve got the wrong end of the stick here. I’m not talking about the REST API, I’m talking about the YAML API. Which would be helpful if it was fully documented, as I’ve already mentioned. Then a lot of the questions that I see here would go away as at least you’d know what you can expect to feed into any given key/mapping/etc. At the moment that’s difficult to find. The main django docs aren’t something I like, but the API Reference [2] is very useful. HA should have this, as it would be an explicit indication of what is acceptable for each entry.

@Hellis81

All error codes in programming is to some extent cryptic.

That’s not been my experience. Python generally gives a sensible traceback - line number where the exception occurred, often with underlining of the part the parser thinks is incorrect, and last time I did any C it was also the case. The feedback given by the raw config editor in HA is often totally unhelpful - one yesterday just made reference to r and that was it.

@Hellis81

Several years ago, then I could see that as a thing, but now there is so little you need to do in the text editor that there is no need at all.

That’s not been my experience of any of the things that I want to get done. Beyond the basics (which have been nice from the visual editor) I’ve had to use YAML to get things done - there have been lots of things that need installation from HACS and then the visual editor isn’t supported so you need to use YAML. Hence the sharp corners.

@Hellis81

But I have enough experience that I know that yaml is just json, and if I know json then I also know yaml.

I think that’s missing the point. Yes, YAML is a ‘shorthand’ version of JSON, and as a result can be easier to type. But that’s not the main issue here - if you need to create or edit it then it can be a frustrating experience (and the lack of delimiting makes it more difficult to parse mentally IMO), and there’s a vast difference between ‘knowing YAML’ and being able to create YAML which HA will parse, interpret and action appropriately. It’s the difference being able to write using a pen words that might look French and being able to write French that makes sense. They aren’t the same thing.

[1] - Actions - Home Assistant
[2] - API Reference | Django documentation | Django

[Hellis81]

@djaychela

Not really. My point still stands - the people who are here and voting are those who are the survivors for the most part.

And so would the 471 000 installations be.
Or the 255 000 that updated to the latest version last week.
Installations | Home Assistant Analytics
Are you saying they are not surviving?

[petro]

@djaychela

`` takes as a variable is shown in the page here [1] but there’s no detail as to what’s actually acceptable for any of the options it takes, such as perform-action or a link to it.

Those are covered all over the documentation. It’s an action, there’s thousands of actions and configurations for that situation and it depends on the action you’re performing. If you go to the action itself in the documentation, you’ll get a list of all the options it takes.

e.g. light.turn_on

Light

or remote.send_command for the sky remote control integration.

Sky Remote Control

At best, we would be able to link to the actions page of a script, but there’s no way to link to a list of available actions because they do not reside in a single place. And if they were to reside in a single place, the list would scroll for days.

---

I also see that you’re arguing heavily against yaml, I’d like to remind you that the goal is to be able to use HA without needing to touch yaml (unless you want to). So you’re really just arguing a moot point. The transition away from YAML configuration has been an ongoing process that we are almost in the middle of. Roughly a 5 year transition so far. Also understand that YAML will not go away, it will always be optional.

[Hellis81]

And HACS installed software can’t be argued you need yaml for.
That is not part of HA to begin with

[djaychela]

@Hellis81

Are you saying they are not surviving?

No. I’m saying that there are a lot of people who are turned away from doing more with HA than they otherwise would do for the reasons I’ve outlined above.

@petro

It’s an action, there’s thousands of actions and configurations for that situation and it depends on the action you’re performing. If you go to the action itself in the documentation, you’ll get a list of all the options it takes.

Not explicitly you don’t. Take a look at tap_action: for instance. Yes, you get some text saying a list of strings that it may take - more-info, toggle, perform-action, navigate, url, assist, none as quoted here. But they don’t link anywhere, so that makes them semi-useless, IMO. You have zero idea whether there are more parameters needed (and in most cases there are), and the arguments they take vary for each one. It should be a simple case of clicking on perform-action for instance to find out what extra is needed for perform action to work.

For instance (reason I’ve picked this) is because call-service doesn’t appear to be documented here as a valid action for tap_action but it does work. And it needs both service: scene.turn_on to turn a service on, plus extra data provided in a specific way.

      service_data:
        entity_id: scene.your_scene_here

to work. That is of course correct and how a language API works. But it should be documented, surely - otherwise you have to find forum posts that show the current way to use the API to get it working, or read the code which isn’t something that is straightforward. It may well be documented somewhere, but I’ve not found it anywhere - all the search results come up with forum posts rather than anything concrete.

Yes, there may be many actions that are possible, but they’re all in the code so therefore I think they should all be documented somewhere. Even if it is a massive page that scrolls for days. Easily searchable, and easy to find the exact thing you need without stabbing in the dark for hours because you were using slightly the wrong incantation to send the data to the action target!

I think it’s extremely unlikely that you’ll be able to get rid of the need for YAML configuration completely without removing the flexibility that’s needed - that sounds like going from Python to Scratch - I can’t see how it’s possible to put everything in a GUI without removing the flexibility that a language offers. Plus I take it that there will always be YAML in the back end anyway?

[petro]

@djaychela

Not explicitly you don’t. Take a look at tap_action: for instance. Yes, you get some text saying a list of strings that it may take - more-info, toggle, perform-action, navigate, url, assist, none as quoted here. But they don’t link anywhere, so that makes them semi-useless, IMO. You have zero idea whether there are more parameters needed (and in most cases there are), and the arguments they take vary for each one. It should be a simple case of clicking on perform-action for instance to find out what extra is needed for perform action to work.

Those are the available values for that option. Continue reading the remaining parameters, they will spell out what action they are attached to.

It’s all covered, you just have to read it.

@djaychela

For instance (reason I’ve picked this) is because call-service doesn’t appear to be documented here as a valid action for tap_action but it does work.

Because it’s deprecated. call-service was renamed perform-action about a year ago, you should not be using it. It’s still in the software for backwards compatibility.

@djaychela

Yes, there may be many actions that are possible, but they’re all in the code so therefore I think they should all be documented somewhere.

Maybe you missed where I already explained:

@petro

Those are covered all over the documentation. It’s an action, there’s thousands of actions and configurations for that situation and it depends on the action you’re performing. If you go to the action itself in the documentation, you’ll get a list of all the options it takes.

Every single action that exists in core home assistant has documentation. There is no single list in the documentation. So the blurb for perform-action has nothing to link to.

[Hellis81]

@djaychela

Yes, there may be many actions that are possible, but they’re all in the code so therefore I think they should all be documented somewhere.

They are documented in each integration.
So if your tap action is a climate action then look in the climate integration documentation.

[djaychela]

@petro

It’s all covered, you just have to read it.

Already have done, I don’t think it’s already covered - one because I don’t think the way the info that is there is sensibly linked/ordered, but more importantly, it’s not complete…

@petro

Because it’s deprecated. call-service was renamed perform-action about a year ago, you should not be using it. It’s still in the software for backwards compatibility.

Thanks for the heads up on that - not sure where I would find deprecations though (but that’s another aside).

OK, so let’s take perform-action as an example. (Which I’ve now changed in my dashboard, again, thanks for the head up on that). perform-action on that page is not explained any further. If you search for perform-action then the page you get up is… for picture elements! [1]. So you’re still none the wiser as to what’s needed to get that to work?

My previous code using call-service was this:

tap_action:
      action: perform-action
      service: scene.turn_on
      service_data:
        entity_id: scene.kitchen_lighting_100

So, going from the docs it appears as if the new format is this?

tap_action:
  action: perform-action
  target: scene.turn_on
  data: scene.kitchen_lighting_100

But that doesn’t work… but this does:

tap_action:
  action: perform-action
  service: scene.turn_on
  service_data:
    entity_id: scene.kitchen_lighting_100

I know that there is an answer… and a right answer. Which I’m probably not using as I was using a deprecation and no doubt the other elements of this are also deprecated. But I’ve done it knowing that there is a right answer and therefore spending ages trying to find it across threads on here and reddit. But lots of people will just give up. I can see that the API for perform-action depends on what you’re trying to call - it works differently for activating a scene than calling a script. And where do you find that out?

Of course if there’s a simple, easy GUI way to do this without delving into all this then that would be mega and suit 90% of people better. But AFAICT there isn’t at the moment, so a full documentation of the YAML API (which after all HA has because it can often tell you that something is wrong!) is needed.

TBH I’m mid chemo cycle and have better things to be doing than arguing on the internet.

[1] - Picture elements card - Home Assistant

[petro]

Not sure where you’re getting any of that from the documentation.

The docs mention:

which gets you:

action: perform-action
perform_action: scene.turn_on  #Blue underline
target:
  entity_id: scene.kitchen_lighting_100  #Red underline

Your code shows that you aren’t using the documentation, but examples from the forums which may be outdated.

If you need to use data, it would look like

action: perform-action
perform_action: light.turn_on
target:
  entity_id: light.kitchen_light
data:
  brightness: 100

As for how target can be formatted with entity_ids, devices, areas, and labels, it’s the same everywhere and covered here. Yes, the docs could probably use a link to that page.

@djaychela

I can see that the API for perform-action depends on what you’re trying to call - it works differently for activating a scene than calling a script. And where do you find that out?

You search for it.

[Hellis81]

@djaychela

not sure where I would find deprecations though (but that’s another aside

From the release notes.
But you probably started with HA after this change happened.
But that also explains that you aren’t using the documentation for reference.
You should.

[Didgeridrew]

The schema for dashboard actions can be found in Dashboards - Actions.

[Fanful]

@petro

the goal is to be able to use HA without needing to touch yaml (unless you want to). So you’re really just arguing a moot point. The transition away from YAML configuration has been an ongoing process that we are almost in the middle of. Roughly a 5 year transition so far. Also understand that YAML will not go away, it will always be optional.

Are you saying the goal is to allow everything to be done in UI? Because I thought this is not true, UI still aims to only provide main or common options while some advanced ones are intentionally kept yaml only. Am I wrong or misreading your point here?

[petro]

The goal of the frontend dashboard editor has always been to allow the choice between UI or YAML with all options available in both.

[Fanful]

Interesting, because there has been some things like this, where a PR included UI configuration, but it was requested to remove it and keep the option to yaml only:

piitaya

And I’m not writing this to argue, maybe this is just an odd exception, but I thought it was the goal in general

[petro]

Those are a special case, read the developers response.

[Fanful]

Alright. But then it does mean the target for UI does allow for some advanced configuration only being available through yaml.

The developer’s response there is just “done”, not sure what you meant.

[petro]

@Fanful

The developer’s response there is just “done”, not sure what you meant.

[Fanful]

Ah, I thought you meant the developer of the PR. I was referring to this specific comment you screenshotted from the start, I thought I linked to it.

[finity]

@santaklon

But I guess if one is well versed in coding, YAML can be a great tool too.

I never even heard of yaml before starting using HA. But back then it was the only option so if you wanted to use HA you had to figure it out. And since HA is still going strong there were apparently lots of people who were able to figure it out. And that’s why advanced users typically use it over the UI because that’s how they became “advanced” in the first place.

it really isn’t that hard.

@santaklon

in my eyes it does a really bad job at helping you fix stuff.

It’s not the editors job to tell you how to fix stuff. That’s job of the config checker. The editor is just supposed to guide you.

But that said that’s probably the biggest complaint I have with the system.

There are some things the config checker will tell you are wrong. And that’s typically an indentation issue. But there are some things it won’t tell you about until you go into the homeassistant.log file and there it is.

For example I’ve created automations that passed the config checker but they either don’t show up in the system or they show up as disabled or unavailable. Then you need to dig into the log to tell you what the problem is. And that could have easily been reported by the config checker.

IMHO, any log entry of at least the “error” type should pop up a repair notification. instead a lot of things just fail silently in the background until you happen to notice something isn’t working. The system knows there’s a problem (because it gets put into the log) so it should be possible to throw up a notification so the user knows there’s an issue without needing to stumble on it by accident.

But once you figure out where the problem is pointed out then it’s usually fairly straight-forward to fix.

[WallyR (Wally)]

It is the way the checks work.
It is like you need to get a room painted and you hire 3 painters to the job.
The config checker then checks the job and see that three painters are needed, so everything is okay.
The next morning (or restart if you want) only 2 painters have arrived for work. This will be written in the logs.
The config checker was right the right amount of painters were assigned.