- Added wiring between `assistant.picovoice` and `tts.picovoice`.
- Added `RESPONDING` status to the assistant.
- Added ability to override the default speech model upon
`start_conversation`.
- Better handling of conversation timeouts.
- Cache Cheetah objects in a `model -> object` map - at least the
default model should be pre-loaded, since model loading at runtime
seems to take a while, and that could impact the ability to detect the
speech in the first seconds after a hotword is detected.
`AssistantEvent.assistant` is now modelled as an opaque object that
behaves the following way:
- The underlying plugin name is saved under `event.args['_assistant']`.
- `event.assistant` is a property that returns the assistant instance
via `get_plugin`.
- `event.assistant` is reported as a string (plugin qualified name) upon
event dump.
This allows event hooks to easily use `event.assistant` to interact with
the underlying assistant and easily modify the conversation flow, while
event hook conditions can still be easily modelled as equality
operations between strings.
Explicitly use a `CastBrowser` object initialized at plugin boot instead
of relying on blocking calls to `pychromecast.get_chromecasts`.
1. It enables better event handling via callbacks instead of
synchronously waiting for scan batches.
2. It optimizes resources - only one Zeroconf and one CastBrowser object
will be created in the plugin, and destroyed upon stop.
3. No need for separate `get_chromecast`/`_refresh_chromecasts` methods:
all the scanning is run continuously, so we can just return the
results from the maps.
- `pychromecast.get_chromecasts` returns both a list of devices and a
browser object. Since the Chromecast plugin is the most likely culprit
of the excessive number of open MDNS sockets, it seems that we may
need to explicitly stop discovery on the browser and close the
ZeroConf object after the discovery is done.
- I was still using an ancient version of pychromecast on my RPi4, and I
didn't notice that more recent versions implemented several breaking
changes. Adapted the code to cope with those changes.
It seems that the process keeps a lot of open connections to Chromecast
devices during playback.
The most likely culprit is the `_refresh_chromecasts` logic.
We should start a `cast` object and register a status listener only if a
Chromecast with the same identifier isn't already registered in the
plugin.
The project hasn't seen a commit in three years and it's probably been
abandoned by Mozilla.
New and better maintained speech-to-text integrations will be
investigated.
1. I no longer I use a Spotify account (I switched to Tidal after
Spotify deprecated libspotify), and I wouldn't like to create one
just to test this integration.
2. After a couple of years, the libspotify open fork (Librespot) seems
to be still in an unstable stage and it's already been discontinued
once - I would avoid rebuilding the integration against a dependency
that may change a lot in the near future.
