Lutron RadioRA 2 (and Caseta) plugin

My current adventure is repurposing a single keypad button to do basic control of Sonos. I'm thinking:

- Define artificial dimmed load attached to keypad button
- Turning button on will trigger Play for Sonos
- Dimming (using up/down) on keypad will adjust volume accordingly
- Turning button off will trigger Sonos Pause

I could either watch the artificial load for the triggers, or watch the keypad. Not sure which makes more sense yet.

Will let you know how it works...

Tony - I'd like to do the exact same thing. Wondering what you worked out as the best way to do it. I'm just dealing with on/off with a single button, but would be nice to use the up/down toggles to control volume too. My guess is the only way to do that would be with a phantom dimmed load, but curious how you worked it out.

Thanks!
-Ray

I'm seeing some weird behavior with how the plugin communicates with the VCRX - I think maybe we need to make a few changes.

First, the integration specs states (on page 129)

Momentary outputs should not be queried.

Yet since the code doesn't have a type for VCRX outputs, I had to select switch as the type, and it queries the state at startup. The status query gets back a response

Code: Select all

~OUTPUT,41,1,100.00

which doesn't really make sense, as that status suggests the output is closed, when it is in fact open. So the "100.00" is basically a nonsense value... Also, it sends an Action Number "1" to the output, which works, although it would probably be better to send an action number "6" to pulse the CCO...


A bigger issue arises with the CCI on the vcrx. Again, I chose the switch type for the CCI. Since the component number of the inputs is 32 and 33, the code adds 80 when querying for status, sending the command

Code: Select all

?DEVICE,46,112,9

which gets a response:

Code: Select all

~ERROR,4

However, the code does correctly respond to status changes on the inputs, correctly interpreting the status message

Code: Select all

~DEVICE,46,32,3

as closing the input.

Given all of this, maybe it would be good to create both a VCRX type and a CCO type. I'm a very amateur coder, but would be happy to take a stab at some proposed changes...

Note that the CCO's have different integration IDs than the VCRX itself. In my case, the VCRX has integration ID 46, while CCO1 has integration ID 41

rapamatic:

Have you tried defining your VCRX as a keypad instead of a switch? This is the recommended way to set it up and you can indirectly get the state of a contact by querying its corresponding LED.

Please do remember to delete a device from the Indigo database before attempting to re-add it or bad things happen!

I agree that we shouldn't be trying to query status at startup and will try to address that next time the plugin is updated.

Code contributions are always welcomed.

-Jim

Have you tried defining your VCRX as a keypad instead of a switch? This is the recommended way to set it up and you can indirectly get the state of a contact by querying its corresponding LED.

I'm sorry - I mis-spoke in my post above. I do have the CCIs setup as keypads - I need to do it that way since a CCI uses the integration ID of the VCRX with its own component number/button ID. The problems arise because the button ID is 32, not within the range expected by the program.

The CCOs don't have a button ID/component number, so I really couldn't set those up as a keypad. They only have an integration ID (like a switch or a dimmer).

I will take a crack at some crude coding this weekend... I'm thinking of making a new device type for both VCRX CCI and CCO... CCO to be able to issue the pulse command and not check for status, the CCI to properly check for LED status....

Judging by comments on the board, it seems a lot of people in general get confused about using multiple types for things (e.g. treating a shade as a dimmer)... so, philosophically, it would probably be easier for people to have different device types for the CCO and CCI? Do you agree?

Judging by comments on the board, it seems a lot of people in general get confused about using multiple types for things (e.g. treating a shade as a dimmer)... so, philosophically, it would probably be easier for people to have different device types for the CCO and CCI? Do you agree?

I can see that defining new device types for CCOs and CCIs would add functionality that is currently missing or not consistent with the Integration Protocol spec. That aside, I'd be curious to know about some specific use cases where direct control of the outputs/inputs would allow us to do things we can't currently do via buttons/LEDs associated with the contact closures.

A separate device type for shades has been on the to-do list for a while. The only reason this was never implemented is that that Indigo doesn't (yet) define a built-in Shade device class and also doesn't (yet) allow us to create our own UI icons for custom device classes. So we could create a new device type called "Shade" but it would operate identically to a Dimmer device and users would be wondering why their shades were represented by lightbulb icons.

Cheers,
-Jim

I can see that defining new device types for CCOs and CCIs would add functionality that is currently missing or not consistent with the Integration Protocol spec. That aside, I'd be curious to know about some specific use cases where direct control of the outputs/inputs would allow us to do things we can't currently do via buttons/LEDs associated with the contact closures.

The case for direct control/monitoring of a CCI is fairly easy (I think) - I am using a CCI with a magnetic garage door sensor to indicate when the garage door is closed. From what I can tell, there is no great way to have that state reflected in a RR2 keypad LED.. To be honest I haven't played around with it a lot in the RR2 software, since I just got the sensor installed a couple of days ago, but from what I've seen here: https://forums.lutron.com/showthread.php/30-Garage-Door-Control there are issues trying to get a reliable indicator of door status on a keypad button within the current limitations of RR2 programming (or lack thereof).... So, to avoid these potential issues where the keypad LED state may get out of sync, its best to monitor the CCI directly.

I agree that with the CCO, as long as their is a keypad button programmed to toggle the garage door, it is just as easy to talk to that keypad button vs the CCO. Maybe its just the completionist/perfectionish in me that would like to talk to the CCO directly

The case for direct control/monitoring of a CCI is fairly easy (I think) - I am using a CCI with a magnetic garage door sensor to indicate when the garage door is closed. From what I can tell, there is no great way to have that state reflected in a RR2 keypad LED.. To be honest I haven't played around with it a lot in the RR2 software, since I just got the sensor installed a couple of days ago, but from what I've seen here: https://forums.lutron.com/showthread.php/30-Garage-Door-Control there are issues trying to get a reliable indicator of door status on a keypad button within the current limitations of RR2 programming (or lack thereof).... So, to avoid these potential issues where the keypad LED state may get out of sync, its best to monitor the CCI directly.

I agree that reliably reflecting the status of a CCI on a RR2 keypad is problematic with a Lutron-only solution, however, we can easily overcome that deficiency with Indigo. While I'm still not disagreeing with the observation that we should add a CCI device type to make things more intuitive, we can reliably monitor the status of a CCI via its LED and then update any keypad LED when the CCI state changes. I'll provide an example. Note that I defined my CCIs in Indigo as Phantom Button/LED device types and defined the rest of the VCRX as Keypad device type.

This is my setup:

3 garage doors openers are connected to CCO outputs 1-3. Output 4 is currently unused.
Parallel dry contacts are wired up to the CCI input 1 (ID 32). (The doors are all visible from the same location, so I'm only concerned if any door is open).
A directional driveway sensor is wired up to CCI input 2, ID 33 (vehicle leaving) and CCI Full/Flash, ID 31 (vehicle arriving)

The three outputs are all set up as momentary, so I always have Indigo send an On to close the relays.

I have triggers set up that respond to the phantom LEDs 31-33. For example, Indigo emails a security camera photo whenever a vehicle arrives. These "phantom LEDs" follow the state of their associated CCIs with 100% reliability.

I have not personally tried this, but I don't see any reason why we couldn't get a reliable status indication on a keypad LED by setting up Indigo triggers that watch for CCI device state changed events and set the appropriate state on the keypad LED accordingly. If the updates are coming from Indigo, it really shouldn't make any difference if we define the CCI in this admittedly nonintuitive way versus defining a separate device type for the CCI.

Again, I agree with Ray's comment that the addition of a separate device type for CCI would be useful and less confusing and offer this kludgy workaround in the meantime.

Cheers,
-Jim

Hi all,

I just posted version 1.26 of the plugin: http://jimandnoreen.com/?p=208.

Here are the changes:

1. Added explicit support for contact closure inputs and outputs (CCIs/CCOs). Many thanks to rapamatic for his research and code contributions!!
2. Added explicit support for motorized shades and removed the lightbulb icon for shade devices from the UI
3. Device names are now recorded in the Indigo log
4. Fixed a bug that could cause the UI to hang when adding certain devices to the Indigo database

Please let me know if you encounter any problems with this update.

Cheers,
-Jim

Greetings. New user here. I went ahead and ordered a serial cable to test this out, but wanted to offer my "+1" request for an IP-connection option.

If anybody has a version that works with ethernet please let me know.

Thanks for those with the skills to do this and share with the community.

I'm very pleased to announce that a member of the community (Ramias) has invested substantial effort to add IP support to the plugin.

His work will be folded into the next general release, which will be out within the next 1-3 weeks, depending on integration testing.

And many thanks again to all past contributors.

Cheers,
-Jim

Awesome news - hopefully I can retire the little IP Serial port box I'm using!

Other than eliminating the ip-to-serial boxes a lot of us are using, is there any advantage to going ip?

I'm very pleased to announce that a member of the community (Ramias) has invested substantial effort to add IP support to the plugin.

His work will be folded into the next general release, which will be out within the next 1-3 weeks, depending on integration testing.

And many thanks again to all past contributors.

Cheers,
-Jim

To clarify: I took the work Sbe08 started (He was able to get me access to his version via another community member since Sbe08 was out) and integrated it with Rat Ranch's latest version. Though what I did is IP only; not dual-stack.

Excited to watch this space as the work continues.

So far I'm very impressed with Indigo -- and its community.

I'm building a new house and read through this thread, I may used Lutron Homeworks since I have the luxury of running control wires. I expect this plug-in would work as it would be going to the same "base" controller. Does that sound correct?

I'm building a new house and read through this thread, I may used Lutron Homeworks since I have the luxury of running control wires. I expect this plug-in would work as it would be going to the same "base" controller. Does that sound correct?

The plugin should theoretically work with Homeworks QS because the command set is the same, however, AFAIK this has never been tested.

Please let us know how it goes for you.