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
* Avoid errors when no internet connection
* Add error
* Create task in HA
* change from matter to automower
* tests
* Update homeassistant/components/husqvarna_automower/coordinator.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* address review
* Make websocket optional
* fix aioautomower version
* Fix tests
* Use stored websocket
* reset reconnect time after sucessful connection
* Typo
* Remove comment
* Add test
* Address review
---------
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Dont remove api key during migration
* Fix return
* Fix test
* Make lambda more readable
* Move fixtures to init, move migration test to test_init.py
* Refactor config_entry data assignment
* Refactor system_bridge migration tests
* Fix type for debug message
* Fix type for debug message
* Remove duplicated unused code (rebase error)
* Refactor test_migration_minor_2_to_1 to test_migration_minor_future_to_2
* Fix version check in async_migrate_entry
* Update migration logic to handle future minor version
* Add ConfigEntryState assertion in test_init.py
* Change condition to minor_version < 2
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Refactor system bridge migration tests
* Remove minor downgrade code
* Update tests/components/system_bridge/test_init.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Update tests/components/system_bridge/test_init.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Apply suggestions from code review
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Move dataclass to store requested data to data.py
* Use dataclass in config flow
* Move media player and sensor onto data.py dataclass
* Move data and handler inside validate
---------
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
These were very likely to be cached so they were low on the
list to migrate, but since they are called in the event loop
its best to be sure we do no blocking I/O
discovered in https://github.com/home-assistant/core/pull/112295#discussion_r1513505710
We only checked if the last language had files to load
instead of all of them. The checks for each language
are the same because the only reason we would skip
a language is a missing/broken integration or the integration
is a single file. Both of these loop conditions are always
the same reguardless of the language so the check worked
* Add system_health to the hassio pre-imports to avoid a late executor job
`2024-03-05 17:01:33.034 DEBUG (MainThread) [homeassistant.loader] Importing platforms for hassio executor=[system_health] loop=[] took 0.12s`
This one does not take that much time but it happens at a time where
the import executor is the most busy during startup
* key
* move patch as its too early now
* Fix config modules being imported in the event loop
There was a late import in this integration because of the circular import.
The code has been rearranged to avoid the circular imports
* fixes
* fixes
* fix patching
* make eager
* remove unrelated change from this branch
We previously checked Integration.config_flow to see if we should
pre-import the config flow, but this is now always set for some
integration like `homeassistant_green`, `hassio`, etc. Instead
we can add it to the rest of the platforms since we already know
which files exist. This simplifies the logic and ensures the pre-import
still happens if the file is there even if its not listed in the
manifest
`2024-03-04 22:54:31.906 DEBUG (MainThread) [homeassistant.loader] Importing platforms for homeassistant_green executor=[config_flow] loop=[] took 2.74s`
* Migrate remaining calls in config modules to async_get_component
There were a few cases that were still using get_component that
could have done blocking I/O in the event loop, although it
was unlikely.
The caching check in async_get_component has been moved
up to avoid creating the future if the module is already in
the cache
* fix one more
