Lutron OH2 binding

Add-ons Bindings
,
183

Has anyone tried using this binding with a fan control switch? Specifically, I have an RRD-2ANF to go with a new ceiling fan, but I discovered that Lutron’s HomeKit integration doesn’t expose fan controllers (and no one else makes HomeKit-compatible fan controls, but there is a accessory type for it in the spec).

I have the binding up and running with my RA2 Select system (have to manually add everything, discovery isn’t working), but I don’t see that any of the supported thing types match the fan controller. Could I just call it a dimmer and confine it to four values, or maybe a SeeTouch? Note, I haven’t actually installed the switch or the fan yet, I’m just trying to confirm if what I want is even going to work.

184

Thanks for replying, David. I now have a caseta bridge and a handful of picos controlling my hue light groups reasonably well. One issue I’m still working on is that the key up events don’t seem to make it to the linked item when I hold a key down for more than about 8 seconds. If anyone is familiar with that behavior and knows a fix, please clue me in.

185

The Picos return a different code when a key is depressed for a longish period of time. Once they have timed out – as you noted, roughly eight seconds – and emitted that unique event, they will not emit a key released event when the key is actually released. I’ve thought about how that “long press release” code might be handled by the binding, but haven’t yet come up with a satisfactory idea.

186

That’s interesting. Exactly what codes are sent by Caseta when you press a Pico button and hold it? Does it first send “DEVICE,id,button,3” and then (after 8 seconds) something like “DEVICE,id,button,5”? And then nothing when it is released?

187

Correct, although the delay to the Hold report is about six seconds. Also, my controller is a RadioRA 2 Master Repeater, not a Caseta Pro Hub. After six seconds the repeater reports a Hold action (5) instead of a Release (4) when I press and hold a key on my Pico remote.

Here is what I see in the logs when I first “normal” press (press and release) each of the Pico PJ2-4B keys:

2019-01-07 10:44:12.589 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,8,3
2019-01-07 10:44:12.817 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,8,4
2019-01-07 10:44:16.630 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,9,3
2019-01-07 10:44:16.854 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,9,4
2019-01-07 10:44:21.554 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,10,3
2019-01-07 10:44:21.707 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,10,4
2019-01-07 10:44:30.005 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,11,3
2019-01-07 10:44:30.234 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,11,4

I then went through the same sequence of keys, from 1 to 4, but instead of “normal” presses, I held each key depressed for ~10 seconds:

2019-01-07 10:45:41.883 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,8,3
2019-01-07 10:45:47.891 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,8,5
2019-01-07 10:46:04.635 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,9,3
2019-01-07 10:46:10.639 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,9,5
2019-01-07 10:46:32.942 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,10,3
2019-01-07 10:46:38.947 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,10,5
2019-01-07 10:46:55.997 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,11,3
2019-01-07 10:47:02.006 [DEBUG][     Thread-203][ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,12,11,5
188

Sorry for the delay in replying, haven’t had a chance to look at this recently. Further investigation is revealing that this may be a false positive. It looks like there has been an issue introduced in the android app which is causing it to not update values as it once did.

For reference, debugs as you asked for:
2019-01-18 12:11:15.439 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message GNET> ~DEVICE,22,4,3
2019-01-18 12:11:15.440 [DEBUG] [ron.internal.handler.IPBridgeHandler] - No thing configured for integration ID 22
2019-01-18 12:11:15.664 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,22,4,4
2019-01-18 12:11:15.665 [DEBUG] [ron.internal.handler.IPBridgeHandler] - No thing configured for integration ID 22
2019-01-18 12:11:15.681 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,21,1,0.00

2019-01-18 12:10:38.650 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,22,2,3
2019-01-18 12:10:38.650 [DEBUG] [ron.internal.handler.IPBridgeHandler] - No thing configured for integration ID 22
2019-01-18 12:10:38.885 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,22,2,4
2019-01-18 12:10:38.885 [DEBUG] [ron.internal.handler.IPBridgeHandler] - No thing configured for integration ID 22
2019-01-18 12:10:38.901 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,21,1,100.00

189

I’m not entirely sure if this is possible, or how to do this, but I was hoping there is some way to restore state for my fan controls. I have the RA2 RRD-2ANF-WH fan controls in several rooms. Right now I just have them configured as dimmers because there isn’t a fan option. The fan controls report back their state as 0.00, 25.10, 50.20, 75.30, and 100.00 so I simply just set those values as necessary. The one gotcha is turning the fan on and it going back to the state it is set to last. For example, let’s assume the fan is set to setting 2 (50.20). If I walk up to the fan control and hit the off button it will turn the fan off but keep the 2nd led a little more lit than the others. When I hit the on button, it will go back to setting 2. If I however use sendCommand(ON), as expected this just gets 100 and the fan goes to full. I was hoping there would be some way that we can create something like sendCommand(RETURN) to put it back to what it was or something along those lines. Thoughts?

190

How is it handled for dimmable lights? Seems like the same issue presents. I’m still waiting on my electrician to install the fan and switch (today, maybe). My first thought it to use a dummy item that stores its state and refer to that to modify the ON command.

191

Dim-able lights just go to 100% if you send ON to it. They don’t maintain a previous on state while off like the fan controls do.

192

I have a fix which will resolve the immediate problem by issuing a release (i.e. updating the channel state to OFF) when a button hold message is received. This will prevent a button channel from becoming “stuck on” when a user holds a button on a keypad/system that supports hold actions, and when the autorelease parameter is off. The net effect should be that on these keypads/systems the binding will consider a held keypad button released after 6 seconds whether you have physically released it or not.

I’ve created issue #4982 on github to track this.

In the future, I’d like to improve the keypad handler so that it can send and receive hold and double-tap button actions as well as press and release, and also send and receive flash and rapid-flash LED actions. These are mostly not supported on RA2 systems, but are important on HWQS (which the binding at least nominally supports now) as well as some other Lutron systems. This will require adding some optional channels and/or channel types, though, so it will probably take a while.

193

The fix was merged in last night. It should be available in the next 2.5.0 development snapshot, or in the 2.5.0.M2 milestone build.

194

Unfortunately there is no Lutron integration protocol command that I know of to tell an output device to turn on to its last level. The fan controller may remember its last level, and a light dimmer will if you set the right option. But as far as I know, you can only make use of that by physically pressing the switch. A remote “on” command always requires that you supply a percentage.

However, you can probably make it do what you want most of the time by using some relatively simple rules. Just save the value for each 2ANF somewhere every time it updates, as long as it in non-zero. The only obvious hole I see would be if OpenHAB were to restart when a switch were off, it would lose the value. In that case, you would have to use a preset default, or maybe persist the value if you really care about it a lot.

That said, I’d be interested to know how well the RRD-2ANF is supported by the existing dimmer handler. Does auto-discovery work? What happens if you send the 2ANF a percentage that is not in the set {0.00, 25.10, 50.20, 75.30, 100.00}? Does it ignore or reject the command, round to the nearest supported value, or actually set the intermediate value (and fan speed)? Or does it cause some sort of problem? I can probably make a few tweaks for better support if necessary.

According to Lutron’s integration docs, the level parameter will set the fan sped on the RA2 or HWQS versions of the 2ANF as follows:

0 =  Off 
1–25% =  Low
26–50% =  Medium
56–75% =  Medium High
76–100% =  High

(It doesn’t say it in the docs, but I suspect it may ignore anything after the decimal point. At least some other RA2 devices do.)

If it does actually behave this way, continuing to use the dimmer handler to access it seems reasonable.

195

Hi,
Is everything in this thread actually in the 2.4 release?

First, the CCI isn’t working for me. Using the debug level messages it doesn’t seem to be receiving anything for CCI, so maybe my Radio Ra2 software is out of date. Is anyone actually using the CCI part of the VCRX support successfully? Could you tell me what version your Radio RA2 is at? I think basic VCRX support exists, since I got one of the buttons to work.

The other thing, I had noticed in 2.3 it would stop working after updating the RadioRa2 system from the software. Since upgrading to 2.4 we had a power failure, and the openhab stopped working after that (it’s running on Synology on a UPS). So I’m wondering if my 2.4 (standard install) has the improvements above.

Thanks for your work on this.

196

Hi Paul. The VCRX contact closure inputs should work in 2.4. CCI 1-4 should appear as components 30-33 on your VCRX device. It looks like the first two are security full/flash, and the second two are general inputs 1 and 2. If you set the logging level to TRACE for the Lutron binding and close VCRX Input 1, you should see log messages that are something like the following (assuming your VCRX integration ID is 5):

#DEVICE,5,32,3 (from the communications code)

then:

Handling command DEVICE 32,3 from keypad 5 (from the keypad handler)

If you don’t see messages like that, your main repeater isn’t sending a notification of the CCI being closed. If you do see messages like that, you need to look to see what messages immediately follow them in order to find out what is going on.

The connection management improvements are also in 2.4. However, I’ve recently seen some cases where 2.4 can still lose connection to the Lutron repeater without re-establishing it. So while it’s better than it was before, I suspect there is still a bug lurking in that code somewhere.

197

Bob,
I’m not receiving the messages so I don’t think the repeater is sending the codes. Another thing I noticed the integration report shows 31-34 for numbers, not 30-33 (calls them CCI6 through CCI9). I’m going to upgrade to 11.6 sometime, to get LED support also. The LED I see in the Lutron change log, but didn’t notice anything about CCI. You don’t know what Lutron version works with CCI? For whatever reason I got 10.something initially, even though I’m pretty sure at least 11.6 existed at the time.
Thanks,
Paul

198

Yes, I just checked and my integration report shows components 31-34 for the VCRX CCIs as well, although the latest revision of the Lutron Integration Protocol Guide (http://www.lutron.com/TechnicalDocumentLibrary/040249.pdf) p.136 says they should be numbered 30-33. I believe the Protocol Guide is correct, and the the integration report is wrong, because when I look at the DbXmlInfo.xml file from the main repeater, it also shows the CCI components as 30-33.

The bigger problem is that my Ra2 main repeater is not sending notifications when I press one of the CCI buttons either, although I do see notifications from it when I press one of the scene buttons. I am running 11.6.

I’ll have to play around with it a bit and see what is going on. It’s possible that the MONITORING setting on the repeater is filtering out those notifications. It’s also possible (thought less likely) that shorting the CCI contacts on the VCRX might trigger a notification while pressing the button does not.

199

I upgraded to 11.6 and got the button LED control to work, but the CCI is the same. I thought about the button vs. the contact also, and was using the button. The button does other actions (I have the CCI turning on a virtual switch to detect it in openhab for now), so agree it’s unlikely to just be a problem with the button. Maybe it’s an actual Lutron bug, though it could be fixed in 12.0 too. I’ll do that upgrade next.
Thanks,
Paul

200

I tried turning on nearly all MONITORING classes on the repeater, and I still don’t get any notifications about CCI state changes from the VCRX. I suspect it may be a Lutron bug. A search of their forums appears to indicate that it did work at one point. I’d be interested to hear if upgrading to 12.0 helps.

201

It does work with the real CCI but not using the button. Then you can’t really test it with the button. I’d still call it a bug. Still on 11.6 I tried triggering the CCI, and followed that with the button for the CCI. Here is what I got:
2019-04-19 12:09:38.474 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,73,32,3
2019-04-19 12:09:38.517 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,79,1,100.00
2019-04-19 12:09:38.536 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,79,29,0
2019-04-19 12:09:38.553 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,79,30,1,100.00
2019-04-19 12:09:41.996 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,73,32,4
2019-04-19 12:09:42.032 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,79,1,0.00
2019-04-19 12:09:42.048 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,79,29,0
2019-04-19 12:09:42.061 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,79,30,1,0.00
2019-04-19 12:11:49.816 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,79,1,100.00
2019-04-19 12:11:49.833 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,79,29,0
2019-04-19 12:11:49.851 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,79,30,1,100.00
2019-04-19 12:11:55.954 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,79,1,0.00
2019-04-19 12:11:55.967 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,79,29,0
2019-04-19 12:11:55.983 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,79,30,1,0.00

Device 73 is my VCRX and 79 is the virtual switch I have turned on/off by the CCI in the repeater programming. At 12:09 I triggered the CCI and at 12:11 I pushed the CCI button on the VCRX.

202

It doesn’t look like my CCI item gets any status though. Can you try testing it using the actual CCI input of your VCRX?
Thanks,
Paul