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.
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 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.
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.
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.