* Add support for pre-imports at setup time
alternative solution to #111331
* refactor
* refactor
* refactor
* mark >1.0s integrations
* no point in executor if already loaded
* no point in executor if already loaded
* cleanup
* cleanup
* two more
* one more
* analytics loads a lot more integrations
* cloud
* debug
* psutil, hardwre
* try zha
* Update homeassistant/setup.py
* await
* comments
* coverage
* coverage
* coverage
* move logic to loader
* move logic to loader
* preserve comments
* Allow setting if we support multiple config entries in config flow
* Move property to config flow instead of flow handler
* Move marking an integration as single instance only to manifest
* Revert line remove
* Avoid init a config flow or adding a new entry on a single instance with an entry
* Revert changes in test
* Process code review comments
* Apply code review suggestion
* Use discovery flow helper for hardware integrations
The discovery flow helper defers loading discovered integrations until after startup
to improve startup reliability.
* Use discovery flow helper for hardware integrations
The discovery flow helper defers loading discovered integrations until after startup
to improve startup reliability. Since hardware was not listed in as a
discovery integration, the notification for new discoveries was missing.
* Convert debouncer async_shutdown to be a normal function
nothing was being awaited here and the shutdown call was only used
in integrations marked internal and other internals. Its possible
that a custom component might have been using the method but it
seemed uncommon enough that it did not warrent marking as a breaking
change. The update coordinator is no longer awaiting anything in
async_shutdown either now but it seemed likely that this use
would get subclassed.
* fix
* Add async_schedule_reload helper to the ConfigEntries manager
We have cases where the the setup retry kicks in right before
the reload happens causing the reload to fail with
OperationNotAllowed. The async_schedule_reload will
cancel the setup retry before the async_reload task
is created to avoid this problem.
I updated a few integrations that were most likely
to have this problem. Future PRs will do a more
extensive audit
* coverage
* revert for now since this needs more refactoring in a followup
* cover
* cleanup and fixes
To wait for after dependencies we created a task to wait an asyncio.Event object,
instead of using an Event we can use an asyncio.Future instead and avoid the need
for a task wrapper
* Small performance improvements to config entry setup retry
- cache some properties that never change
- avoid loader.async_get_integration when we already have it
- avoid multiple integration.domain checks
* tweaks
* Make ConfigEntryItems responsible for updating unique ids
* Make ConfigEntryItems responsible for updating unique ids
* Make ConfigEntryItems responsible for updating unique ids
* Make ConfigEntryItems responsible for updating unique ids
* Make ConfigEntryItems responsible for updating unique ids
* Don't blow up if config entries have unhashable unique IDs
* Add test
* Add comment on when we remove the guard
* Don't stringify hashable non string unique_id
* Add helper function to update and reload config entry to config flow
* Use async_create_task
* Remove await
* Reload only when update & add task name
* Rename function
We should have been checking for the module in hass.data[DATA_COMPONENTS]
and not hass.config.components as the check was ineffective if there were
no existing integrations instances for the domain which is the case for
discovery or when the integration is ignored
* Improve performance of abort_entries_match
In #90406 a ChainMap was added which called __iter__
and __contains__ which ends up creating temp dicts
for matching
174e9da083/Lib/collections/__init__.py (L1022)
We can avoid this by removing the ChainMap since there
are only two mappings to match on.
This also means options no longer obscures data
* adjust comment
I added this in #77803 but I never designed it to be called
externally. External usage may break at any time because the
class is not designed for this. I should have made it protected
in the original PR but I did not think it would get called
externally (my mistake)
* Debounce discoveries to improve event loop stability at the started event
The first one is immediate and anything that fires within the next
second will be debounced to only happen once every second
* fix mock
J. Nick Koston
Jan-Philipp Benecke
Aidan Timson
Erik Montnemery
Marc Mueller
Jan Bouwhuis
Franck Nijhof
Paulus Schoutsen