Skip to content

Support multiple Integrations #23

@Flix6x

Description

@Flix6x

A second integration does install, but I am trying to distinguish which one to use when triggering an action.

I found out that you can have 2 FM integrations installed, and enable/disable them separately. The most recently enabled integration is the one that ends up processing the Action. If you then disable that one, the services are unregistered and can't be called anymore, even if the older integration is still enabled. You have to disable and then enable the older integration again if you want to revert back to using the older integration.

I believe this is a relevant part of async_setup_entry:

hass.data[DOMAIN][FRBC_CONFIG] = FRBC_data
hass.data[DOMAIN]["fm_client"] = client

In many other Integrations, for example, the data is distinguished by entry_id:

hass.data.setdefault(DOMAIN, {})[entry.entry_id] = coordinator

Note that in async_unload_entry both other Integrations and our Integration are distinguishing data by entry_id already:

hass.data[DOMAIN].pop(entry.entry_id)

However, unlike other Integrations we are trying to be robust against a missing entry_id:

hass.data[DOMAIN].pop(entry.entry_id, None)

Probably we did this because we are not setting up the data correctly with the use of the entry_id.
I think we may need something like this instead:

entry_config = {
    FRBC_CONFIG: FRBC_data,
    "fm_client": client
}
hass.data.setdefault(DOMAIN, {})[entry.entry_id] = entry_config

and then adapt other places in the code where our Integration is fetching data from hass.data, accordingly.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions