2022.9: Home Assistant Birthday Release!

[FreakLikeMe]

            tap_action:
              action: call-service
              service: input_select.select_option
              service_data:
                option: Home
              target:
                entity_id: input_select.modes

[petro]

well that’s the problem, you’re mixing up syntax. Target isn’t valid in the frontend (dashboards).

            tap_action:
              action: call-service
              service: input_select.select_option
              service_data:
                option: Home
                entity_id: input_select.modes

[FreakLikeMe]

is that a new thing? because it worked for me up until now

[petro]

Nope, it’s always been this way.

[FreakLikeMe]

weird. thanks anyway i really appreciate it.

[anon78847916]

Because the browser didn’t change, the version is the same as before the HA update. This only started after the update. I regressed to August the it doesn’t happen. Reinstalled September update and problem came back. So obviously it’s HA not the browser.

[lepton]

Bluetooth intragration crashes after some time (<1h) · Issue #78036 · home-assistant/core · GitHub is broken for me too.

Please be more careful when programming.

[Ildar_Gabdullin]

Please tell me someone who knows it for certain.

Currently people move their integrations from yaml to UI.
Is is obligatory? No.
Is it possible to maintain settings in UI & yaml in parallel? Probably yes; harder but still possible; and probably there is a way to “yaml settings - change in yaml only, UI settings - change in UI only”.

Similar questions are asked here many times.
And a situation becomes worse.

[Ildar_Gabdullin]

Check here: Actions - Home Assistant

Used "data" instead of "service_data":

Outdated docs?
Earlier I used “data” in “tap_action” - and it worked.

Btw, here all 3 different "tap_action" seem to give same result (i.e. toggling an "input_boolean"):

type: entities
entities:
  - input_boolean.test_boolean

  - entity: sun.sun
    name: using data
    tap_action:
      action: call-service
      service: input_boolean.toggle
      data:
        entity_id: input_boolean.test_boolean

  - entity: sun.sun
    name: using service_data
    tap_action:
      action: call-service
      service: input_boolean.toggle
      service_data:
        entity_id: input_boolean.test_boolean

  - entity: sun.sun
    name: using target
    tap_action:
      action: call-service
      service: input_boolean.toggle
      target:
        entity_id: input_boolean.test_boolean

For instance, these both codes work for a template switch:

        turn_on:
          - service: input_boolean.turn_on
            entity_id: input_boolean.test_boolean
...
        turn_off:
          - service: input_boolean.turn_off
            target:
              entity_id: input_boolean.test_boolean

But for picture-elements card you are obliged to use "service_data" instead of “target”:

          - type: service-button
            title: Button
            style:
              top: 6%
              left: 20%
            service: homeassistant.update_entity
            service_data:
              entity_id: sun.sun

So, 100500 different variants of calling a service.
There should be ONE way to define data when calling services - and it must be used in docs for examples (all of us may propose corrections in docs, btw).

[Ildar_Gabdullin]

Btw, got plenty of “repair required” after update 2022.9.4 → 2022.9.5.
These calls were considered as “wrong service”:

                        - service: input_boolean.turn_off
                          target:
                            entity_id: input_boolean.xxxxxx
                          data: {}

Will see, may be will register an issue for this.

[arganto]

@Ildar_Gabdullin

So, 100500 different variants of calling a service.
There should be ONE way to define data when calling services - and it must be used in docs for examples (all of us may propose corrections in docs, btw).

Here background, esp. not everything is possible in each case. I agree, that it would be great to have always only one multi-optional way, but here I see the problems of breaking changes for 99,9% of the users as well in removing the “old” ways.

If statement in entity template automation

Here’s the history: first there was service: .... entity_id: ... no template ... But then someone wanted to template the entity_id. And remember at this point you could only template inside data and you had to change data to the name data_template… service: .... entity_id: ... no template ... service: .... data: entity_id: ... no template ... or service: .... data_template: entity_id: ... template ... Then the month of WTH happend and people were like "Why do I have to specify data_…

[petro]

@Ildar_Gabdullin

“wrong service”:

What? No. You completely miss-interpreted what I said.

@petro

Target isn’t valid in the frontend (dashboards).

Target isn’t valid in the frontend, i.e. under tap_action.

It’s valid in automation actions, template actions, blueprint actions, and script sequences.

So this is perfectly valid. Just not in the frontend.

@Ildar_Gabdullin

                        - service: input_boolean.turn_off
                          target:
                            entity_id: input_boolean.xxxxxx
                          data: {}

[petro]

@Ildar_Gabdullin

Outdated docs?
Earlier I used “data” in “tap_action” - and it worked.

service_data was just changed to data recently in tap_actions. Before it required the verbiage service_data. Now, service_data and data both work in tap_actions. The docs no longer cover service_data because there’s no reason to at this point. But your old tap_actions will still work if they have service_data and your new tap actions that just use data will also still work.

@Ildar_Gabdullin

For instance, these both codes work for a template switch:

Yes, see previous post.

[petro]

Yep, and that background doesn’t cover tap_actions at all. They have a different history, but similar. Maybe someday the yaml in tap_actions will match the yaml for calling a service in the backend.

[Ildar_Gabdullin]

@petro

What? No. You completely miss-interpreted what I said.

This post was not really addressed to you. It was basically about “why this code is considered as wring service”.

@petro

Target isn’t valid in the frontend, i.e. under tap_action.

It’s valid in automation actions, template actions, blueprint actions, and script sequences.

This difference makes a syntax confusing.

@petro

Maybe someday the yaml in tap_actions will match the yaml for calling a service in the backend

This would be good!

[Ildar_Gabdullin]

@petro

Target isn’t valid in the frontend, i.e. under tap_action.

Check this code - “target” seems to work:

type: entities
entities:
  - input_boolean.test_boolean
  - type: button
    name: tap to toggle boolean
    tap_action:
      action: call-service
      service: input_boolean.toggle
      target:
        entity_id: input_boolean.test_boolean
  - entity: sun.sun
    name: tap to toggle boolean
    tap_action:
      action: call-service
      service: input_boolean.toggle
      target:
        entity_id: input_boolean.test_boolean

[petro]

Interesting, that makes it mean that there is a bug. But based on the documents, it’s unclear what the expected behavior is. So we don’t know where to file the issue. I’d just put it under core and let the devs figure it out. Either tap_action → target should work everywhere and the documents should include target, or target should not work anywhere and the docs don’t need to be updated.

[Ildar_Gabdullin]

And in custom cards still the “target” is not used:

  - type: custom:multiple-entity-row
    entity: sun.sun
    name: tap to toggle boolean
    entities:
      - icon: mdi:restore
        tap_action:
          action: call-service
          service: input_boolean.toggle
          target:
            entity_id: input_boolean.test_boolean
    show_state: false

Shows an error:

@petro

I’d just put it under core and let the devs figure it out

Could you post an issue’s link here then?
Or I may try to create the issue myself, if you like.

[petro]

Well, that’s custom:multiple-entity-row not implementing tap action correctly. I’m pretty sure custom cards ‘replicate’ tap_action and don’t use core’s tap_action. That’s what custom:button-card does and many others.

[Ildar_Gabdullin]

@petro

custom:multiple-entity-row not implementing tap action correctly.

Right, bad example.
This card has own rules: GitHub - benct/lovelace-multiple-entity-row: Show multiple entity states and attributes on entity rows in Home Assistant's Lovelace UI