architecture
architecture copied to clipboard
home-assistant
Removing an integration (config entry) should allow retention of entities.
Context
Currently, removing an integration (config entry) removes all devices associated with the integration and by extension all the entity ids from the entity registry. We should have an option to allow retention of entity ids in the registry. Some times users remove integrations without meaning to remove the entities and customization. e.g. removing the ZHA integration, because serial port path has changed (yeah, they should be using serial by-id path, but...) etc
Proposal
Allow retention of entities on integration or device removal.
Consequences
Users can temporarily remove integrations without loosing entities customization. The risk -- entity registry may have stale entries which users would have to clean up manually
Well changing serial port could be made a config entry option, but let's keep that out of scope.
I think that instead of cleaning up things right away, we should consider marking entries for deletion, which will then be done when Home Assistant shuts down.
I think that instead of cleaning up things right away, we should consider marking entries for deletion, which will then be done when Home Assistant shuts down.
That’s an interesting idea. Although it leaves it as a form of magic to the user... and if they restart while troubleshooting everything is gone...
I agree on the options flow. I have to peek at that soon.
Right, that's a good point. I wonder how we should expose it to the user? Maybe something like: "Clear data" ? It just feels a little weird. If I uninstall an app on my phone I expect data to be gone.
Clearing the data should be the default. It could be a check box in the remove confirmation dialog, where the user can uncheck the box.
The entity registry entry will need to be updated to remove the config entry id.
Is this option really needed? Maybe it's just a sign that something else isn't working as it should? If I remove an integration I don't expect its entities or their customizations to remain.
Right, that's a good point. I wonder how we should expose it to the user? Maybe something like: "Clear data" ? It just feels a little weird. If I uninstall an app on my phone I expect data to be gone.
On Android you expect settings to be stored (likely in Firebase) but the data to disappear.
Is there a way to detect that an entity has been has been customized by the user?
Is this option really needed? Maybe it's just a sign that something else isn't working as it should? If I remove an integration I don't expect its entities or their customizations to remain.
I think this is a big part. Currently you can't edit the primary settings of a config entry (like the usb path for zwave/zha, network key for zwave, username/password for a handful of them) without either hand-editing the .storage/core.config_entries file or removing the integration and re-adding it.
Perhaps a better solution would be adding a UI means or re-configuring a config entry's settings (from the main config flow, not the config entry options flow), and then add a separate option to disable a config entry, but not remove it. Disabling would effectively unload it without deleting data, removing it would remove all the data that goes with it.
For anyone who stumbles on this thread, the discussion about editing entries is at #377 (I think that would resolve the problem statement). I also believe removal should be a clean slate. Allowing data from a prior install to remain is prone to leaving orphaned data that never gets cleaned. Yes, it's implementation dependent but at least that's a clear bug.
This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.
For that reason, I'm going to close this issue.
../Frenck
