Yeah, I’d say that is definitely a Lutron bug. Actually, I’d say you’ve found two Lutron bugs: one for the VCRX CCI buttons not generating integration messages, and one for the wrong VCRX CCI component numbers on the integration report in the Ra2 configuration software.
I can’t easily get access to that connector on my VCRX, but I did confirm the problem by driving the CCI states using integration messages sent to my repeater. The CCI channels are not getting properly updated.
I believe I’ve found and fixed the problem in the binding code already. Unfortunately the fix is built on 2.5, and it will not load on 2.4 (well technically it loads but will not start). And since the Lutron binding in 2.5 has been moved to the new build system already, back-porting changes to 2.4 isn’t quick and easy. Unless I can find some time tomorrow, it may be a week or so until I can merge it back in to 2.4, build it, test it myself, and then make the patched 2.4 jar available on github.
Paul,
Ok. I was able to build and very briefly test the CCI fix for 2.4. Versions for 2.4 and 2.5 are available for testing here:
(https://github.com/bobadair/openhab2-addons/releases/tag/lutron-ccifix-beta1)
Basically, I fixed a problem that was left over from when I switched the CCI channel types from Switch to Contact. Thanks for pointing this out! I also changed the logic so that the autorelease parameter setting does not apply to CCI channels.
If you get an error about an unresolved requirement for gnu.io when you try to load the 2.4 version, just go into the console and execute the command “feature:install openhab-transport-serial”.
I finally got the time to try this out. I installed the 2.4 version, and it looks good.
Thanks,
Paul
Thanks. A version of this fix has been merged in to 2.5. Please see the docs for details.
Has anyone been using the Lutron binding with a RA2 Select system? I believe it should work, but I’d be interested in hearing about your experiences with it so that I can make sure that support for RA2 Select is properly documented and that any issues with it are fixed.
Other than overall function, I’m especially interested in getting information about discovery issues and in the results of certain integration commands used by the binding. If someone with a RA2 Select system could help out by answering the following questions, I would very much appreciate it!
Bridge Discovery
RadioRA 2 and HomeWorks QS use a custom UDP multicast to group 224.0.37.42 port 2647 for bridge device discovery. Caseta doesn’t support that, but instead uses mDNS for bridge device discovery. Since RA2 Select is controlled using the same app as Caseta, I would guess that it probably does as well. But it’s also possible that it supports both.
I’d like to know for sure if RA2 Select uses either or both of the above mechanisms. If it supports the UDP multicast discovery mechanism, the existing bridge discovery code in the binding should automatically find a RA2 Select main repeater (RR-SEL-REP2) and add it to the discovery inbox. Does it?
If it is using mDNS in a manner similar to Caseta, then from a Linux system on the same network with avahi installed you should be able to see the mDNS info from it using the following two queries:
avahi-browse -d local _lutron._tcp --resolve -tk
avahi-browse -d local _hap._tcp --resolve -tk
Seeing the response to those would help immensely in the development of automatic bridge discovery for Caseta and RA2 Select.
Device Discovery
RadioRA 2 and HomeWorks QS provide an XML configuration file that is retrievable from the bridge device via HTTP (e.g. http://192.168.1.2/DbXmlInfo.xml ). This allows for full automatic discovery of attached devices.
Caseta does not provide this. The configuration app allows the user to manually export the configuration in JSON format, however from what I’ve seen the resulting file doesn’t provide enough information to distinguish between different device types, so it is essentially useless for automated device discovery.
Does RA2 Select allow for the retrieval of a DbXmlInfo.xml file? Or does it use the same less-than-useful JSON config export mechanism as Caseta? Or does it provide something else entirely?
System Commands
The binding uses a couple of integration commands which may not work on all systems. I’d like to know whether they work or not on RA2 Select, as it isn’t documented anywhere that I know of.
This command should disable CLI prompts:
#MONITORING,12,2
This command should return the date and time of the last configuration update:
?SYSTEM,10
If it works, the system should return a response like the following:
~SYSTEM,02/25/2019,12:30:23
If these don’t work, you will probably get a response like “~ERROR,3” or “~ERROR,6” instead.
I’m running a RadioRA2 system and have a Grafik Eye QS (QSGRJ-6P) connected to it. (Note that despite it’s name, it’s capable of connecting to a RRA2 network!)
Even though it’s not officially recognized, I was able to trick the Lutron OpenHAB binding into (mostly) supporting it. Wanted to document that here in case anybody else is in the same situation:
The Grafik Eye QS consists of a few different components. It integrates some number of dimmers (my model has 6) and also has a lot of keypad buttons for controlling scenes and shades. The dimmers are fine since they get exposed as regular dimmers, but how can I read the keypresses?
Per the integration guide, the Grafik Eye QS exposes all of it’s keypad buttons in component numbers 38-83, and it turns out the VirtualKeypadHandler in the OH2 binding expects components 1-100 to be buttons! So if you manually set up a Virtual Keypad with the integration ID of your Grafik Eye, you can get the button presses. For example, “Shade Column 1 Open” button has a Lutron component ID of 38 in the integration guide, so you can link to the “button38” channel in the virtual keypad to use it.
You will also need to link a dummy item to the “led74” channel to get your thing status to be correct. (This is because the OH2 binding queries LEDs and waits for a response to determine if your thing is online. By default to prevent spamming the hub, it only queries the first LED and any LEDs that are linked. The first LED is mapped to a component that doesn’t exist, but the led74 gets mapped to component 174, which is the “Shade 1 Column Open LED”, so the Grafik Eye QS will respond to that query and OH2 will know that your thing is online)
At some point, I’ll look into properly adding the Grafik Eye QS to the integration, but this is a fairly nice workaround.
Hi Kevin! It’s actually great timing for you to bring up GRAFIK Eye QS support. It happens that just a few days ago I submitted a PR that adds a handler for the GRAFIK Eye keypad on RadioRA 2 and HomeWorks QS systems. The new thing is called “grafikeyekeypad” in order to distinguish it from the existing “grafikeye” thing, which is for stand-alone GRAFIK Eye controllers. I’m hoping that the PR will be merged in time for the upcoming 2.5.0.M2 milestone build. In the meantime, if you’d like to test it out, I can make a development build of the binding available on github. Actually, I would appreciate the testing.
Your technique of using the VirtualKeypadHandler for unsupported keypad types is a good one, though. As you point out, the tricky bit is linking at least one item to a valid LED channel for your keypad so that the handler will see a response to its state query at initialization time and mark the thing as online. Hopefully others will be able to use this work-around as well until they can move to 2.5.
Sure, I’d be happy to test out your PR!
I see that you fixed the issue with the keypad being initialized. Nice. That was also bugging me 
The 2.5.0.M2 milestone has finally been released! For those of you who have been waiting for M2, here are the changes made to the Lutron binding since 2.4.0:
- Added support for Lutron seeTouch CL hybrid keypad models
- Added discovery support for dimmer output types: ECO_SYSTEM_FLOURESCENT, FLOURESCENT_DB, ZERO_TO_TEN, CEILING_FAN_TYPE
- Fix for VCRX/keypad CCI channel bug
- Added support for HomeWorks QS International seeTouch keypads
- Added support for HomeWorks QS QSE-IO Interface
- Added support for GRAFIK Eye in RadioRA 2 and HomeWorks QS systems
- Fix for keypad reconfiguration bug
- Multiple documentation updates
1 Like
Hi Bob,
That’s fantastic news. Just wondering what the best way is to use the downloaded xml file, rather than autodiscovery? I tried
Bridge lutron:ipbridge:qs [ ipAddress="192.168.1.139", user="lutron", password="integration",discoveryFile="/etc/openhab2/utils/lutron.xml"]
and the bridge is then correctly added, but there’s no discovery of all the devices (and instead it looks like it’s trying to autodiscover from the online xml, with the usual ParseError).
many thanks!
Dan
@dan12345 I went to the Jenkins website per instruction posted by @Kai and manually installed it from the M2 bindings. Good luck 
Hi Dan. The PR that implements the “discoveryFile” parameter didn’t make it in to the M2 build. But the good news is that it was just merged in to 2.5 about 3 hours ago!
It contains a few bug fixes, plus the following user-visible changes:
- Adds support for reading discovery data from a file (see the updated docs)
- Adds discovery support for DALI and ELV output devices
- Defines bridge thing properties during discovery
- Reduces logging levels of discovery errors
I’d recommend trying this version of the Lutron binding over the M2 version for any HomeWorks QS users who have been having problems with auto-discovery as described in issue 5841. As Dan indicated, it will allow you to get around this problem by downloading the DbXmlInfo.xml file to your openHAB server and pointing discovery at it using the discoveryFile bridge parameter.
It may also be useful for Caseta users who have been annoyed by the discovery stack traces in their logs. It will eliminate those, although it will still not discover Caseta devices yet.
You may have to wait for the next nightly build. Then, as Steve mentioned above, you should be able to get it from Jenkins.
cool - thank you!
Well that is working perfectly - thank you!
I spoke too soon - there is an interesting problem with keypad buttons.
When I press and release a button, I see appropriate-looking entries in the events log:
2019-08-14 08:21:48.369 [vent.ItemStateChangedEvent] - MasterKeypad9 changed from OFF to ON
2019-08-14 08:21:48.369 [vent.ItemStateChangedEvent] - MasterKeypad9 changed from ON to OFF
However any rules triggered by an ON or OFF command don’t fire. Nor do rules triggered by a change to ON. The only rule I can get to fire is a rule triggered by a change to OFF (which I’m reluctant to use, because it would also fire when openHAB starts up).
I’m guessing the problem may be caused by the fact that the ON and OFF are shown as precisely simultaneous in the events log.
Has anyone else seen this? Is there a neat workaround?
Dan
That’s a new one. How are you triggering the rule? I’ve been using rules like this:
rule GoodnightScene
when
Item VirtualMBRKeypad_Button1 received update ON
then
...
end
You can also try setting the parameter autorelease=false for the keypad thing. That will keep the handler from automatically toggling the button back off right away when you press it. Unfortunately it may cause problems if you’re also using the Lutron Home+ app, but it would at least be worth a try for debugging purposes.
thanks - how funny. I had been having rules triggered by “changed”, but just replaced it with “received update ON” and it works just fine.
Great! I should probably add something about that to the docs.
Hi Everybody! I have a new test version of the Lutron binding which supports auto-discovery of keypad models for RadioRA 2 and HomeWorks QS systems. This will finally eliminate the need for users to manually select their keypad models after discovery, which over time has proven to be a major source of confusion. Implementing it required a considerable number of changes to the existing keypad handlers so that the discovery code could have access to the keypad configuration information. So before I create a PR to have the changes merged in to 2.5, I’d really like to have some people (other than myself) test it out!
Even if you use configuration files, you can still test keypad discovery. The identified keypad models will be written in to the log in DEBUG level messages. More importantly, if the discovery service isn’t able to identify the model for a particular keypad, it will write a message like the following in to the log at INFO level:
Unable to determine model of seeTouch keypad xx with button IDs: […]
You should not see any of these messages, but if you do please let me know!
The test binding is available here on github.
It will work with recent 2.5 milestone or snapshot builds, and may work under 2.4 as well.
One final note: Because of the way Lutron provides keypad configuration data in the XML, the discovery code is unable to distinguish between different keypad models with identical key layouts (e.g W3BSRL, H3BSRL, and HN3BSRL). In practice this doesn’t matter, since from the binding’s point of view these models are all treated identically.