Struggling to get call_service working again

I upgraded an HA/AD system from something old (I don’t have the versions handy and I assume they are not relevant) to the latest versions. As part of the upgrade, I’m trying to get my old appdaemon apps working again. I cannot seem to get the call_service() function to work.

I think that I figured out that the service name uses a “/” delimiter between the domain and service now rather than “.” which was used in the older versions. The current documentation does contradict itself on that subject in the API reference section:

For listed services, the part before the first period is the domain , and the part after is the ``service name`. For instance, light/turn_on has a domain of light and a service name of turn_on.

However, with that change, I have moved on from the first problem to the next one. This call to a service named “set_variable” provided by a custom component called “variable” still fails.

self.call_service('variable/set_variable', entity_id='variable.sunrise', value=localtime)

The error message in the appdaemon error log looks like this:

2020-08-29 11:00:01.010688 WARNING HASS: Error calling Home Assistant service default/variable/set_variable
2020-08-29 11:00:01.011040 WARNING HASS: Code: 400, error: 400: Bad Request

My questions are thus:

  1. Where does the “default” element in the service name come from?
  2. Is appdaemon sending the service name with “/” delimiters when HA seems to use “.”
  3. Does the 400/Bad Request result tell us something else?

Then you must have upgraded from a really old version, the version I started with more than two years ago already used the dash and not the point.

Does the call service work for other services like turning on a light? Do you see the service listed when you use the list_services method?

That’s the namespace, shouldn’t matter except if you have multiple HA instances configured in AppDaemon.

No, the “/” is just the syntax for the appdaemon method that calls the home assistant service. The appdaemon call_service method “translates” the “/” to a “.”

Thanks for the suggestions. I added the following to the initialize method in one of my apps:

      for service in self.list_services():
        self.log('Services: {}'.format(service))
      self.call_service('variable/set_variable', entity_id='variable.daylight', value=88)
      self.call_service('light/turn_off', entity_id='office.light')

The resulting list of services includes:

2020-08-30 10:48:20.954929 INFO sun: Services: {'namespace': 'default', 'domain': 'variable', 'service': 'set_variable'}

The call to call_service() with a service of ‘variable/set_variable’ fails as usual. The call to call_service() with a service of ‘light/turn_off’ doesn’t fail but it doesn’t turn the light in the office off. I tried the old syntax of ‘light.turn_off’ and it didn’t fail and didn’t turn the office light off.

I tried calling self.turn_off(‘light.office’) and that worked as expected.

Do you have an MQTT plugin setup in AppDaemon?

Can you try:

self.call_service('light/turn_off', entity_id='office.light', namespace="default")

and can you please show your config from appdaemon.yaml?

I don’t have MQTT or any other plugins setup in appdaemon.

I tried adding the namespace argument to the call_service invocation and it made no difference. The call generates no errors but doesn’t result in the light state being changed.

Here is my appdaemon.yaml:

appdaemon:
  latitude: ****
  longitude: ****
  elevation: 157
  time_zone: America/Chicago
  api_port: 5000
  plugins:
    HASS:
      type: hass
      ha_url: http://localhost:8123
      token: !secret hass_token

logs:
  main_log:
    filename: /home/homeassistant/.appdaemon/logs/appdaemon.log
    log_generations: 5
    log_size: 100000
  access_log:
    filename: /home/homeassistant/.appdaemon/logs/access.log
    log_generations: 5
    log_size: 100000
  error_log:
    filename: /home/homeassistant/.appdaemon/logs/error.log
    log_generations: 5
    log_size: 100000
  diag_log:
    filename: /home/homeassistant/.appdaemon/logs/diag.log
    log_generations: 5
    log_size: 100000
  applog:
    name: AppLog
    filename: /home/homeassistant/.appdaemon/logs/app.log
    log_generations: 5
    log_size: 100000

admin:

http:
  url: http://localhost:5050

api:

admin:

hadashboard:
  dash_url: http://localhost:5050

I have this problem ,but I fixed it by restarting Appdaemon. Everytime I restart home assistant I have to restart appdaemon completely.

I just realized that the the entity_id in the service call is wrong, I just blindly copied your code. the entity_id should be light.office and not office.light.
Does the variable variable.daylight exist at startup of AppDaemon? I could imagine this being a problem.

Yep. That was the problem with the test of the “light/turn_off” service call. Sorry about that.

I have no idea when the variable component instance come into being during startup of appdaemon. However, the errors occur every day while appdaemon is running and the listen_state() actions trigger so I don’t think that it’s a race condition that is the root of the problem.

I’m interested to hear more about your problem. I have started and restarted appdaemon with the systemctl service during my initial debugging of the problem so I don’t think my problem is identical to yours.

Is there any way to get HomeAssistant to tell me why it’s throwing the 400 error? That would definitely help as I’m still stuck by this.