-
Notifications
You must be signed in to change notification settings - Fork 1
Description
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.