Lutron VCRX cci1 always NULL

Add-ons Bindings
, ,
1

I’m trying to monitor events for a garage door cci but the Lutron binding doesn’t appear to getting or possibly using the events.

I have a VCRX (integration id 34) that was auto-discovered and I enabled the cci1 channel and created a Contact item.

Contact F1_GarageDoor_cci1 “Garage Door 1 Status” (F1_Garage, gGarageDoor, gDEBUG) {channel=“lutron:vcrx:00748D3A:34:cci1”}

I can move the garage door up/down and see the LED for cci1 turn off/on so I know the vcrx is reading the physical contact.

From the console, I can see the state is always NULL no matter how many times I move the garage door and see the cci LED change.

openhab> smarthome:items list F1_GarageDoor_cci1
F1_GarageDoor_cci1 (Type=ContactItem, State=NULL, Label=Garage Door 1 Status, Category=garagedoor, Groups=[F1_Garage, gGarageDoor, gDEBUG])

If I telnet into the RA2, I can see that the cci device is enabled. And if I move the garage door I can see the monitor events come across in the session.

GNET> ?help,?device,1
~HELP,
?DEVICE,<state=1> device state
RESPONSE: ~DEVICE,,0,<1=Enable/disable state>,
FORMAT: state = (1=enabled,2=disabled)

GNET> ?device,34,32,1
~DEVICE,34,00000,1,1

GNET> ~DEVICE,34,32,4
~DEVICE,34,32,3

I don’t see anything in the logs showing the state change for the cci.

From researching this, it appears that the cci state can’t be read directly but can only be captured from a monitoring event being reported which I understand is different from most of the Lutron devices.

What am I missing?

  • Platform information:
    • Hardware: x86_64
    • OS: Ubuntu 18.04
    • Java Runtime Environment: openjdk version “1.8.0_232”
    • openHAB version: 2.5.0-1
2

That’s strange. If you look in the events.log file, do you see any state changes for the CCI item(s)?
I’d recommend setting the logging level for the lutron binding (org.openhab.binding.lutron) to TRACE, and seeing what is logged when the CCI is opened/closed.

Yes, that’s my understanding too. The CCIs look more or less like keypad buttons to the system, which can’t be queried. So when the binding (or more specifically the VCRX thing handler) first starts, the state of the channels for those CCIs will be undefined. But after the first state change, you should be seeing valid values for them.

3

One other thing… I just noticed that in the output from your telnet session, the component that is updating is 32. That is cci3, not cci1. Here are the definitions from the thing handler code:

        CCI1(30, "cci1", "CCI 1", ComponentType.CCI),
        CCI2(31, "cci2", "CCI 2", ComponentType.CCI),
        CCI3(32, "cci3", "CCI 3", ComponentType.CCI),
        CCI4(33, "cci4", "CCI 4", ComponentType.CCI),
4

I put the Lutron binding in trace mode and moved the door and the following showed up in the openhab.log for the cci but nothing in the events.log file.

2020-01-19 14:18:05.107 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,34,32,4
2020-01-19 14:18:05.108 [TRACE] [n.internal.handler.BaseKeypadHandler] - Handling command DEVICE [32, 4] from keypad 34
2020-01-19 14:18:17.942 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,34,32,3
2020-01-19 14:18:17.943 [TRACE] [n.internal.handler.BaseKeypadHandler] - Handling command DEVICE [32, 3] from keypad 34

I checked the latest Lutron Integration Protocol Guide and page 137 has Input 1 as component 32 and not 30 as your code shows. I don’t know if this was changed by Lutron at some point. Your component numbers make much more logical sense. J

To test this a bit more, I changed the Contact item to reference cci3 instead of cci1, moved the door, and got the following in the openhab.log file.

2020-01-19 14:39:59.910 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,34,32,4
2020-01-19 14:39:59.910 [TRACE] [n.internal.handler.BaseKeypadHandler] - Handling command DEVICE [32, 4] from keypad 34
2020-01-19 14:39:59.990 [INFO ] [clipse.smarthome.model.script.Scenes] - F1_GarageDoor_cci1 state was: NULL
2020-01-19 14:39:59.991 [INFO ] [clipse.smarthome.model.script.Scenes] - F1_GarageDoor_cci1 state changed to: OPEN
2020-01-19 14:40:08.903 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,34,32,3
2020-01-19 14:40:08.903 [TRACE] [n.internal.handler.BaseKeypadHandler] - Handling command DEVICE [32, 3] from keypad 34
2020-01-19 14:40:08.905 [INFO ] [clipse.smarthome.model.script.Scenes] - F1_GarageDoor_cci1 state was: OPEN
2020-01-19 14:40:08.905 [INFO ] [clipse.smarthome.model.script.Scenes] - F1_GarageDoor_cci1 state changed to: CLOSED

So from this, I have a work around but it appears that the bindings cci component numbers don’t match the current protocol documentation. I am running v12.0 on my RA2 and using the same version level of Elements software to configure the Lutron devices.

5

It’s been a while since I wrote that code, but I seem to remember the component numbers in the protocol guide not matching the component numbers on my own VCRX unit when I was testing it.

The configuration xml file from my system (running 11.6 of the RA2 software) says my VCRX CCI component numbers are 30-33, so I suspect the integration protocol guide is wrong.

-<Device UUID="4490" Name="Device 001" SortOrder="0" IntegrationID="34" GangPosition="0" DeviceType="VISOR_CONTROL_RECEIVER" SerialNumber="">
  -<Components>
    +<Component ComponentType="BUTTON" ComponentNumber="1">
    +<Component ComponentType="BUTTON" ComponentNumber="2">
    +<Component ComponentType="BUTTON" ComponentNumber="3">
    +<Component ComponentType="BUTTON" ComponentNumber="4">
    +<Component ComponentType="BUTTON" ComponentNumber="5">
    +<Component ComponentType="BUTTON" ComponentNumber="6">
    +<Component ComponentType="CCI" ComponentNumber="30">
    +<Component ComponentType="CCI" ComponentNumber="31">
    +<Component ComponentType="CCI" ComponentNumber="32">
    +<Component ComponentType="CCI" ComponentNumber="33">
    +<Component ComponentType="LED" ComponentNumber="81">
    +<Component ComponentType="LED" ComponentNumber="82">
    +<Component ComponentType="LED" ComponentNumber="83">
    +<Component ComponentType="LED" ComponentNumber="84">
    +<Component ComponentType="LED" ComponentNumber="85">
    +<Component ComponentType="LED" ComponentNumber="86">
  </Components>
</Device>

Do you see different component numbers on your system?

6

I think it’s more likely that the component numbers were changed from 11.x to 12.0+.

I’m using cci1 and cci2 and they’re showing up in the monitoring output as component 32 and 33 respectively which matches the current protocol docs.

I’m also using cco1 and cco2 and they work as expected.

7

I’d appreciate it if you could send me a copy of the DbXmlInfo.xml file from your main repeater. You can retrieve it from the repeater using the URL http://<repeater IP>/DbXmlInfo.xml . If it won’t fit in a private message, I can send you my email address so that you can send it directly as an attachment.

Also, if you have a chance to trigger the other two CCI inputs and see what messages the repeater outputs, that would be helpful as well. If there really is some variation between RA 2 software versions or different VCRX hardware versions, I’ll need to modify the binding to account for that.

8

Bob,

I sent you a PM with a link to download the DbXmlInfo.xml file.

There are only 3x physical CCIs on the VCRX (at least mine) and their labeled 1, 2, and “Full Flash”. I did short the “Full Flash” to the common ground and got the following output with tracing enabled. Both the Full and Flash LEDs light up solid when I did this and went out when I removed the short.

2020-01-20 15:59:18.375 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,34,31,3
2020-01-20 15:59:18.375 [TRACE] [n.internal.handler.BaseKeypadHandler] - Handling command DEVICE [31, 3] from keypad 34
2020-01-20 15:59:18.875 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,34,30,3
2020-01-20 15:59:18.875 [TRACE] [n.internal.handler.BaseKeypadHandler] - Handling command DEVICE [30, 3] from keypad 34
2020-01-20 15:59:26.985 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,34,31,4
2020-01-20 15:59:26.985 [TRACE] [n.internal.handler.BaseKeypadHandler] - Handling command DEVICE [31, 4] from keypad 34
2020-01-20 15:59:27.485 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,34,30,4
2020-01-20 15:59:27.485 [TRACE] [n.internal.handler.BaseKeypadHandler] - Handling command DEVICE [30, 4] from keypad 34

This is interesting as two CCIs closed and then opened. I’m not sure why Lutron defined two CCIs to a single physical contact.

9

Thanks Scott! Yes, I got your DbXmlInfo.xml file, and the VCRX component numbers look the same as in mine.

Yeah, I had forgotten that those security input CCIs are actually tied together. It is the same on mine. I suspect that it may be like that so that you can trigger the “full on” and “flash” parts of the security scene separately with the front-panel buttons (and maybe with HomeLink remotes?), but I’ve never tried it. Either way, it doesn’t make much sense to me. The HomeWorks version of the VCRX has the third CCI button labeled “security”, and the fourth unused, so maybe it didn’t make much sense to the people at Lutron either.

I’ll add a note to the docs that the VCRX CCI numbering is not what you might expect it to be.