Endless call_service events?

[123 (Taras)]

Does anyone else see this on their system?

If I use Developer Tools > Events to listen for call_service events, I see an endless stream of events reporting this:

Event 133 fired 22:18:
{
    "event_type": "call_service",
    "data": {
        "domain": "persistent_notification",
        "service": "dismiss",
        "service_data": {
            "notification_id": "config_entry_discovery"
        }
    },
    "origin": "LOCAL",
    "time_fired": "2021-10-26T02:18:39.754810+00:00",
    "context": {
        "id": "5daeccb3bf2e3b51c9cf1e599d388fec",
        "parent_id": null,
        "user_id": null
    }
}

They come in bursts, ranging from about 5 at a time to dozens. Within about a minute of observation, it reported over 130 events containing the same data.

I’m using 2021.10.4. Does anyone know why these events are produced?

BTW, I have call_service events excluded from the recorder integration.

[tom_l]

Yes I am.

Event 55 fired 13:48:

{
    "event_type": "call_service",
    "data": {
        "domain": "persistent_notification",
        "service": "dismiss",
        "service_data": {
            "notification_id": "config_entry_discovery"
        }
    },
    "origin": "LOCAL",
    "time_fired": "2021-10-26T02:48:48.423863+00:00",
    "context": {
        "id": "efe94f367b20f0097dc8d1a29dd75f5d",
        "parent_id": null,
        "user_id": null
    }
}

[123 (Taras)]

Thanks for taking the time to confirm it’s not unique to my system.

Based on the phrase “config_entry_discovery” it seems like there’s continuous monitoring of configuration entries. However, it’s unclear to me why that activity (whatever it actually is) is reported as as a dismissal of a persistent_notification.

Have you excluded call_service events from recorder? If you have not, I assume these events are not recorded by default … otherwise your database would be filled with these things! (Or is it?)

[tom_l]

No I have not excluded any events from the recorder, only entities.

I do have a few ignored integrations that could be causing it:

[123 (Taras)]

FWIW, I stumbled over this when I simply wanted to see the event produced when I executed a certain service call. It’s nearly impossible to observe it because it’s swamped by these endless events.

[tom_l]

I reckon it is the ignored discovery messages as I see a persistent notification very briefly during restart.

[123 (Taras)]

I have also observed these events on my test system which has just two (config-flow) integrations (ELKM1 and Supervisor) and seven ignored integrations.

Anyway, I will experiment with it tomorrow (disable zeroconf, etc) and see what, if anything, affects the production of these events.

[123 (Taras)]

Based on my experiments, the endless call_service events (of the type posted above) are produced by the SSDP integration (Simple Service Discovery Protocol) and the zeroconf integration (Zero-configuration networking).

---

All new installations are configured with default_config. It’s a shorthand way of including over 30 individual integrations. Among those integrations are SSDP and zeroconf (and DHCP Discovery) which permit Home Assistant to search your local network for compatible devices. When discovered, Home Assistant presents suitable integrations that you may install to integrate the discovered devices.

---

When I disabled the SSDP integration, it dramatically reduced the number of call_service events. Only 23 events were generated over a span of 10 minutes. In contrast, with SSDP enabled over 130 were produced within a minute. When both SSDP and zeroconf were disabled, no call_service events were reported. Enabling the DHCP Discovery integration did not produce call_service events.

I don’t know why the SSDP and zeroconf integrations generate these events (Dismissing a persistent_notification). The main drawback of this chatty behavior is that if you ever need to examine a specific call_service event, it is likely to be lost in the flood of these numerous events.

---

In my case, Home Assistant has already discovered all of the devices I own so I no longer need it to continue monitoring my network for others. Therefore I have chosen to disable the SSDP and zeroconf integrations.

[tom_l]

@123

I don’t know why the SSDP and zeroconf integrations generate these events (Dismissing a persistent_notification).

I’m guessing lazy quick fix programming.

A device is discovered and a persistent notification generated. Then the ignore status is checked and the notification dismissed if required.

Really the check should happen before the notification is created.

Do you want to create the issue?

[123 (Taras)]

@tom_l

Do you want to create the issue?

It looks like someone beat me to it last month!

I searched through recent closed Issues and found that someone already reported it here:

call_service persistant_notification dismiss config_entry_discovery got triggered repeatedly

Bdraco responded with this PR:

Only create discovery/reconfig notification when its not present

Balloob created a more recent PR addressing the same issue:

Refactor persistent notification to no longer route all data via a service

Both PRs were pulled into the dev branch so they stand a good chance of appearing in the 2021.11.0 release.