Different versions of the `sounddevice` dependency may or may not return
the `index` parameter when querying the available sound devices.
Thus, the code should be ready for both cases.
The integration was based on my old fork of the AVS service, which is no
longer functional given the changes the the Amazon's backend side.
A new `avs-device-sdk` is now available, but it seems that it requires
lengthy compilation processes which are RaspberryPi-specific.
Further investigation is needed for a new Alexa plugin - see #334.
It only existed as a back-compatibility layer with armv6, since there
was no build of the assistant library that worked on Raspberry Pi Zero.
But that API layer has been discontinued by Google and it's no longer
functional, so only the `assistant.google` integration (on x86_64 and
armv7) is currently supported.
continuous-integration/drone/push Build is passingDetails
- `iputils` should be an explicit system dependency for `ping`.
Some minimal systems (like some Docker images) may not have the `ping`
command installed out of the box.
- `hid` and `marshmallow_dataclass` should be among the auto-mocked
modules.
Added a `wrapped` "hidden" parameter to the function returned by the
`@action` decorator.
We need this to access the underlying decorated function when e.g. we
need to access its specs or decorators.
- The `inspect` plugin and the Sphinx inspection extensions now use the
same underlying logic.
- Moved all the common inspection logic under
`platypush.common.reflection`.
- Faster scanning of the available integrations and components through a
pool of threads.
- Added `doc_url` parameters.
- Migrated events and responses metadata scanning logic.
- Now expanding some custom Sphinx tag instead of returning errors when
running outside of the Sphinx context - it includes `:class:`,
`:meth:` and `.. schema::`.
1. Improved documentation. Every plugin now reports the exact steps to
get the integration up and running with the right API scopes.
2. All Google plugins now have a standard process to get (and reuse) the
client secret. Except for PubSub, Translate and Maps (which have
their own flows), all the Google plugins now read the client secrets
from `<WORKDIR>/credentials/google/client_secret.json` by default.
3. Black/LINT for some of those plugins, which hadn't been touched in a
while.
4. The interface to pass API scopes is now leaner. It's now possible to
pass a scope directly as e.g. `calendar.readonly` rather than
`https://www.googleapis.com/auth/calendar.readonly`.
5. Improved the logic to retrieve the right scope tokens file. If e.g.
an integration requires the role `A`, and a credentials file exists
for the roles `A` and `B`, then this file will be used rather than
prompting the user to authenticate again.
The old type configuration
(`platypush.plugins.calendar.name.CalendarNamePlugin`) is a bit clunky.
Instead, since the type will always be a plugin, we should encourage
the use of `calendar.name` directly to identify the type.
continuous-integration/drone/push Build is passingDetails
If the client that forwarded the request is no longer available (either
because an exception or a timeout was raised) then its I/O buffer and
event loop may be closed.
In this case, the response callback should handle and report the
exception, and still set the event, so that any other threads waiting
for the response can move on.
continuous-integration/drone/push Build is passingDetails
Added an `add_dependencies` plugin to the Sphinx build process that
parses the manifest files of the scanned backends and plugins and
automatically generates the documentation for the required dependencies
and triggered events.
This means that those dependencies are no longer required to be listed
in the docstring of the class itself.
Also in this commit:
- Black/LINT for some integrations that hadn't been touched in a long
time.
- Deleted some leftovers from previous refactors (deprecated
`backend.mqtt`, `backend.zwave.mqtt`, `backend.http.request.rss`).
- Deleted deprecated `inotify` backend - replaced by `file.monitor` (see
#289).
By default, the `phue` library will store the file containing the token
and the bridge configuration under `~/.python_hue`.
That's outside of our application folder, and it can't easily be copied
around or added to Docker volumes.
We should instead have it under `<WORKDIR>/light.hue/config.json`, in
line with what the other plugins do, and if `~/.python_hue` is available
but `<WORKDIR>/light.hue/config.json` isn't then we should copy the
legacy file to the new one.
continuous-integration/drone/push Build is passingDetails
I've tried my best to keep it around, but the endpoints seem to be
broken, they no longer have a link to their API v3 documentation, and
the API Explorer that was supposed to be in the dashboard is gone.
Fabio Manganiello