* Allow tts options of type list such as profiles in google_cloud
* Update tests/components/tts/test_media_source.py
* Don't mix engine specific options with other options
* Fix test
* Update assist_pipeline snapshots
---------
Co-authored-by: Paulus Schoutsen <balloob@gmail.com>
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
Co-authored-by: Erik Montnemery <erik@montnemery.com>
* Add issue asking users to disable ESPHome assist_in_progress binary sensor
* Include integration name in title and description
* Add repair flow
* Improve test coverage
* Allow targetting conversation agent as pipeline
* Test that we can use a conversation entity as an assist pipeline
* Add test for WS get
---------
Co-authored-by: Michael Hansen <mike@rhasspy.org>
* Refactor config entry forwards to implictly obtain the lock instead of explictly
This is a bit of a tradeoff to not need async_late_forward_entry_setups
The downside is we can no longer detect non-awaited plastform setups
as we will always implicitly obtain the lock instead of explictly.
Note, this PR is incomplete and is only for discussion purposes
at this point
* preen
* cover
* cover
* restore check for non-awaited platform setup
* cleanup
* fix missing word
* make non-awaited test safer
* Report non-awaited/non-locked config entry platform forwards
Its currently possible for config entries to be reloaded while their platforms
are being forwarded if platform forwards are not awaited or done after the
config entry is setup since the lock will not be held in this case.
In https://developers.home-assistant.io/blog/2022/07/08/config_entry_forwards
we advised to await platform forwards to ensure this does not happen, however
for sleeping devices and late discovered devices, platform forwards may happen
later.
If config platform forwards are happening during setup, they should be awaited
If config entry platform forwards are not happening during setup, instead
async_late_forward_entry_setups should be used which will hold the lock to
prevent the config entry from being unloaded while its platforms are being
setup
* Report non-awaited/non-locked config entry platform forwards
Its currently possible for config entries to be reloaded while their platforms
are being forwarded if platform forwards are not awaited or done after the
config entry is setup since the lock will not be held in this case.
In https://developers.home-assistant.io/blog/2022/07/08/config_entry_forwards
we advised to await platform forwards to ensure this does not happen, however
for sleeping devices and late discovered devices, platform forwards may happen
later.
If config platform forwards are happening during setup, they should be awaited
If config entry platform forwards are not happening during setup, instead
async_late_forward_entry_setups should be used which will hold the lock to
prevent the config entry from being unloaded while its platforms are being
setup
* run with error on to find them
* cert_exp, hold lock
* cert_exp, hold lock
* shelly async_late_forward_entry_setups
* compact
* compact
* found another
* patch up mobileapp
* patch up hue tests
* patch up smartthings
* fix mqtt
* fix esphome
* zwave_js
* mqtt
* rework
* fixes
* fix mocking
* fix mocking
* do not call async_forward_entry_setup directly
* docstrings
* docstrings
* docstrings
* add comments
* doc strings
* fixed all in core, turn off strict
* coverage
* coverage
* missing
* coverage
* Default agent as entity
* Migrate constant to point at new value
* Fix tests
* Fix more tests
* Move assist pipeline back to cloud after dependenceis
* Deconflict based on wake word
* Undo test
* Make wake up key a string, rename error
* Update snapshot
* Change to "wake word phrase" and normalize
* Move normalization into the wake provider
* Working on describe
* Use satellite info to resolve wake word phrase
* Add test for wake word phrase
* Match phrase with model name in wake word provider
* Check model id
* Use one constant wake word cooldown
* Update homeassistant/components/assist_pipeline/error.py
Co-authored-by: Paulus Schoutsen <balloob@gmail.com>
* Fix wake word tests
---------
Co-authored-by: Paulus Schoutsen <balloob@gmail.com>
* Migrate cloud stt to config entry
* Update default engine
* Test config flow
* Migrate pipelines with cloud stt engine to new engine id
* Fix test after rebase
* Update and add comment
* Remove cloud specifics from default stt engine
* Refactor cloud assist pipeline
* Fix cloud stt entity_id
* Try to wait for platforms before creating default pipeline
* Clean up import
* Move function in cloud assist pipeline
* Wait for tts platform loaded in stt migration
* Update deprecation dates
* Clean up not used fixture
* Add test for async_update_pipeline
* Define pipeline update interface better
* Remove leftover
* Fix tests
* Change default engine test
* Add test for missing stt entity during login
* Add and update comments
* Update config entry title
* Add websocket command to capture audio from a device
* Update homeassistant/components/assist_pipeline/pipeline.py
Co-authored-by: Paulus Schoutsen <balloob@gmail.com>
* Add device capture test
* More tests
* Add logbook
* Remove unnecessary check
* Remove seconds and make logbook message past tense
---------
Co-authored-by: Paulus Schoutsen <balloob@gmail.com>
* Add ATTR_PREFERRED_FORMAT to TTS for auto-converting audio
* Move conversion into SpeechManager
* Handle None case for expected_extension
* Only use ATTR_AUDIO_OUTPUT
* Prefer MP3 in pipelines
* Automatically convert to mp3 on demand
* Add preferred audio format
* Break out preferred format
* Add ATTR_BLOCKING to allow async fetching
* Make a copy of supported options
* Fix MaryTTS tests
* Update ESPHome to use "wav" instead of "raw"
* Clean up tests, remove blocking
* Clean up rest of TTS tests
* Fix ESPHome tests
* More test coverage
