docs
docs copied to clipboard
qtoggle
A way of interconnecting sensors, actuators and other data sources
Hello, I took a look over the devices section and I was not able to identify any door sensor or movement sensor. Is there anyone that I might have skipped?...
Currently, all attributes (whether port or device ones) are listed all together, with no ordering or grouping. This makes it difficult for frontends to display them to the user in...
The `GET /firmware` API call should disclose the version that the device is currently upgrading to, while upgrading.
When dealing with many slave ports, there's sometimes no need to add all of them to master; some of them may not need to be exposed via master. To be...
Currently, attributes `offline`, `last_sync` and `validity` are defined only for slave ports exposed by master. The reasoning behind them can be easily extended and applied to any local port. To...
Devices that support expressions should accept an expression instead of a simple value, when processing `POST /ports/{id}/value` requests.
Devices should be able to optionally store port values within a period of time. Purposes include: * auditing * displaying graphs * debugging Desired operations: * paginated listing within a...
Devices should have optional support for managing logs. Purposes of these logs include: * auditing * remote debugging Desired operations: * paginated listing within a given period of time *...
All generated events should have a timestamp, if real date/time is available on the device.
There are two attributes whose data type is not one of the currently accepted ones: * `flags` is a list of strings * `choices` is a list dictionaries