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`.
Fabio Manganiello