public/openhab-addons
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[lutron] Add LEAP protocol support (#8650)

Browse Source 
* [lutron] Add LEAP protocol support

Signed-off-by: Bob Adair <bob.github@att.net>
This commit is contained in:
Bob A
2020-10-15 18:59:24 -04:00
committed by GitHub
parent 25826854b4
commit 6f659f2308
65 changed files with 4313 additions and 352 deletions
Download Patch File Download Diff File Expand all files Collapse all files

207
bundles/org.openhab.binding.lutron/README.md
View File

@@ -3,31 +3,32 @@
This binding integrates with [Lutron](http://www.lutron.com) lighting control and home automation systems.
It contains separate binding support for four different types of Lutron systems:
* RadioRA 2, HomeWorks QS, and other systems that can be controlled by Lutron Integration Protocol, such as RA2 Select, and Caseta Pro
* RadioRA 2, HomeWorks QS, and other systems that can be controlled by Lutron Integration Protocol (LIP) or LEAP, such as RA2 Select, and Caseta
* The original RadioRA system, referred to here as RadioRA Classic
* Legacy HomeWorks RS232 Processors
* Grafik Eye 3x/4x systems with GRX-PRG or GRX-CI-PRG control interfaces
Each is described in a separate section below.
# Lutron RadioRA 2/HomeWorks QS Binding
# Lutron RadioRA 2/HomeWorks QS/Caseta Binding
**Note:** While the integration protocol used by this binding should largely be compatible with other current Lutron systems, this binding has only been fully tested with RadioRA 2, HomeWorks QS, and Caseta with Smart Bridge Pro.
**Note:** While the Lutron Integration Protocol used by this binding should largely be compatible with other current Lutron systems, this binding has only been fully tested with RadioRA 2, HomeWorks QS, and Caseta with Smart Bridge Pro.
Homeworks QS support is still a work in progress, since not all features/devices are supported yet.
RA2 Select systems have been reported to work with the binding, but full support is still unconfirmed.
The binding has not been tested with Quantum, QS Standalone, or myRoom Plus systems.
**Note:** Caseta support is only possible with the Smart Bridge **Pro** hub.
The standard Caseta hub does not support Lutron Integration Protocol.
RA2 Select systems work with the binding, but full support for all devices still needs to be confirmed.
Caseta Smart Bridge (non-Pro model) support and support for Caseta occupancy sensors is available only through the experimental leapbridge thing.
The binding has not been tested with Quantum, QS Standalone, myRoom Plus, or Athena systems.
## Supported Things
This binding currently supports the following thing types:
* **ipbridge** - The Lutron main repeater/processor/hub
* **dimmer** - Dimmer or fan controller
* **leapbridge** - Experimental bridge that uses LEAP protocol (Caseta & RA2 Select only)
* **dimmer** - Light dimmer
* **switch** - Switch or relay module
* **fan** - Fan controller
* **occupancysensor** - Occupancy/vacancy sensor
* **ogroup** - Occupancy group
* **keypad** - Lutron seeTouch or Hybrid seeTouch Keypad
* **ttkeypad** - Tabletop seeTouch Keypad
* **intlkeypad** - International seeTouch Keypad (HomeWorks QS only)
@@ -53,8 +54,8 @@ Discovered repeaters/processors will be accessed using the default integration c
These can be changed in the bridge thing configuration.
Discovered keypad devices should now have their model parameters automatically set to the correct value.
Caseta Smart Bridge PRO 2 hubs and RA2 Select main repeaters should now be discovered automatically via mDNS.
Devices attached to them still need to be configured manually.
Caseta Smart Bridge hubs, Smart Bridge Pro 2 hubs, and RA2 Select main repeaters should now be discovered automatically via mDNS.
Devices attached to them still need to be configured manually unless the experimental leapbridge is used.
Other supported Lutron systems must be configured manually.
@@ -68,11 +69,42 @@ Each Lutron thing requires the integration ID of the corresponding item in the L
The integration IDs can be retrieved from the integration report generated by the Lutron software.
If a thing will not come online, but instead has the status "UNKNOWN: Awaiting initial response", it is likely that you have configured the wrong integration ID for it.
### Bridge
### Bridges
A bridge may currently be a RadioRA 2 main repeater, a HomeWorks QS Processor, a Caseta Smart Bridge Pro, or a RA2 Select main repeater.
The bridge configuration requires the IP address of the bridge as well as the telnet username and password to log in to the bridge.
Two different bridges are now supported by the binding, ipbridge and leapbridge.
The LIP protocol is supported by ipbridge while the LEAP protocol is supported by leapbridge.
Current Lutron systems support one or both protocols as shown below.
|Bridge Device | LIP | LEAP |
|------------------------|-----|------|
|HomeWorks QS Processor | X | |
|RadioRA 2 Main Repeater | X | |
|RA2 Select Main Repeater| X | X |
|Caseta Smart Bridge Pro | X | X |
|Caseta Smart Bridge | | X |
If your system supports only one protocol, then the choice of bridge is easy.
If you have a system that supports both protocols, you must decide which you wish to use.
You should be aware of the following functional differences between the protocols:
* Using LIP on Caseta you can’t receive notifications of occupancy group status changes (occupied/unoccupied/unknown), but using LEAP you can.
* Conversely, LIP provides notifications of keypad key presses, while LEAP does not (as far as is currently known).
This means that using ipbridge you can trigger rules and take actions on keypad key presses/releases, but using leapbridge you can’t.
* Caseta and RA2 Select device discovery is supported via LEAP, but not via LIP.
* The leapbridge is a bit more complicated to configure because LEAP uses an SSL connections and authenticates using certificates.
* LIP is a publicly documented protocol, while LEAP is not. This means that Lutron could make a change that breaks LEAP support at any time.
It is possible to run leapbridge and ipbridge at the same time, for the same bridge device, but each managed device (e.g. keypad or dimmer) should only be configured through *one* bridge.
Remember that LEAP device IDs and LIP integration IDs are not necessarily equal!
#### ipbridge
This is the standard bridge which should be used with most Lutron systems.
It relies on Lutron Integration Protocol (LIP) over TCP/IP to communicate with the target device.
It can currently be used with a RadioRA 2 main repeater, a HomeWorks QS Processor, a Caseta Smart Bridge Pro, or a RA2 Select main repeater.
The ipbridge configuration requires the IP address of the bridge as well as the telnet username and password to log in to the bridge.
It is recommended that main repeaters/processors be configured with static IP addresses.
However if automatic discovery is used, the bridge thing will work with DHCP-configured addresses.
@@ -102,7 +134,45 @@ Bridge lutron:ipbridge:radiora2 [ ipAddress="192.168.1.2", user="lutron", passwo
}
```
### Dimmers
#### leapbridge [**experimental**]
The leapbridge is an experimental bridge which allows the binding to work with the Caseta Smart Hub (non-Pro version).
It can also be used to provide additional features, such as support for occupancy groups and device discovery, when used with Caseta Smart Hub Pro or RA2 Select.
It uses the LEAP protocol over SSL, which is an undocumented protocol supported by some of Lutron's newer systems.
Note that the LEAP protocol will not notify the bridge of keypad key presses.
If you need this useful feature, you should use ipbridge instead.
You can use both ipbridge and leapbridge at the same time, but each device should only be configured through one bridge.
You should also be aware that LEAP and LIP integration IDs for the same device can be different.
For instructions on configuring authentication for leapbridge, see the [Leap Notes](doc/leapnotes.md) document.
The `ipAddress`, `keystore` and `keystorePassword` parameters must be set.
The optional `port` parameter defaults to 8081 and should not normally need to be changed.
The optional parameter `certValidate` defaults to true. It should be set to false only if validation of the hub's server certificate is failing, possibly because the hostname you are using for it does not match its internal hostname.
If this happens, the leapbridge status will be: "OFFLINE - COMMUNICATION_ERROR - Error opening SSL connection", and a message like the following may be logged:
```Error opening SSL connection: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target```.
The optional advanced parameter `heartbeat` can be used to set the interval between connection keepalive heartbeat messages, in minutes.
It defaults to 5.
Note that the handler will wait up to 30 seconds for a heartbeat response before attempting to reconnect.
The optional advanced parameter `reconnect` can be used to set the connection retry interval, in minutes.
It also defaults to 5.
The optional advanced parameter `delay` can be used to set a delay (in milliseconds) between transmission of LEAP commands to the bridge device.
It should not normally need to be changed.
Thing configuration file example:
```
Bridge lutron:leapbridge:caseta [ ipAddress="192.168.1.3", keystore="/home/openhab/lutron.keystore", keystorePassword="secret" ] {
Thing ...
Thing ...
}
```
### Devices
#### Dimmers
Dimmers can optionally be configured to specify a default fade in and fade out time in seconds using the `fadeInTime` and `fadeOutTime` parameters.
These are used for ON and OFF commands, respectively, and default to 1 second if not set.
@@ -116,6 +186,7 @@ If set to "true", the dimmer will go to its last non-zero level when sent an ON
If the last non-zero level cannot be determined, the value of `onLevel` will be used instead.
A **dimmer** thing has a single channel *lightlevel* with type Dimmer and category DimmableLight.
The **dimmer** thing was previously also used to control fan speed controllers, but now you should use the **fan** thing instead.
Thing configuration file example:
@@ -136,7 +207,7 @@ Times of 100 seconds or more will be rounded to the nearest integer value.
See below for an example rule using thing actions.
### Switches
#### Switches
Switches take no additional parameters besides `integrationId`.
A **switch** thing has a single channel *switchstatus* with type Switch and category Switch.
@@ -147,9 +218,24 @@ Thing configuration file example:
Thing switch porch [ integrationId=8 ]
```
### Occupancy Sensors
#### Fans
Fan speed controllers are interfaced with using the **fan** thing.
It accepts no additional parameters besides `integrationId`.
A **fan** thing has two channels, *fanspeed* and *fanlevel*.
Thing configuration file example:
```
Thing fan porchfan [ integrationId=12 ]
```
#### Occupancy Sensors
An **occupancysensor** thing interfaces to Lutron Radio Powr Savr wireless occupancy/vacancy sensors on RadioRA 2 and HomeWorks QS systems.
On these systems, you should generally choose to interface to either an occupancy group or individual occupancy sensors for a given area.
For Caseta Smart Motion Sensors, you must use the **group** thing instead.
An **occupancysensor** thing interfaces to Lutron Radio Powr Savr wireless occupancy/vacancy sensors.
It accepts no configuration parameters other than `integrationId`.
The binding creates one *occupancystatus* channel, Item type Switch, category Motion.
@@ -163,7 +249,23 @@ Thing configuration file example:
Thing occupancysensor shopsensor [ integrationId=7 ]
```
### seeTouch and Hybrid seeTouch Keypads
#### Occupancy Groups
A **ogroup** thing interfaces to an occupancy group, which shows occcupancy/vacancy status for an area or room with one or more occupancy sensors.
On RadioRA2 and HomeWorks QS systems, you should generally choose to interface to either an occupancy group or individual occupancy sensors for a given area.
On Caseta systems, you cannot interface to individual sensors and must use the *ogroup* thing.
The `integrationId` parameter must be set to the occupancy group ID.
The binding creates one read-only *groupstate* channel, item type String, category Motion.
The value can be "OCCUPIED", "UNOCCUPIED", or "UNKNOWN".
Thing configuration file example:
```
Thing ogroup lrgroup [ integrationId=7 ]
```
#### seeTouch and Hybrid seeTouch Keypads
seeTouch and Hybrid seeTouch keypads are interfaced with using the **keypad** thing.
In addition to the usual `integrationId` parameter, it accepts `model` and `autorelease` parameters.
@@ -191,7 +293,8 @@ Ditto for the indicator LED channels.
Note, however, that version 11.6 or higher of the RadioRA 2 software may be required in order to drive keypad LED states, and then this may only be done on unbound buttons.
Component numbering: For button and LED layouts and numbering, see the Lutron Integration Protocol Guide (rev. AA) p.104 (https://www.lutron.com/TechnicalDocumentLibrary/040249.pdf).
If you are having problems determining which channels have been created for a given keypad model, click on the thing under Configuration/Things in the Paper UI, or run the command `things show <thingUID>` (e.g. `things show lutron:keypad:radiora2:entrykeypad`) from the openHAB CLI to list the channels.
If you are having problems determining which channels have been created for a given keypad model, select the appropriate keypad thing under Settings/Things in the Administration UI and click on the Channels tab.
You can also run the command `things show <thingUID>` (e.g. `things show lutron:keypad:radiora2:entrykeypad`) from the openHAB CLI to list the channels.
Supported settings for `model` parameter: H1RLD, H2RLD, H3BSRL, H3S, H4S, H5BRL, H6BRL, HN1RLD, HN2RLD, HN3S, HN3BSRL, HN4S, HN5BRL, HN6BRL, W1RLD, W2RLD, W3BD, W3BRL, W3BSRL, W3S, W4S, W5BRL, W5BRLIR, W6BRL, W7B, Generic (default)
@@ -212,14 +315,16 @@ then
end
```
### Tabletop seeTouch Keypads
#### Tabletop seeTouch Keypads
Tabletop seeTouch keypads use the **ttkeypad** thing.
It accepts the same `integrationId`, `model`, and `autorelease` parameters and creates the same channel types as the **keypad** thing.
See the **keypad** section above for a full discussion of configuration and use.
Component numbering: For button and LED layouts and numbering, see the Lutron Integration Protocol Guide (rev. AA) p.110 (https://www.lutron.com/TechnicalDocumentLibrary/040249.pdf).
If you are having problems determining which channels have been created for a given keypad model, click on the thing under Configuration/Things in the Paper UI, or run the command `things show <thingUID>` (e.g. `things show lutron:ttkeypad:radiora2:bedroomkeypad`) from the openHAB CLI to list the channels.
If you are having problems determining which channels have been created for a given keypad model, select the appropriate ttkeypad thing under Settings/Things in the Administration UI and click on the Channels tab.
You can also run the command `things show <thingUID>` (e.g. `things show lutron:ttkeypad:radiora2:bedroomkeypad`) from the openHAB CLI to list the channels.
Supported settings for `model` parameter: T5RL, T10RL, T15RL, T5CRL, T10CRL, T15CRL, Generic (default)
@@ -229,18 +334,19 @@ Thing configuration file example:
Thing ttkeypad bedroomkeypad [ integrationId=11, model="T10RL" autorelease=true ]
```
### International seeTouch Keypads (HomeWorks QS)
#### International seeTouch Keypads (HomeWorks QS)
International seeTouch keypads used in the HomeWorks QS system use the **intlkeypad** thing.
It accepts the same `integrationId`, `model`, and `autorelease` parameters and creates the same button and LED channel types as the **keypad** thing.
See the **keypad** section above for a full discussion of configuration and use.
To support this keypad's contact closure inputs, CCI channels named *cci1* and *cci2* are created with item type Contact and category Switch.
They are marked as Advanced, so they will not be automatically linked to items in the Paper UI's Simple Mode.
They are marked as Advanced, so you will need to check "Show advanced" in order to see them listed in the Administration UI.
They present ON/OFF states the same as a keypad button.
Component numbering: For button and LED layouts and numbering, see the Lutron Integration Protocol Guide (rev. AA) p.107 (https://www.lutron.com/TechnicalDocumentLibrary/040249.pdf).
If you are having problems determining which channels have been created for a given keypad model, click on the thing under Configuration/Things in the Paper UI, or run the command `things show <thingUID>` (e.g. `things show lutron:intlkeypad:hwprocessor:kitchenkeypad`) from the openHAB CLI to list the channels.
If you are having problems determining which channels have been created for a given keypad model, select the appropriate intlkeypad thing under Settings/Things in the Administration UI and click on the Channels tab.
You can also run the command `things show <thingUID>` (e.g. `things show lutron:intlkeypad:hwprocessor:kitchenkeypad`) from the openHAB CLI to list the channels.
Supported settings for `model` parameter: 2B, 3B, 4B, 5BRL, 6BRL, 7BRL, 8BRL, 10BRL / Generic (default)
@@ -250,14 +356,15 @@ Thing configuration file example:
Thing intlkeypad kitchenkeypad [ integrationId=15, model="10BRL" autorelease=true ]
```
### Palladiom Keypads (HomeWorks QS)
#### Palladiom Keypads (HomeWorks QS)
Palladiom keypads used in the HomeWorks QS system use the **palladiomkeypad** thing.
It accepts the same `integrationId`, `model`, and `autorelease` parameters and creates the same button and LED channel types as the **keypad** thing.
See the **keypad** section above for a full discussion of configuration and use.
Component numbering: For button and LED layouts and numbering, see the Lutron Integration Protocol Guide (rev. AA) p.95 (https://www.lutron.com/TechnicalDocumentLibrary/040249.pdf).
If you are having problems determining which channels have been created for a given keypad model, click on the thing under Configuration/Things in the Paper UI, or run the command `things show <thingUID>` (e.g. `things show lutron:palladiomkeypad:hwprocessor:kitchenkeypad`) from the openHAB CLI to list the channels.
If you are having problems determining which channels have been created for a given keypad model, select the appropriate palladiomkeypad thing under Settings/Things in the Administration UI and click on the Channels tab.
You can also run the command `things show <thingUID>` (e.g. `things show lutron:palladiomkeypad:hwprocessor:kitchenkeypad`) from the openHAB CLI to list the channels.
Supported settings for `model` parameter: 2W, 3W, 4W, RW, 22W, 24W, 42W, 44W, 2RW, 4RW, RRW
@@ -268,7 +375,7 @@ Thing palladiomkeypad kitchenkeypad [ integrationId=16, model="4W" autorelease=t
```
### Pico Keypads
#### Pico Keypads
Pico keypads use the **pico** thing.
It accepts the same `integrationId`, `model`, and `autorelease` parameters and creates the same channel types as the **keypad** and **ttkeypad** things.
@@ -276,7 +383,8 @@ The only difference is that no LED channels will be created, since Pico keypads
See the discussion above for a full discussion of configuration and use.
Component numbering: For button layouts and numbering, see the Lutron Integration Protocol Guide (rev. AA) p.113 (https://www.lutron.com/TechnicalDocumentLibrary/040249.pdf).
If you are having problems determining which channels have been created for a given keypad model, click on the thing under Configuration/Things in the Paper UI, or run the command `things show <thingUID>` (e.g. `things show lutron:pico:radiora2:hallpico`) from the openHAB CLI to list the channels.
If you are having problems determining which channels have been created for a given keypad model, select the appropriate pico thing under Settings/Things in the Administration UI and click on the Channels tab.
You can also run the command `things show <thingUID>` (e.g. `things show lutron:pico:radiora2:hallpico`) from the openHAB CLI to list the channels.
Supported settings for `model` parameter: 2B, 2BRL, 3B, 3BRL, 4B, Generic (default)
@@ -286,7 +394,7 @@ Thing configuration file example:
Thing pico hallpico [ integrationId=12, model="3BRL", autorelease=true ]
```
### GRAFIK Eye QS Keypads (in RadioRA 2/HomeWorks QS systems)
#### GRAFIK Eye QS Keypads (in RadioRA 2/HomeWorks QS systems)
GRAFIK Eye devices can contain up to 6 lighting dimmers, a scene controller, a time clock, and a front panel with a column of 5 programmable scene buttons and 0 to 3 columns of programmable shade or lighting control buttons.
They can be used as peripheral devices in a RadioRA 2 or HomeWorks QS system, or can be used as stand-alone controllers that themselves can control other Lutron devices.
@@ -301,11 +409,12 @@ The model parameter should be set to indicate whether there are zero, one, two,
Note that this count does not include the column of 5 scene buttons always found on the right side of the panel.
To support the GRAFIK Eye's contact closure input, a CCI channel named *cci1* will be created with item type Contact and category Switch.
It is marked as Advanced, so it will not be automatically linked to items in the Paper UI's Simple Mode.
It is marked as Advanced, so you will need to check "Show advanced" in order to see it listed in the Administration UI.
It presents ON/OFF states the same as a keypad button.
Component numbering: The buttons and LEDs on the GRAFIK Eye are numbered top to bottom, starting with the 5 scene buttons in a column on the right side of the panel, and then proceeding with the columns of buttons (if any) on the left side of the panel, working left to right.
If you are having problems determining which channels have been created for a given model setting, click on the thing under Configuration/Things in the Paper UI, or run the command `things show <thingUID>` (e.g. `things show lutron:grafikeyekeypad:radiora2:theaterkeypad`) from the openHAB CLI to list the channels.
If you are having problems determining which channels have been created for a given model setting, select the appropriate grafikeyekeypad thing under Settings/Things in the Administration UI and click on the Channels tab.
You can also run the command `things show <thingUID>` (e.g. `things show lutron:grafikeyekeypad:radiora2:theaterkeypad`) from the openHAB CLI to list the channels.
Supported settings for `model` parameter: 0COL, 1COL, 2COL, 3COL (default)
@@ -315,7 +424,7 @@ Thing configuration file example:
Thing lutron:grafikeyekeypad:theaterkeypad (lutron:ipbridge:radiora2) [ integrationId=12, model="3COL", autorelease="true" ]
```
### Virtual Keypads
#### Virtual Keypads
The **virtualkeypad** thing is used to interface to the virtual buttons on the RadioRA 2 main repeater or HomeWorks processor.
These are sometimes referred to in the Lutron documentation as phantom buttons or integration buttons, and are used only for integration.
@@ -327,7 +436,7 @@ For this to work, the optional `model` parameter must be set to `Caseta`.
When used with Caseta, no virtual indicator LED channels are created.
The behavior of this binding is the same as the other keypad bindings, with the exception that the button and LED channels created have the Advanced flag set.
This means, among other things, that they will not be automatically linked to items in the Paper UI's Simple Mode.
This means, among other things, that you will need to check "Show advanced" in order to see them listed in the Administration UI.
In most cases the integrationId parameter should be set to 1.
@@ -339,7 +448,7 @@ Thing configuration file example:
Thing virtualkeypad repeaterbuttons [ integrationId=1, autorelease=true ]
```
### VCRX Modules
#### VCRX Modules
The Lutron VCRX appears to openHAB as multiple devices.
The 6 buttons (which can be activated remotely by HomeLink remote controls), 6 corresponding LEDs, and 4 contact closure inputs (CCIs) are handled by the **vcrx** thing, which behaves like a keypad.
@@ -350,7 +459,7 @@ Supplying a model is not required, as there is only one model.
To support the contact closure inputs, CCI channels named *cci[n]* are created with item type Contact and category Switch.
The VCRX security (Full/Flash) input controls both the cci1 and cci2 channels, while input connections 1 and 2 map to the cci3 and cci4 channels respectively.
The cci channels are marked as Advanced, so they will not be automatically linked to items in the Paper UI's Simple Mode.
The cci channels are marked as Advanced, so you will need to check "Show advanced" in order to see them listed in the Administration UI.
They present OPEN/CLOSED states but do not accept commands since Contact items are read-only in openHAB.
Note that the `autorelease` option **does not** apply to CCI channels.
@@ -360,7 +469,7 @@ Thing configuration file example:
Thing vcrx vcrx1 [ integrationId=13, autorelease=true ]
```
### QS IO Interface (HomeWorks QS)
#### QS IO Interface (HomeWorks QS)
The Lutron QS IO Interface (QSE-IO) appears to openHAB as multiple devices.
The 5 contact closure inputs (CCIs) are handled by the **qsio** thing.
@@ -368,7 +477,7 @@ The 5 contact closure outputs (CCOs) are handled by the **cco** thing (see below
The only configuration option is `integrationId`
To support the contact closure inputs, CCI channels named *cci[n]* are created with item type Contact and category Switch.
They are marked as Advanced, so they will not be automatically linked to items in the Paper UI's Simple Mode.
They are marked as Advanced, so you will need to check "Show advanced" in order to see them listed in the Administration UI.
They present OPEN/CLOSED states but do not accept commands as Contact items are read-only in openHAB.
Some functionality may depend on QSE-IO DIP switch settings. See the Lutron documentation for more information.
@@ -379,7 +488,7 @@ Thing configuration file example:
Thing qsio sensorinputs [ integrationId=42 ]
```
### QS Wallbox Closure Interface (WCI) (HomeWorks QS only)
#### QS Wallbox Closure Interface (WCI) (HomeWorks QS only)
The Lutron Wallbox Closure Interface (QSE-CI-WCI) is used to interface to contact closure keypads.
It is handled by the **wci** thing.
@@ -397,7 +506,7 @@ Thing configuration file example:
Thing wci specialkeypad [ integrationId=48, autorelease=true ]
```
### CCO Modules
#### CCO Modules
Contact closure output (**cco**) things accept `outputType` and `pulseLength` parameters.
The `outputType` parameter is a string that should be set to "Pulsed" for pulsed CCOs or "Maintained" for non-pulsed CCOs.
@@ -424,7 +533,7 @@ Thing cco garage [ integrationId=5, outputType="Pulsed", pulseLength=0.5 ]
Thing cco relay1 [ integrationId=7, outputType="Maintained"]
```
### Shades
#### Shades
Each Lutron shade, motorized drape, or QS motor controller output (LQSE-4M-D) is controlled by a **shade** thing.
The only configuration parameter it accepts is `integrationId`.
@@ -449,7 +558,7 @@ Thing configuration file example:
Thing shade libraryshade [ integrationId=33]
```
### Blinds [**Experimental**]
#### Blinds [**Experimental**]
Each Lutron Sivoia QS Venetian Blind or Horizontal Sheer Blind is controlled by a **blind** thing.
Besides `integrationId`, it requires that the parameter `type` be set to either "Venetian" for venetian blinds or "Sheer" for horizontal sheer blinds.
@@ -475,7 +584,7 @@ Thing configuration file example:
Thing blind officeblinds [ integrationId=76, type="Venetian"]
```
### Green Mode
#### Green Mode
Radio RA2 and HomeWorks QS systems have a "Green Mode" or "Green Button" feature which allows the system to be placed in to one or more user-defined power saving modes called "steps".
Each step can take actions such as trimming down the 100% level on selected lighting dimmers by a specified percentage, shutting off certain loads, modifying thermostat settings, etc.
@@ -501,7 +610,7 @@ Thing configuration file example:
Thing greenmode greenmode [ integrationId=22 ]
```
### Timeclock
#### Timeclock
RadioRA 2 and Homeworks QS have timeclock subsystems that provide scheduled execution of tasks at set times, randomized times or at arbitrary offsets from local sunrise/sunset.
The tasks executed depend on the currently selected timeclock mode (e.g. Normal, Away, Suspend) and the modes themselves are user-definable (RadioRA 2 only).
@@ -545,7 +654,7 @@ then
end
```
### System State Variables (HomeWorks QS only) [**Experimental**]
#### System State Variables (HomeWorks QS only) [**Experimental**]
HomeWorks QS systems allow for conditional programming logic based on state variables.
The **sysvar** thing allows state variable values to be read and set from openHAB.
@@ -569,7 +678,10 @@ The following is a summary of channels for all RadioRA 2 binding things:
|---------------------|-------------------|---------------|--------------------------------------------- |
| dimmer | lightlevel | Dimmer | Increase/decrease the light level |
| switch | switchstatus | Switch | On/off status of the switch |
| occupancysensor | occupancystatus | Switch | Occupancy status |
| fan | fanspeed | String | Set/get fan speed using string options |
| fan | fanlevel | Dimmer | Set/get fan speed using a dimmer channel |
| occupancysensor | occupancystatus | Switch | Occupancy sensor status |
| ogroup | groupstate | String | Occupancy group status |
| cco | switchstatus | Switch | On/off status of the CCO |
| keypads (all) | button* | Switch | Keypad button |
| keypads(except pico)| led* | Switch | LED indicator for the associated button |
@@ -595,7 +707,10 @@ Appropriate channels will be created automatically by the keypad, ttkeypad, intl
|-----------|---------------|--------------|-------------------------------------------------------|
|dimmer |lightlevel |PercentType |OnOffType, PercentType (rounded/truncated to integer) |
|switch |switchstatus |OnOffType |OnOffType |
|fan |fanspeed |StringType |"OFF","LOW","MEDIUM","MEDIUMHIGH","HIGH" |
|fan |fanlevel |PercentType |OnOffType, PercentType |
|occ. sensor|occupancystatus|OnOffType |(*readonly*) |
|ogroup |groupstate |StringType |"OCCUPIED","UNOCCUPIED","UNKNOWN" (*readonly*) |
|cco |switchstatus |OnOffType |OnOffType, RefreshType |
|keypads |button* |OnOffType |OnOffType |
| |led* |OnOffType |OnOffType, RefreshType |