Required key not provided @data['type'] send.knx

Configuration Frontend
1

Want to activate a KNX scene from a HA button.
used the call service method but get an error “required key not provided @data[‘type’]”

This is the yaml from the button:

tap_action:
  action: call-service
  service: knx.send
  data:
    address: 0/6/2
    payload: '2'
    type: scene_number

Looked at several examples, but cannot see what I’m doing wrong?

2 
tap_action:
  action: call-service
  service: knx.send
  service_data: ### <------ This ###
    address: 0/6/2
    payload: '2'
    type: scene_number

data: for scripts and automations.

service_data: for Lovelace.

5 Likes
3

This is so annoying, pops at least once a week.

4

Thanks Tom,

I had that before and changed it to data:
Now it’s working, not sure what my previous error was.

And good to know that data is for scripts and automation.

1 Like
5

Twice in 15 hours: Frontend-to-Script Variable Syntax

I think I’ll suggest this be changed to data: everywhere if we get a WTH month again this year.

3 Likes
6

Once people update their instances they will benefit from the better error handling that I implemented in 2021.2.

Then this would be the error that is shown and will hopefully reduce the confusion at least a bit.

image

1 Like
7

Aporeciate your contribution, but this doesn’t help at all in my opinion.

It says “is not expected or supported by the visual editor”, which only tells me that it doesn’t show up in the visual editor, not that it is wrong code. There’s also lots of other stuff that is not supported by the visual editor, but works just fine.

8

Is there a reason Lovelace uses service_data:, as opposed to just data:?

9

I still think it is an improvement to what we had before (e.g. missing keys are now clearly marked, as is general card type support, more details in the PR). Never said it’s perfect, but took enough time to get to this stage. There might be sensible ways to distinguish further, but with the MVP approach, I did not want to over complicate things. But this is getting off-topic (admittingly started by myself :laughing:…).

10

I can only guess here: For scripts and automations it is clear that the data belongs to the service/action/… (so data is clear enough). But in the frontend scenario, the original developer probably wanted to make it clear that this data only relates to the service call and is not relevant e.g. for navigate or url actions hence service_data.

11

As I said, I appreciate your contribution :slight_smile:
I took a look at your PR and I think an incorrect key should also be a config error in red like the ones about “url_path” is missing etc… This would make it clear that it’s an error and not just “not supported by the UI editor”, because this is misleading. What do you think about this?

12

That might be tricky with custom cards, since they can require keys that HA does not know about. I think that is why the warning approach was originally taken for that.

For internal cards a more strict approach might work in theory, but currently the error handling logic does not know what kind of GUI element triggered the error. Also I think the GUI does not know which parameters are not expected and which are just not supported in the visual editor. This distinction does not exist currently as far as I am aware.

Lastly, the error might also be coming from an automation editor which also needs to be taken into account.

So all in all, not so straight forward as it might look…at least from where I am sitting right now :slight_smile: .

1 Like
13

To avoid breaking changes maybe make either work anywhere