Data: or service_data: - what are the rules?

Configuration
1

In lovelace, I use service_data:

  tap_action:
    action: call-service
    service: switch.toggle
    service_data: 
      entity_id: switch.office_center

But in automations, I use data:

  action:
    - service: switch.toggle
      data:
        entity_id: switch.office_center

Is that the generalized rule?

Is service_data: required or allowed anywhere else?

Is data: required or allowed anywhere else?

Thanks, RIchard

2

in lovelace tap_actions it’s service_data.

in normal services (I.e. action section, script sequence section, etc…), it’s data.

EDIT: I have a feeling that you’re over thinking this. When in doubt, consult the docs. There’s no rule. data/service_data are just the names of the field and the docs will tell you if the name of the field is valid or not.

3

Thanks for responding. I asked BECAUSE I consulted the docs.

Search Docs for “service_data” and you get an unhelpful Lovelace changelog page
Search Docs for “data” and you get irrelevant result overload
Search Docs for “switch.toggle” and you see references to “Service Data” but nothing about when or where to use service_data

Does anyone know any docs that cover this? I’d like to write a PR for clarification.

2 Likes
4

Google: “Home Assistant tap_action”, first result…

Google: “Home Assistant switch”, second result (below template switch)…

Doc for switch actually tells you not to use data at all

  action:
    - service: switch.toggle
      entity_id: switch.office_center

Which is best practice as there is no other data to be passed to the service.

As @petro said, follow the docs.

5

Let me fix that for you … what you’re really saying is follow the docs, but don’t rely on being able to search the docs with the search button on the docs.

6

No, I’m saying look for what you’re looking for in the docs.

You wanted to know what keys are accepted by the tap_action lovelace item, and what keys are accepted by the switch integration, but you searched for ‘data’ and ‘service_data’.

If I wanted to know how to replace the batteries in a drone , I would search for the model of the drone. If I searched for batteries I’d never find the right page.

7

Let me try it like this: do you know of any place in Home Assistant where service_data is used other than lovelace?

Your assumption is incorrect. Obviously, I know what keys are accepted. I wanted to know when and where service_data is used.

8

I already answered this. It’s only used in tap_action. Also there is 1000+ integrations, it’s possible that one of them use the same field name. Why do you want to know where it’s used anyways? It only has the name service_data for tap action to let you know it’s only valid with a call service tap action.

1 Like
9

Indeed, the keys are relevant to their parents. Doesn’t matter what integrations use what keys, it matters what keys work with the integration you’re using.

OP is trying to do things backwards and getting confused.

10

You seem to be confused by my original post. I’m not trying to “do” anything except to understand how and where service_data is used.

I had clearly already read the docs to know it is used in lovelace, but I wanted to know if is it also used anywhere else? Searching the docs was inconclusive, so I asked. Thanks, petro, for answering.

The rest of this thread reflects a rigidity of thinking that surprises me. Why would I want to know that? Why not? X requires Y. Great. Does anything else require Y? Who wouldn’t want to know? Perhaps if you already know the answer, it’s harder to understand why someone else would ask.

And please think twice before parroting 'follow the docs". I understand the need to encourage people to read the docs, but petro’s answer is not in the docs, except by exclusion.

11

very much looking forward to that. always good when experts try to improve the docs. would hope the difference between frontend en backend is clear on your side before you do that though.

12

The problem with a PR like that is it doesn’t clarify anything. If we add a blurb about a service_data field inside actions, it’s just going to confuse people because actions require the data field. The only acceptable place to write anything would be in the service_data field under tap_action, which IMO is already covered well.

If anything, this thread just shows you how bad the home-assistant.io search engine still is (even after the recent search engine changes).

1 Like
13

It’s not ‘rigidity of thinking’ it’s about doing things the correct way around. Making docs for every subkey would just make the docs a million times more complicated.

What makes more sense, and what the docs currently do, is that for each integration they list all the available options.

I presume that you don’t intend to only purchase iot gadgets for your home that use a certain key in their configuration? You’re going to buy a gadget that you need and then configure it with the keys that the integration uses.

What I was trying to convey to you is that trying to find ‘which integrations use which key’ is the wrong way round, it should be ‘which keys does this integration use’.

The answer is already in the documentation if you look for it the correct way round.

2 Likes
14

tbh, I was a bit sarcastic. shouldn’t have done that. sorry. It’s just that when people start accusing others so bluntly of ‘parroting’ and being ‘rigid’, while in fact they are most helpful, and most of all, simply right, it makes me itchy.

Found it somewhat amusing that a fellow community-member, while not being clear on the subject at hand, feels the urge of writing a PR.

Again, I shouldn’t have.
Have a great day y’all.

1 Like
15

I’m not saying a PR wouldn’t be helpful. I’m trying to clarify where the PR should go if we were to make changes. I do think that the tap_action examples section could be expanded and the example used directly in the service_data field isn’t the best option. light.turn_on for service and brightness: 255 for service_data would be a better fit because entity_id is not required to be inside the data. However it would be required for that specific service_data in order for it to work. :man_shrugging:

16

of course, that could be done. Improving the docs is always a good thing.

OP was confused by the frontend and backend though, and put forward examples that have no relation whatsoever. tap_action is never in the backend, so why compare apples and pears.

And that we don’t need (service_)data: in the backend when only an entity_id is used without further data has been clear since forever. If that isn’t in the doc’s, it should be added, since it cuts another extra line of yaml :wink:

17

It is in the docs, that’s what was ironic about it all. The docs for switch I linked to above don’t use the data key because their is no extra service data, they just use entity_id.

Also, the code in the docs is (supposed to be, and 99.9% of the time is) best practice, but it’s not the only way to do things. This is also explained in the docs right back in the ‘getting started’ sections.

Yaml anchors aren’t mentioned explicitly in the docs for example, as they’re not considered ‘best practice’ because they confuse new users, but in the getting started docs they explain that all configuration is yaml and valid yaml is accepted. In fact, you could rewrite your entire configuration on json if you want, it would still work, but documenting that just makes it more confusing for new users.

18

correct.
but, admittedly, this is not so unambiguous: Light - Home Assistant

as said, if no further data is used, one can suffice with the action service and entity_id. If specific settings are required, we need the data: field.

I think that adding 1 example here like:

  action:
    - service: light.turn_on
      entity_id: light.ledliststair

would improve the docs, with the above reasoning added to it.

now don’t get me started, Ive today cut many many lines and made my config so much easier to maintain using only a few new anchors (Frontend and backend)

19

Again though, just because something can be done doesn’t make it best practice.

You can use all sorts of weird and wonderful ways of quoting things in single line templates, but all the docs are written with double quotes on the outside and single quotes inside. Just makes it easier for new users to understand it without making the docs too complicated to understand.

With turning on a light, using data is the best practice because you can also pass brightness and colour. Although turning off should only be entity_id imho as there is no other data to pass other than the entity_id for that service.

Ignore the last bit, forgot about transition :see_no_evil:

20

petro nails it again. Thanks

I’m not confused about frontend and backend – yes tap_action is only used in the
frontend, what I was asking is if service_data is only used with tap_action.

And when someone says you have to look for things “the correct way round” that seems like the definition of rigid thinking.

I have written PRs for clarification that were accepted and published. I don’t know everything, but that means I sometimes see ways to make things more clear for others who don’t know everything.

That said, this issue is now burned into my brain and I’m not sure I see a way (or need) to clarify. Perhaps I am the only one who will ever wonder about the lowly service_data and its meager existence under the thumb of tap_action.

Thanks all.

1 Like