Service call does not work from developer tools

[bgalport]

The automation script below works fine to turn the light on when my garage door opens. But if I use developer tools->services to call the the same service light.turn_on with an entity_id of light.garage_light nothing happens. Same problem when I call the service from appdaemon. Am I doing something wrong?

- alias: garage_light_on_when_door_open
   id: garage_light_on_with_door_open
   trigger:
     platform: state
     entity_id: sensor.garage_door
     to: 
       - 'opening'
       - 'open'
   action:
     - service: light.turn_on
       entity_id: light.garage_light

[finity]

Are you using yaml mode or UI mode in the services tab?

[bgalport]

I don’t see any option to specify mode on that screen

[finity]

Which version of HA are you on?

[petro]

don’t include the entity_id in the service data.

[bgalport]

[petro]

That version is 6 months old now, you’re going to need to specify it when starting support threads. Either way, if what I said above doesn’t work, you’ll need to post your logs

[bgalport]

The entity_id in the service data gets populated automatically when I select the entity.
There are no log entries generated when I call the service.

[petro]

Then home assistant thinks it’s working. What kind of light is this?

[bgalport]

It’s MQTT. As I mentioned in my initial post, the same service call works from an automation script.

- platform: mqtt
  name: "Garage Light"
  command_topic: "shellies/shelly1-553B35/relay/0/command"
  state_topic: "shellies/shelly1-553B35/relay/0"
  payload_on: "on"
  payload_off: "off"
  optimistic: false

[finity]

@petro

don’t include the entity_id in the service data.

I could have sworn that the “entity_id:” needed to be there. Even now the example on the services tab show it in there.

Unless I’m misunderstanding what you mean.

[petro]

I don’t remember, it was 6 months ago (Or however long ago). I was taking a stab in the dark.

[finity]

actually to add…

I think in those older versions everything needed to go under “data:”

like this:

data:
  entity_id: light.garage_light

[petro]

I couldn’t remember if it was passed outside the service data or not when the dropdown was present. There’s 3 ways to call a service now:

really old way

service: xyz
entity_id: blah

old way

service: xyz
data:
  entity_id: blah

and new way

service: xyz
target:
  entity_id: blah

all 3 still work, his version should only have the old ways working. Although there were a few versions where the new way worked but wasn’t advertised.

[koying (Chris B)]

Thanks for this. It’s been quite confusing to me which form is to be used…

[bgalport]

I’ve just upgraded to 2021.7.2 and tried the same thing again in both UI and YAML mode. Still nothing and no logs

[petro]

Not sure what to tell you. The issue lies with your mqtt setup then. Unless your logs are filtered. Only you know that.

[bgalport]

If it was a problem with the MQTT setup, the automation would not work either. I’ll keep digging, in the meantime thanks for trying to help.

[petro]

That is true, which is why it doesn’t make sense that there’s no errors in your logs. When a service call fails, errors will appear. You haven’t posted any logs, so I have to take your word on it. 9 times out of 10 the user is omitting information or looking in the wrong spot. I wasn’t responding to you because I don’t know what you’re doing that’s different than everyone else.

[bgalport]

I hear you. I’ve done my fair share of tech support. I’ve attached a log extract having tried to call the service at 19:50. The zigbee errors are to due to a separate harware issue. To be fair there is not much latitude for getting it wrong when you are selecting both the service and the entity from drop-down lists in UI mode.