Calling EvoHome services triggers error: HomeAssistantError: value should be a string for dictionary value @ data['entity_id']

[sgurgul]

Describe the bug

EvoHome is a HA's build-in integration. It exposes few services to control EvoHome devices.
Home Assitant NodeRed addon version 17.0.0 introduced node-red-contrib-home-assistant-websocket update to version 0.62.2.

These update causes EvoHome services impossible to be called.
Whichever service I try I receive following error:
"HomeAssistantError: value should be a string for dictionary value @ data['entity_id']"

Calling the same service directly from HA (using Developer Tools / Services) works properly.

To Reproduce

1. Create Call Service node
2. Configure any of EvoHome's services e.g. "evohome.set_zone_override"
3. Call the service

Expected behavior

Executing appropriate action on EvoHome device.

Screenshots

Example Flow

No response

Environment Information

Version:

Home Assistant version: 2024.1.2

Node-RED version: 3.1.3
Docker: no
Add-on: yes, 17.0.0

Additional context

The only workaround I found is to use websocket API node instead of "call service"

[sgurgul]

Observed issue seems to be similar to #1245
However I am not sure if root cause is the same

[zolakt]

I have the same problem when calling services from the multimatic integration. In a bunch of my flows, which used to work fine before the update, I get the same error.

I can't find the root cause. What is even more weird, I tried just calling it from an inject node, no variables or anything. I don't get the error in this case, but nothing happens. The services call doesn't do anything.

The only calls that do work are those without any data...

I mean seriously, is anyone testing these updates at all? After every single node-red companion/websockets update half of my working flows break...

@sgurgul Can you please share how you have done this with a websocket API node?

[zolakt]

Btw. this definitely isn't service specific. Here is the simplest example I could think of. You can't even add an entry to the logbook. From what I've managed to conclude all service calls which have some data, don't work. Only service calls without any data (e.g. light turn_on/turn_off) do work.

Also, is there any way to easily revert the add-on to the old version, without reverting the whole HA?

[sgurgul]

I wouldn't be sure if it's really unspecific for the service.

I checked that before I reported this ticket and I could easily find "call service" node having some data and still working in the most recent version - not triggering this error we discuss here.

Here is a sample - light turn_on service but configured with additional data. It works and does what expected - changed the brightness of the light:

[sgurgul]

And the workaround...
Here is a node:

and a sample configuration - data field content:
{ "type": "execute_script", "sequence": [ { "service": "evohome.set_zone_override", "data": { "entity_id": "climate.salon", "setpoint": msg.payload } } ] }

[zolakt]

I checked that before I reported this ticket and I could easily find "call service" node having some data and still working in the most recent version - not triggering this error we discuss here.

Hmm, weird... Are you sure that they actually do work, and not just "not produce an error"? I have similar examples that don't produce an error, but they don't do anything, e.g. the temperature isn't set. It used to work perfectly before the update. And it works perfectly fine when I call this service from Developer tools -> Services. I really doubt this is service specific. Initially I though it was maybe related to climate services, but since the logbook doesn't work either, that is definitely not the case.

[sgurgul]

Well, I see that light in front of me. It's changing brightness, definitely :)

[zolakt]

I can confirm that it isn't even data related. Here is another example. I've done the "set_veto" call with the API node (btw. thank you for that). Now I'm testing removing the veto. It doesn't have any data, it doesn't produce any errors... but it does nothing.

I suspect this might be related to having climate entities as target. Both your and mine examples are for climate entities, even my logbook one. Just perfect for the middle of the heating season...

[zachowj]

It has to do with the service that is being called doesn't accept entity ids as an array. A temporary workaround is to put the entity ID in the data field {"entity_id": "light.kitchen"}

[zolakt]

It has to do with the service that is being called doesn't accept entity ids as an array. A temporary workaround is to put the entity ID in the data field {"entity_id": "light.kitchen"}

Thanks. That workaround seems to work.

Do you know when a fix can be expected? I have a bunch of heating automations, none of them are working currently. It's a pretty big pain to switch all of them to the workaround and then back. If the fix will be released in the next HA update, I'll rather wait for it and operate them manually for the next 3-4 days

[sgurgul]

Great, thank you very much for prompt fix. I confirm - it works well.