Unknown domain (default/remote) in call_service

Third party integrations AppDaemon
,
2

After rolling back to 0.105.3, it didn’t work, so I rolled back to 0.105.2, which I know worked, yet it didn’t work this time. :confounded:

In doing research, I could not find anything like this, but I found a reference (I wish I could find where so I could link it here, but alas, I can’t find it again) where someone changed the “remote/turn_on” to “homeassistant/turn_on” so I tried that, and success! I have no idea why this changed. I did upgrade to AppDaemon 4 a couple of weeks ago, but I know it was working with “remote/turn_on” for at least a few days before the core update when it broke.

One other thing that changed in that intervening time was updates to HassOS. I noticed that after I rolled back, I received notices to update the core, but not HassOS, which indicates that does not get stored with snapshots. If that is the case, that would be the one thing that might tie all this together.

Anyway, I’m happy again!

3

Well, I said, “I’m happy again” too soon. While the homeassistant/turn_on and homeassistant/turn_off services adequately replace the remote/turn_on and remote/turn_off for the Harmony hub, there is no equivalent to replace the remote/send_command used to send specific commands to navigate menus and pause/play/fastforward/rewind, etc.

So, I considered whether it could be a Supervisor version or HassOS version, since those did not appear to change when I did the rollback. But in researching, I could not find any documentation of how to roll those back. I tried restarting them, but there was no change.

In reading the AppDaemon documentation, I came upon the self.list_services() function/api call, which, acording to the Change Log, is new to AppDaemon 4.0.0. So, I added this to my initialization routine:

self.log(self.list_services(namespace="global"))

When parsing through the list of services in the log, I could see that there were no services listed for the “remote” or “harmony_hub” domains. Obviously, that would account for the errors. But why were they missing? Was there anything else missing?

I thought this might be a bug in AppDaemon 4, so I reinstalled AppDaemon 3, and renamed my original appdaemon.yaml file back (I always keep old versions for a while), stopped AppDaemon 4 and started AppDaemon 3. The list_services() function threw an error, as expected since it was not part of AppDaemon 3. I tried the parts of my system that were not working with AppDaemon 4, and they were working again!

Okay, getting much better! Switching versions is very painless, so I swapped my appdaemon.yaml file back to version 4, stopped AppDaemon 3 and started AppDaemon 4 again. I found that the “remote” and “harmony” services were now listed! I tried my system, and everything is working again.

I compared the services list from before and after the problem. The first (problem) version had 136 services. The newer (working) version has 168. These are the services that are in the new version that were not in the old version:

{'namespace': 'default', 'domain': 'zwave', 'service': 'add_node'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'add_node_secure'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'cancel_command'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'change_association'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'heal_network'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'heal_node'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'print_config_parameter'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'print_node'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'refresh_entity'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'refresh_node'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'refresh_node_value'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'remove_failed_node'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'remove_node'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'rename_node'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'rename_value'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'replace_failed_node'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'reset_node_meters'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'set_config_parameter'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'set_node_value'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'set_poll_intensity'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'set_wakeup'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'soft_reset'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'stop_network'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'test_network'}, 
{'namespace': 'default', 'domain': 'zwave', 'service': 'test_node'}, 
{'namespace': 'default', 'domain': 'remote', 'service': 'learn_command'}, 
{'namespace': 'default', 'domain': 'remote', 'service': 'send_command'}, 
{'namespace': 'default', 'domain': 'remote', 'service': 'toggle'}, 
{'namespace': 'default', 'domain': 'remote', 'service': 'turn_off'}, 
{'namespace': 'default', 'domain': 'remote', 'service': 'turn_on'}, 
{'namespace': 'default', 'domain': 'harmony', 'service': 'change_channel'}, 
{'namespace': 'default', 'domain': 'harmony', 'service': 'sync'},

Interestingly, of the zwave domain, only this was in the bad version:
{'namespace': 'default', 'domain': 'zwave', 'service': 'start_network'},

So this leaves unanswered questions for me. Why did this happen? Was it a bad install? Will this happen again? If you have any answers to these questions, I hope you will post them here. And if you see any similar challenges, please share those as well.

4 
2020-03-11 20:48:33.656247 WARNING AppDaemon: Unknown domain (default/lock) in call_service from modes

I’m seeing this from appdaemon 4.0.3. It seems intermittent in that most of the time the locks work but sometimes… not… and I see this.

5

Just to follow-up on this, what I have learned is the problem seems to show up when HassOS is updated. When that happens, a bunch of services do not get loaded. What seems to correct it is to stop and restart AppDaemon.

What I have done to detect the problem is use AppDaemon 4’s list_services() function to get the full list of services. I create a variable in my initialize() function, then compare that list to the services I have now:

self.expected_services = <insert list returned previously by list_services()>
services_now = self.list_services(namespace="global")
if len([i for i in self.expected_services + services_now if i not in self.expected_services or i not in services_now]) == 0:
    self.log("Services list matches")
else:
    self.log("Services list does NOT match")

I realize I can improve on the code to list the differences. The important thing right now is that I can see if I am missing a bunch.

One side-effect of this is that when I install a new integration (for example, I setup Sonos last night), a few new services may appear, so I have to update my expected_services list. While a little annoying, it is better than having my Harmony functionality unexpectedly cease working!

(I am currently on AppDaemon 4.0.2.5, HassOS 3.13, HA Core 0.108.9)

6

I spent the weekend spinning up a new RPi4, and in that process had plenty of opportunity to experiment with different methods, configuration, and timing. I think I have found the root cause.

It appears that the list of services returned by the AppDaemon function self.list_services() is only updated once, at the launch of AppDaemon. If any new services come online after AD startup, they will not be returned by list_services(). Since, after a cold system start, it takes a while for z-wave services to be registered, this is why I am experiencing the problem mostly with z-wave. However, the problem happens with any newly added services with new integrations or components. Since AppDaemon runs in a separate container from Core HA, newly registered components regularly appear when AppDaemon has not been restarted.

I proved this by having my initialize() function test for the existence of a zwave device, and if it is not ready, set a listener for a z-wave service_registered event. Then, when that event is triggered, get list_services() still does not show the services that was just registered. And if you manually run list_services() later, it still doesn’t show up.

Example code snippets:

        if self.get_state("zwave.skimmer_pump_outlet") != 'ready':
            self.zwave_initializer = self.listen_event(self.initialize_zwave_listener,"service_registered",domain="zwave",service="test_node")
...
    def initialize_zwave_listener(self, name, id, type, event = None, function = None, data = None, kwargs = None):
        if "initialize" in self.logging_features:
            #message = "Event handler - name={}, id={}, type={}, event={}, function={}, data={}, kwargs={}".format(name, id, type, event, function, data, kwargs)
            #self.log(message)
            self.log("Initializing z-wave")
        self.cancel_listen_event(self.zwave_initializer)
        services_now = self.list_services(namespace="global")
        if len([i for i in self.expected_services + services_now if i not in self.expected_services or i not in services_now]) == 0:
            self.log("Services list matches")
        elif len(self.expected_services) < len(services_now):
            self.log("More services than expected")
        else:
            self.log("Services list does NOT match")

The only workaround I have found is to manually restart AppDaemon after all services have been registered, and only after that, compare my stored list of expected services with the list returned by list_services().

Currently running:
HassOS 3.13
Supervisor 222
HA Core 0.109.6
AppDaemon 4.0.2.5

I am also posting this to github at https://github.com/home-assistant/appdaemon/issues/977

2 Likes
7

For all concerned: I have been assured that this is fixed in the next release. No word on when that will be.

8

FWIW, every major system has been updated, yet the problem remains. Now running
HassOS 4.8
Supervisor 225
HA Core 0.110.4
AppDaemon 4.0.2.6

So much for the “assurances” that this would be corrected in “the next release.”

9

In the github issue you linked, he’s talking about AppDaemon releases not HA releases, and there was no new AD release in the last 3 months. In addition you are not even on the latest version now, the latest is 4.0.3.

10

Apparently you have a different definition for a software “release” than every software developer I have worked with for the past 45 years. As you can clearly see in my documented version numbers, on May 17, AppDaemon version was 4.0.2.5, and on June 1, AppDaemon version was 4.0.2.6. I distinctly remember installing that update. While not a major version, most developers would call this a “maintenance release.”

The problem appears to be that one of the required approvers has not yet approved the correction for merging.

11

I just checked again and there is not even an Appdaemon version 4.0.2.6 or 4.0.2.5. Here are the releases for AppDaemon, there you see the last release was more than 3 months ago as I said.
You are probably talking about a new release of the AppDaemon addon, but the addon has already been updated to use AppDaemon 4.0.3 in version 0.2.3, as you can see here. And there’s no version 4.0.2.6 neither for the addon nor for AppDaemon.

12

Screen capture directly from my AppDaemon add-on screen in the Supervisor:
image

I am only conveying exactly what I see. If this is not an accurate representation of the version numbering, you guys really need to provide us a better way.

13

AppDaemon addon and AppDaemon are not the same thing. The AppDaemon add-on is a docker container that uses AppDaemon and integrates smoothly into Home Assistant. The releases of the add-on and the releases of AppDaemon are independent from each other. When a new version of AppDaemon gets released, the add-on creator needs to update the add-on as well to incorporate the new version. And the version number between these two are in no way related to each other.

It’s written right there in your screenshot
current version: 0.2.6
The Add-on is called AppDaemon 4, the 4 is not part of the version number.
@frenck may explain this better than I do.

14

To a hassio user, all of this is gibberish - distinctions without a difference. If you want us to document versions when we report problems or seek assistance, you need to provide us a clear and consistent way to do so. The way you are treating your users will drive them away. Scolding people for doing their best to give you all the information that is available to them is not a way to build a loyal user base.

15

Hi there.

Just write to say that I’m suffering apparently the same behaviour in some services like tts/google_say that worked perfectly in previous releases. It’s an intermitent problem as you say, and I think that may be influenced by the recent changes in Home Assistant boot proccess.

Now not every service is available when HA boots, but it has some kind of lazy load. So I think that Appdaemon checkes that HA is available before all the services are available. When it comes to use certain service, AppDaemon has no knowledge about it. If I restart Appdaemon after HA, it works again…

2 Likes
16

Exact same observation!

17

Hi, I am a bit new to AppDaemon and wonder if I have same problem, or just doing something wrong. I am trying to call-service media-player , but in error log I says not defined. I have tried to restart AppDaemon module supervisor (V4.03), and verified that media_player, volume_set is listed in “list_services”. output.

I am trying to perform 2 calls, volume set and play_media , but they both fails.

any hints would be appreciated.

cmd.py:

self.call_service(media_player/volume_set,entity_id="media_player.office2",volume_level="0.5")
self.call_service(media_player/play_media,entity_id="media_player.office2",media_content_id=cont_id)

Error log

self.call_service(media_player/volume_set, entity_id="media_player.office2",volume_level="0.5") NameError: name 'media_player' is not defined

debug log : In self.list_services I can see:

{'namespace': 'default', 'domain': 'media_player', 'service': 'volume_set'},

18

In this case, no, this is not the same problem. In your case, your syntax needs adjustment. Try adding some quotes:

self.call_service("media_player/volume_set",entity_id="media_player.office2",volume_level="0.5")
self.call_service("media_player/play_media",entity_id="media_player.office2",media_content_id=cont_id)

But don’t beat yourself up. We all go through that stage at first.\

19

Thank you very much, its working now. It was indeed the missing “”. and obviously also had to add the content_type to play_media call.

cont_id = "http://10.0.1.43:8123/local/sounds/double-beep.mp3"
self.call_service("media_player/volume_set",entity_id="media_player.office2",volume_level="0.5",)
self.call_service("media_player/play_media",entity_id="media_player.office2",media_content_id=cont_id,media_content_type="music",)
20

Here the same. If I restart Appdaemon after starting my docker-copose , it works again too.

Is there a chance to write a little script for a docker-compose yaml to include to do a websocket login?

21

I have similar issue though with a bit different symptoms. In my case HADashboard cannot run scripts from mode widget. The same script run from script widget works ok. It happens after system restart (entire jail) and is back to normal when I restart addpaemon service. The following entries show up in appdaemon_daemon.log:

2020-10-27 18:10:02.612065 WARNING AppDaemon: Unknown domain (default/script) in call_service from stream
2020-10-27 18:11:14.906043 WARNING AppDaemon: Unknown domain (default/script) in call_service from stream

The appdaemon was installed as part of the HA Core community plugin to FreeNAS and so far was working ok. So it is installed in a FreeNAS jail in a virtualenv:

Testing virtualenv...

 CWD: /usr/local/share/appdaemon
 Python 3.8.6
 AppDaemon 4.0.5

HA Core is 0.116.2 release.
Any hints? I’m pretty sure it was working ok in one of previous versions running on python 3.7 but not sure exactly when it got broken.