The frontend now calls `utils.rst_to_html` to render the docstrings as
HTML instead of dumping them as raw text.
Also, actions and arguments are now cached to improve performance.
This reverts commit 71401a4936.
Temporarily reverted this commit because the `reuse_address` on the
application's `listen` method has only been implemented in Tornado 6.2 -
and Debian stable still shipts Tornado 6.1.
The WSGI container is a good option to wrap a multi-modal webapp
(Flask + websocket routes), but it's constrained to a single-process
approach and queued/pre-buffered requests. That makes performance poor
when handling requests that may take a few seconds to complete.
The Tensorflow module may take a few seconds to load the first time and
slow down the first scan of the plugins.
All the Tensorflow imports should therefore be placed close to where
they are used instead of being defined at the top of the module.
Defined a `platypush.backend.http.ws` package with all the routes, a
base `WSRoute` class that all the websocket routes can extend, and a
logic in the HTTP backend to automatically scan the package to register
exposed websocket routes.
It was just too painful to find a combination of versions of gunicorn,
gevent, eventlet, pyuwsgi etc. that could work on all of my systems.
On the other hand, Tornado works out of the box with no headaches.
Also in this commit:
- Updated a bunch of outdated/required integration dependencies.
- Black'd and LINTed a couple of old plugins.
The eventlet API has way too many dependency issues with gunicorn.
Still TODO: Fix or at least mitigate the WSGI workers timeout issue when
they handle websocket connections.
The websocket service is no longer provided by a different service,
controlled by a different thread running on another port.
Instead, it's now exposed directly over Flask routes, using
WSGI+eventlet+simple_websocket.
Also, the SSL context options have been removed from `backend.http`, for
sake of simplicity. If you want to enable SSL, you can serve Platypush
through a reverse proxy like nginx.
Instead of iterating over each of the entities in a grouping to find out
which groups should be displayed based on the selector's policy, the
selector can directly keep its `selectedGroups` attribute in sync with
the index.
`delete` will actually remove the record from the database (same as
`unset`'s new behaviour), while `unset` will set it to null without
deleting it (same as the `unset`'s previous behaviour).
Added `waitress` dependency. For performance and security reasons, it's
better to always run the Flask application inside of a uWSGI server.
`waitress` also makes things easier by avoiding to ask the user to
manually provide the external executable arguments, as it was the case
with `uwsgi` and `gunicorn`.
It was broken by the previous refactor of the entities panel, which no
longer triggers the `watch` callback on the upstream `entityGroups`.
The new approach listens for entity updates on the frontend bus and
dynamically creates the entity groupings in `selectedGroups` if they are
missing.
Unlike the other entity groupings, which are 4-layered (`grouping ->
group -> entity_id -> entity`), the grouping by ID only needs 3 layers
(`grouping -> entity_id -> entity`).
- Don't recalculate entity groups every time. Instead, keep them in sync
every time an entity is added or removed.
- Removed `computedChildren` from the entity component - no null nodes
are guaranteed to be passed now, so there's no need for another
iteration on the list of children.
- `childrenByParentId` now only looks in the scope of the entity's
children instead of searching all the entities.
The animation has a big impact on page loading performance when the
system includes a high number of entities that all need their loading
animation to be render.
Multiple style improvements for the entity components. Among these:
- A more consistent style for entity values and toggler buttons.
- Fixed overflowing/underflowing entities on smaller/larger screen
sizes.
- Simplified the stylesheets for many entities as many component classes
have now been moved to `common.scss`.
The entity name and value in the component header may be arbitrarily
long and rendered on small screens.
We therefore need to ensure that the text won't overflow the screen
width.
`entities.transform_entities` will pass back an empty list instead of an
empty dict if no entities were found, and the function should be able to
handle it.
Added Alembic environment and `run_db_migrations` logic to the entities
engine so database schema changes can be processed as soon as the
application is started.
- Support for nested attributes on event hook conditions. Things like
these are now possible:
```
from platypush.event.hook import hook
from platypush.message.event.entities import EntityUpdateEvent
@hook(EntityUpdateEvent, entity={"external_id": "system:cpu"})
def on_cpu_update_event(event: EntityUpdateEvent, **_):
print(event.args["entity"]["percent"])
```
- The scoring/regex extraction/partial string match logic in
`_matches_argument` is actually only needed for
`SpeechRecognizedEvent`. Other events don't need these features, and
event hooks may be actually triggered unexpectedly in case of partial
matches. Therefore, the "complex" `_matches_argument` has been moved
as an override only for `SpeechRecognizedEvent`, and all the other
events will perform simple key-value matching.
SQLAlchemy should automatically begin a transaction on
connection/session creation. Plus, `.begin()` messes up things with
SQLAlchemy 2, which has `autobegin` enabled with no easy way of
disabling it.
`Mapped` has been introduced only in SQLAlchemy 1.4, while Debian stable
still ships 1.3.
Removing the type annotation doesn't come with a big cost, but it keeps
Platypush compatible with Debian stable.
- `percent_field` should be declared on `platypush.schemas.dataclasses`
level, since it's not specific to the `system` plugin.
- Added a common `SystemBaseSchema` that takes care of calling
`_asdict()` if the object is passed as a `psutil` object instead of a
dict.
Plus, `platypush.schemas.system` has now been split into multiple
submodules to avoid a single-file mega-module with all the system
schemas definitions.
Also, there is now a single `Cpu` entity being exported, with a nested
hierarchy structured like:
```
cpu
-> cpu_info
-> cpu_times
-> idle
-> user
-> system
-> ...
-> cpu_load
-> ...
```
There are probably more optimal ways of achieving this other than
passing a reference to the full list of entities to each of the
entities, such as running a BFS to recursively expand all the entities
within the child hierarchy of an entity.
This is needed because the entity needs to know which entities aren't
direct children, but are two or more layers down in the hierarchy, so
they should be passed to their own child entities.
Remove `backend.sensor.distance` and `gpio.sensor.distance`. They are
now replaced by the `sensor.hcsr04` integration, which is compatible
with the new `SensorPlugin` API.
Removed `backend.sensor.dht` and `gpio.sensor.dht`. They have been
merged into the new `sensor.dht` integration, which supports the new
`SensorPlugin` API.
Removed `backend.sensor.accelerometer` and `gpio.sensor.accelerometer`.
The logic has now been merged in the new `sensor.lis3dh` integration,
which is compatible with the new `SensorPlugin` API.
Removed legacy `backend.sensor.motion.pmw3901` and
`gpio.sensor.motion.pmw3901`. They have been merged in the new
`sensor.pmw3901` integration, compatible with the new `SensorPlugin`
API.
No more `_value` in the JSON output instead of the `value` property.
If a column is marked as private, and there's an associated property
mapped to its public name, then we should use and serialize that value.
Removed the old `backend.sensor.bme280` and the old `gpio.sensor.bme280`
plugin. They have now been merged into the new `sensor.bme280` runnable
plugin, which extends the `SensorPlugin` API and supports entities.
`backend.serial` has been removed and the polling logic merged into the
`serial` plugin.
The `serial` plugin now supports the new entity engine as well.
`str.title` capitalizes any alphabetic letter after any non-alphabetic
letter. That's a problem for Platypush plugins' naming convention,
because plugins like `sensor.distance.vl53l1x` may be broken into
`sensor.distance.vl53.l1.x`.
Workaround for the circular dependency between
`platypush.entities.bluetooth` and `platypush.plugins.bluetooth.model`.
Unentangling the circular dependency would require way too much work,
since the entity model provides several helpers and properties that
depend on the plugin's model.
The workaround in this commit is to simply push those imports down in
the methods that use them, so they won't be imported until those methods
are called, as well as removing some type annotations that depended on
those objects.
- Support for cloud instances as native entities.
- Using Marshmallow dataclasses+schemas instead of custom `Response`
objects.
- Merge `linode` backend into `linode` plugin.
No replacements have been made for the OBEX backends (push and file
services). PyOBEX is too broken and unmaintained, and there are too many
poorly documented steps required to get an unprivileged user to run an
SDP service.
1. Check the manufacturer parsed via Bleak/Theengs
2. Check the MAC address prefix in the oui numbers table
3. Check from the reported `manufacturer_data`
- Merged together Bluetooth legacy and BLE plugins and scanners.
- Introduced Theengs as a dependency to infer BLE device types and
create sub-entities appropriately.
- Using `BluetoothDevice` and `BluetoothService` entities as the bread
and butter for all the Bluetooth plugin's components.
- Using a shared cache of devices and services between the legacy and
BLE integrations, with merging/coalescing logic included.
- Extended list of discoverable services to include all those officially
supported by the Bluetooth specs.
- Instantiate a separate pool of workers to discover services.
- Refactor of the Bluetooth events - all of them are now instantiated
from a single `BluetoothDevice` object.
Not the upserted entities themselves, no matter if expunged or made transient.
Reminder to my future self: returning the flushed entities and then using them
outside of the session or in another thread opens a big can of worms when using
SQLAlchemy.
That's the best way to ensure that all the columns are fetched eagerly and
prevent errors later when trying to access lazily loaded attributes outside
of the session/thread.
- Added `wait_start()` method that other threads can use to synchronize
with the engine and wait before performing db operations.
- Callback logic wrapped in a try/except block to prevent custom
integrations with buggy callbacks from crashing the engine.
ImportErrors on these entity modules will be ignored when dynamically
loading them, since they have optional external dependencies and we
shouldn't throw an error if we can't import them.
- Support for an optional callback on `publish_entities` to get notified
when the published object are flushed to the db.
- Use `lazy='selectin'` for the entity parent -> children relationship -
it is more efficient and it ensures that all the data the application
needs is loaded upfront.
- `Entity.entity_key` rolled back to `<external_id, plugin>`. The
fallback logic on `<id, plugin>` created more problems than those it
as supposed to solve.
- Added `expire_on_commit=False` to the entities engine session to make
sure that we don't get errors on detached/expired instances.
- Better logic to recursively link parent/children entities, so partial
updates won't get lost.
- Removed `EntitiesCache` - it was too much to maintain while keeping
consistent with the ORM, and it was a perennial fight against
SQLAlchemy's own cache.
- Removed `EntityNotifier` - with no need to merge cached entities, the
`notify` method has become much simpler and it's simply been merged
in the `EntitiesRepository`.
Exceptions that cause the termination of the plugin's loop should always
be logged as such, unless the plugin is supposed to stop and various
exceptions may occur upon teardown.
- Out `gattlib` + `pybluez`, in `bleak`. It's not platform-dependent, it doesn't
require libboost and other heavy build dependencies, and it doesn't require the
user that runs the service from having special privileges to access raw
Bluetooth sockets.
- Better integration with Platypush native entities. The devices are now mapped
to write-only `EnumSwitch` entities, and the status returns the serialized
representation of those entities instead of the previous intermediate
representation.
- Better synchronization logic on stop for `AsyncRunnablePlugin`.
- Fixed several thread names by dropping `prctl.set_name` in favour of
specifying the name directly on thread creation.
- Several LINT fixes.
This removes warnings on `config.get`, where the `logging` configuration
key may also contain the current logging stream and we end up with a
JSONDecodeError when trying to serialize it.
- Added support for `Battery` entities
- Fixed saturation range for `Light` entities
- Parsing `min`/`max`/`unit` from the status attributes, if available
- Toggle collapsed state also if clicked on the gap between the entity
name and the right edge, instead of opening the entity modal. The
entity configuration modal should open only when clicking on the
entity name or icon (and these should be highlighted on hover as links
as well).
- The collapsed state update should be propagated to the wrapped
component as well, if applicable.
The performance of the page is heavily degraded by components loaded
dynamically via defineAsyncComponent that recursively carry behind the
whole Vue machinery.
By wrapping defineAsyncComponent calls in shallowRef we make sure that
we only wire the root level of the newly created dynamic component.
Renamed to `notifyWarning` and `notifyError` respectively.
Those names can often clash with other properties defined on components
that extend the mixin (like entities).
- Support for device options as children configuration entities
- Refactored switches management, removed legacy `switches` plugin
integration, and supporting multiple binary switches for one device
The Zeroconf registration part may randomly get stuck, resulting in the
web server not being properly started.
It's therefore better to run the Zeroconf registration process
asynchronously, for it's not strictly required for the web server to
execute.
The Zeroconf registration part may randomly get stuck, resulting in the
web server not being properly started.
It's therefore better to run the Zeroconf registration process
asynchronously, for it's not strictly required for the web server to
execute.
When a cronjob receives a TIME_SYNC event (because the system clock has
changed/drifted and the cronjobs are expected to recalculate their next
run slot) it should also clear the event.
Otherwise, the next `wait` will be skipped and the cronjob will be
executed even if it wasn't scheduled.
This may make things a bit less optimal, but it's probably the only
possible solution that preserves my sanity.
Managing upserts of cached instances that were previously made transient
and expunged from the session is far from easy, and the management of
recursive parent/children relationships only add one more layer of
complexity (and that management is already complex enough in its current
implementation).
The `disable_logging` attribute was only available on events and
responses, and it could only either entirely disable or enable logging
for all the events of a certain type.
The new flag allows more customization by setting the default logging
level used for any message of a certain type (or `None` to disable
logging). This makes it possible to e.g. set some verbose events to
debug level, and the user can see them if they configure the application
in debug mode.
It also delegates the logging logic to the message itself, instead of
having different parts of the application handling their own logic.
The `disable_logging` attribute was only available on events and
responses, and it could only either entirely disable or enable logging
for all the events of a certain type.
The new flag allows more customization by setting the default logging
level used for any message of a certain type (or `None` to disable
logging). This makes it possible to e.g. set some verbose events to
debug level, and the user can see them if they configure the application
in debug mode.
It also delegates the logging logic to the message itself, instead of
having different parts of the application handling their own logic.
ZWaveJS has broken back-compatibility with zwavejs2mqtt when it comes to
events format.
Only a partial representation of the node and value objects is
forwarded, and that's often not sufficient to infer the full state of
the node with its values.
The `_dispatch_event` logic has therefore been modified to accommodate
both the implementation.
This means that we have to go conservative in order to preserve
back-compatibility and not over-complicate things, even if it (slightly)
comes at the expense of performance.
ZWaveJS has broken back-compatibility with zwavejs2mqtt when it comes to
events format.
Only a partial representation of the node and value objects is
forwarded, and that's often not sufficient to infer the full state of
the node with its values.
The `_dispatch_event` logic has therefore been modified to accommodate
both the implementation.
This means that we have to go conservative in order to preserve
back-compatibility and not over-complicate things, even if it (slightly)
comes at the expense of performance.
Since Parenthesized context managers are only supported on very recent
versions of Python (thanks black for breaking back-compatibility), we
should still use the old multiline syntax - it's not worth breaking
compatibility with Python >= 3.6 and < 3.10 just to avoid typing a
backslash.
The most recent versions of ZwaveJS-UI don't send the `hexId` of the
node on node change events. We have therefore to infer it from the
reported `dbLink`.
The most recent versions of ZwaveJS-UI don't send the `hexId` of the
node on node change events. We have therefore to infer it from the
reported `dbLink`.
The parent->child relationship is now modelled on the database itself,
so we no longer need value names specifically formatted as
`[DeviceName] ValueName` - the UI will take care of it.
- Infer entity types on the basis of their semantic type (bool, decimal,
list) and read-only attribute (read-only bool is `BinarySensor`,
read-write bool is `Switch`, read-only decimal is `NumericSensor`,
read-write decimal is `Dimmer`, etc.) instead of trying to infer it
from the command class. Only a small set of command classes (like
configurations, vendor-specific or internal values) will be excluded.
This should greatly increase the number of supported values.
- Added support for `EnumSwitch` entities.
- Added inference for illuminance and humidity sensors.
Adding the credentials ensures that tokens associated to non-existing
users, or users with an invalid password, won't be accepted, even if
they were correctly encrypted using the host's keypair.
This adds an additional layer of security in case the host's keypair
gets compromised.
PyJWT is a very brittle and cumbersome dependency that expects several
cryptography libraries to be already installed on the system, and it can
lead to hard-to-debug errors when ported to different systems.
Moreover, it installs the whole `cryptography` package, which is several
MBs in size, takes time to compile, and it requires a Rust compiler to
be present on the target machine.
Platypush will now use the Python-native `rsa` module to handle JWT
tokens.
`UserManager.get_users` should not return a reference to the query
object, since the query object will be invalidated as soon as the
connection is closed.
Instead, it should return directly the list of `User` objects.
- The `declarative_base` instance should be shared
- Database `session_locks` should be stored at module, not instance
level
- Better isolation of scoped sessions
- Enclapsulated `get_session` method in `UserManager`
- Don't publish a `get` request if the device has no exposed queriable
attributes.
- Perform the recursive build of the `get` request payload before
checking for the `access` attribute.
Changed from `type` to `category`, which is basically the `name_plural`
attribute of the associated entity type metadata.
This allows us to define distinct entity metadata entries that we still
want to share the same grouping - for instance, `temperature_sensor`,
`humidity_sensor` and `battery` should all be grouped under `Sensors` on
the frontend.