Add support for IAS warning devices
Closed this issue · 1 comments
Currently, there is no converter for warning devices (like, e.g., sirens).
My plan is to add a channel type for warning devices as well as a converter, using the IAS WD cluster (0x0502) for controlling the devices.
Examples of devices supporting this cluster:
- The bitron video siren 902010/29
- The bitron video smoke detector 902010/24
I have thought about how to model IAS warning devices on the ESH side. Basically, one can do three things with a warning device: (1) trigger a warning signal emitted by the device (using a siren and/or a strobe signal, which automatically stops after a configurable time), (2) stop the current warning signal, or (3) emit a short audible and/or visible pulse from the device ("squawk").
I will not consider (3) in this comment, as I believe this this is easier to model on the ESH side compared to (1) and (2).
Considering (1) and (2), on first sight, this looks like a switch channel, where turning the switch on triggers the warning, and turning the switch off turns the warning off.
However, the warning signal can be configured in many ways, including (a) a warning mode with 6 different options, (b) the selection between siren, strobe, or both, and (c) the volume of the siren, and users should be able to use different configurations for the warning signal in different situations (e.g., one warning mode for intruder alerts, and another warning mode for a fire alarm).
So there's need for configuring which type of warning is triggered on the device. One option is to use a channel configuration to configure the type of warning. The disadvantage here is that the channel needs to be reconfigured every time one wants to use a different warning type. Another option is to have multiple channels, that can each be configured to trigger a different warning type - but how to decide how many different warning types a user wants to have? Also, adding multiple channels for a single converter does not fit into how the binding creates the channels currently.
The third option I see (which is my favourite) is as follows: The binding generates one String-typed channel, and dynamically provides command options (from this soon-to-be-merged PR) for that channel: One command option for stopping the warning, and one command option for each provided 'warning type' (i.e., configuration of the triggered warning), where warning types can be provided in two ways: (1) by implementing a new interface WarningConfigurationProvider so that solutions can provide warning types that the solution wants to use, and (2) by using a channel configuration via which users can configure multiple warning types.
By using the command options, UIs (like paperUI) will show a button for each configured warning type (see https://user-images.githubusercontent.com/1729268/36534983-7b7fcd22-17c8-11e8-8956-199fde552a22.png for how this would look like in paperUI).
I would implement this third (i.e., my favourite) option, but am also open for feedback here.