Hey
I’m new to node red so thought I’d start off with a simple flow to turn off my lights when I play a movie through kodi.
I have the event triggering fine however when it then attempts to call service light off, I get the error: "HomeAssistantError: extra keys not allowed @ data['data']"
I found this recent thread: NodeRed 17.0.4 what happened? - #4 by Biscuit
But I’ve checked the pallete manager and I cant see any yellow outlines or any options to update.
Am I missing something?
Cheers.
Without sight of exactly what you are sending to your Call service node, I am going to guess that your Data object field is not correctly formatted, or has a key value pair that should not be there.
The HA light.turn_off service call has an empty {} data object, so passing anything in this is likely to generate an error.
Additionally:
As you have quoted an earlier post of mine regarding an apparently similar error message, I would like to add for posterity (and anyone else reading this later) that the two messages are different. Your error says ‘data’ as the extra key not allowed, which kind of suggests you are sending the node ‘Data’ field with something in it.
The other message says ‘return_response’ as the extra key not allowed, and the OP there was having issues with the recently introduced service call return. In that case, the most recent version of WebSocket nodes was trying to get a return response, and the OP was using an older version of HA that was not providing this.
These error messages come from when the WebSocket nodes package the entire data object required for an API call back to HA, which is put into ‘data’. If the HA API call is not expecting something or something is missing, it will complain.
Some of the confusion I believe comes from the fact that the API data is the entire service call, target, etc including the ‘data’ sub-field object.
Apologise I misunderstood your original thread.
I’m trying to use the call service node to disable a light, using the default node that is generated changing just the sevice and entity, not populating anything in the data param.
[
{
"id": "825c10e2c49729c0",
"type": "api-call-service",
"z": "8f76f198a437dd80",
"name": "Light OFf",
"server": "7b57ba97aa04f53c",
"version": 5,
"debugenabled": false,
"domain": "light",
"service": "turn_off",
"areaId": [],
"deviceId": [],
"entityId": [
"light.hobby"
],
"data": "",
"dataType": "jsonata",
"mergeContext": "",
"mustacheAltTags": false,
"outputProperties": [],
"queue": "none",
"output_location": "",
"output_location_type": "none",
"x": 1320,
"y": 760,
"wires": [
[]
]
},
{
"id": "7b57ba97aa04f53c",
"type": "server",
"name": "Home Assistant",
"version": 5,
"addon": true,
"rejectUnauthorizedCerts": true,
"ha_boolean": "y|yes|true|on|home|open",
"connectionDelay": true,
"cacheJson": true,
"heartbeat": false,
"heartbeatInterval": "30",
"areaSelector": "friendlyName",
"deviceSelector": "friendlyName",
"entitySelector": "friendlyName",
"statusSeparator": ": ",
"statusYear": "hidden",
"statusMonth": "short",
"statusDay": "numeric",
"statusHourCycle": "default",
"statusTimeFormat": "h:m",
"enableGlobalContextStore": false
}
]
I’ve tried pssing in an empty json object but still errors.
EDIT: used correct display tag for json
Not a problem - this stuff is quite complicated, I just wanted to leave a history trail that makes sense for anyone reading this stuff in the future!
Code: it is very useful to post your Node-RED flow, but you have to use the </> option at the top otherwise the JSON gets mashed. All the [ ] have turned into and it is impossible to import !
Anyway, reading your code / picture, yes it all looks OK. Certainly a basic call service for light : turn_off should work as you have it configured.
So, the next thought is that the problem could be issues with your setup version. Worth checking - you have websocket nodes 0.62.3. I assume you are using Node-RED as the addon in HA - version? And which version of HA core? And, which version of the Node-RED Companion integration are you using in HA?
In spite of what I said above, yes this ‘extra keys not allowed’ does appear to pop up when there is something not up to date.
Ahhh it’s called pre formatted, I was looking for a tag called code haha, update the post to make it more readable.
Core
2024.1.6
Supervisor
2023.12.1
Operating System
11.4
Frontend
20240104.0
Yeah using Node-red as an addon.
Web sockets version: 0.62.3
Companion version 3.1.3
Your code works for me, although I don’t have a “light.hobby” entity I can use another “light.” sensor switch and all is fine.
Version: 0.62.3
Home Assistant version: 2024.1.6
Companion version: 3.1.3
Node-RED version: 3.1.3
Docker: no
Add-on: no
There have been a couple of posting along this line, generally associated with version issues. Everything has to match up at the moment. The only one you have not reported is your Node-RED version - check the addon which should be 17.0.3 or 4. Node-RED itself should be 3.1.3 for the latest (see the addon logs when NR starts for the installed version).
Otherwise, I am down to wondering about your sensor light.hobby, and if that is not actually a light, or there are issues with the integration that created it.
At this point, all I can suggest is going back to HA > Developer Tools > services and trying the light-off service and entity combination there.
Somewhere in the service call you have a parameter/object called data, but the service call already write that “data” for your, so you need to cut that level out.
If you do not set it in the service call node, then you might bring it in with the msg.
Node red addon is 17.0.4, Node-RED version: v3.1.3.
Oh nice I did not know about the services tool in the Develeoper tools, that’s going to make life a lot easier.
I can call it find with this payload:
service: light.turn_off
target:
entity_id:
- light.hobby
data: {}
Ok so I hooked it up to a button entity to test it easier (which is cool) and now it works fine 
So either I wired it up wrong when trying to drive it from the media player through a switch, or I needed to restart node 4 for some reason 
@WallyR cracked it. I had forgotten - even though your service call node has the data field empty, you are most likely passing the output from the media entity, and have something already in msg.payload as a data object.
The call-service node takes UI settings, but also reads in from the input message, and if msg.payload is an object it will attempt to merge in the data there with the UI settings. Something like msg.payload = {“thing”: value} is just enough to confuse the issue!
As a fix, you can add a Change node just ahead of your service call, and set msg.payload to something like “” string, or 0 number, just to clear it from being an object.
Got there in the end I think