* Add category registry
* Add entity registry support
* Update homeassistant/components/config/entity_registry.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Use ulid instead
* Add tests for adding same name in different scopes
* Handle keyerror on update
* Lookup tweak
* Omit categories from entity registry snapshots
* Use base registry
* Update snapshots
* Update snapshots
---------
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
This does not make default_config a requirement, it only preloads
the python code for the integration so it does not have to be loaded
when the import executor is busy. While its a tiny init file, it always
ends up at the end of the line and delays startup
* Phase out periodic tasks
* false by default or some tests will block forever, will need to fix each one manually
* kwarg works
* kwarg works
* kwarg works
* fixes
* fix more tests
* fix more tests
* fix lifx
* opensky
* pvpc_hourly_pricing
* adjust more
* adjust more
* smarttub
* adjust more
* adjust more
* adjust more
* adjust more
* adjust
* no eager executor
* zha
* qnap_qsw
* fix more
* fix fix
* docs
* its a wrapper now
* add more coverage
* coverage
* cover all combos
* more fixes
* more fixes
* more fixes
* remaining issues are legit bugs in tests
* make tplink test more predictable
* more fixes
* feedreader
* grind out some more
* make test race safe
* one more
* Schedule periodic coordinator updates as background tasks.
Currently, the coordinator's periodic refreshes delay startup because they are not scheduled as background tasks. We will wait if the startup takes long enough for the first planned refresh. Another coordinator's scheduled refresh will be fired on busy systems, further delaying the startup. This chain of events results in the startup taking a long time and hitting the safety timeout because too many coordinators are refreshing.
This case can also happen with scheduled entity refreshes, but it's less common. A future PR will address that case.
* periodic_tasks
* periodic_tasks
* periodic_tasks
* merge
* merge
* merge
* merge
* merge
* fix test that call the sync api from async
* one more place
* cannot chain
* async_run_periodic_hass_job
* sun and pattern time changes from automations also block startup
* Revert "sun and pattern time changes from automations also block startup"
This reverts commit 6de2defa0586165c2918ce006cf57aa3acaae730.
* make sure polling is cancelled when config entry is unloaded
* Revert "Revert "sun and pattern time changes from automations also block startup""
This reverts commit e8f12aad5579a1e5e3930957a46ea6f3dd9beecf.
* remove DisabledError from homewizard test as it relies on a race
* fix race
* direct coverage
* Pre import the rest of the recorder platforms before asyncio starts
I removed these from #112131 since I had trouble with the weather
tests passing due to a race that I could not figure out. The race
seems to have gone away now (at least locally) so hopefully the CI
will pass now
* Avoid importing counter and proximity integrations in logbook
* Avoid importing counter and proximity integrations in logbook
Move analytics setup to stage 1 to avoid delaying frontend startup
analytics was only needed in the frontend startup phase for onboarding.
Its very unlikely the user will be able to complete the onboarding
steps and get to the analytics screen before analytics is done loading
so we can delay loading it until stage 1. To be absolutely sure that
it is ready, the core_config step in onboarding will wait to proceed
if it is some how still being setup
This one ends in stage 1 and other components have to wait
for it to be imported. Its cheap to import but it ends up
at the end of the line which means other end up waiting for
it which is time we could be doing startup work
`2024-03-04 23:13:04.347 INFO (MainThread) [homeassistant.bootstrap] Setting up stage 1: {usb, websocket_api, webhook, zeroconf, bluetooth, ssdp, dhcp, cloud, network, api, http, hassio}`
It currently always has a wait time for the import executor
`2024-03-04 23:13:04.496 DEBUG (MainThread) [homeassistant.loader] Component webhook import took 0.146 seconds (loaded_executor=True)`
image_upload will always be setup because its a dep of person
and since person is a dep of onboarding which is a dep of
frontend its already a base requirement for homeassistant.
Pillow is now listed as a requirement for homeassistant
so we can be sure it installed by the time bootstrap is
loaded
image_upload loading is currently a bottleneck to
get the frontend loaded because it has to load in the
import executor when everything is busy early in startup
* Move backup/* WS commands to the backup integration
* Call correct command
* Use debug for logging
* Remove assertion of hass.data for setup test
* parametrize token fixture
* Refactor integration startup time tracking to reduce overhead
- Use monotonic time for watching integration startup time as it avoids incorrect values if time moves backwards because of ntp during startup and reduces many time conversions since we want durations in seconds and not local time
- Use loop scheduling instead of a task
- Moves all the dispatcher logic into the new _WatchPendingSetups
* websocket as well
* tweaks
* simplify logic
* preserve logic
* preserve logic
* lint
* adjust
* Signficantly reduce executor contention during bootstrap
At startup we have a thundering herd wanting to use the executor
to load manifiest.json. Since we know which integrations we are
about to load in each resolver step, group the manifest loads
into single executor jobs by calling async_get_integrations on
the deps of the integrations after they are resolved.
In practice this reduced the number of executor jobs
by 80% during bootstrap
* merge
* naming
* tweak
* tweak
* not enough contention to be worth it there
* refactor to avoid waiting
* refactor to avoid waiting
* tweaks
* tweaks
* tweak
* background is fine
* comment
* Drop use of regex in helpers.extract_domain_configs
* Update test
* Revert test update
* Add domain_from_config_key helper
* Add validator
* Address review comment
* Update snapshots
* Inline domain_from_config_key in validator
* Migrate restore_state helper to use registry loading pattern
As more entities have started using restore_state over time, it
has become a startup bottleneck as each entity being added is
creating a task to load restore state data that is already loaded
since it is a singleton
We now use the same pattern as the registry helpers
* fix refactoring error -- guess I am tired
* fixes
* fix tests
* fix more
* fix more
* fix zha tests
* fix zha tests
* comments
* fix error
* add missing coverage
* s/DATA_RESTORE_STATE_TASK/DATA_RESTORE_STATE/g
