Cooper RFWC5 - indicators and scene control in OH2 not working

@Chris, Thanks for your note. I had hoped my post from March 18th would have provided the log of messages sent and received. Perhaps that post was not clear. Thus I will try to summarize this post. If this does not contain the information you had hoped for, I would appreciate your questions.
The RFWC5 maintains state for 5 scenes. That is any of these 5 scenes can be either on or off. This is indicated by the LEDs on the keys which are either dimm (off) or bright (on). The scene controller is initialized and the associations are set as detailed in the code below.

COMMAND_CLASS_ASSOCIATION_V1/ASSOCIATION_SET, Group ID = 1, Node ID = [your controller ID]
COMMAND_CLASS_ASSOCIATION_V1/ASSOCIATION_SET, Group ID = 2, Node ID = [your controller ID]
COMMAND_CLASS_ASSOCIATION_V1/ASSOCIATION_SET, Group ID = 3, Node ID = [your controller ID]
COMMAND_CLASS_ASSOCIATION_V1/ASSOCIATION_SET, Group ID = 4, Node ID = [your controller ID]
COMMAND_CLASS_ASSOCIATION_V1/ASSOCIATION_SET, Group ID = 5, Node ID = [your controller ID]
COMMAND_CLASS_SCENE_CONTROLLER_CONF_V1/SCENE_CONTROLLER_CONF_SET, Group ID = 1, Scene ID = 1, Dimming duration = 0
COMMAND_CLASS_SCENE_CONTROLLER_CONF_V1/SCENE_CONTROLLER_CONF_SET, Group ID = 2, Scene ID = 2, Dimming duration = 0
COMMAND_CLASS_SCENE_CONTROLLER_CONF_V1/SCENE_CONTROLLER_CONF_SET, Group ID = 3, Scene ID = 3, Dimming duration = 0
COMMAND_CLASS_SCENE_CONTROLLER_CONF_V1/SCENE_CONTROLLER_CONF_SET, Group ID = 4, Scene ID = 4, Dimming duration = 0
COMMAND_CLASS_SCENE_CONTROLLER_CONF_V1/SCENE_CONTROLLER_CONF_SET, Group ID = 5, Scene ID = 5, Dimming duration = 0

For operation, the scene controller behaves a bit inconvenient. Whenever a scene is activated (switches from off to on) the controller sends the following message

Received: COMMAND_CLASS_SCENE_ACTIVATION.SCENE_ACTIVATION_SET, hex data: 2B 01 <num> 00 
Received: COMMAND_CLASS_SCENE_ACTIVATION.SCENE_ACTIVATION_SET, hex data: 2B 01 <num> 00 

where is the scene number (1 through 5). That sounds pretty good. However, if a scene is switched off, then the controller sends

Received: COMMAND_CLASS_BASIC.BASIC_SET, hex data: 20 01 00 
Received: COMMAND_CLASS_BASIC.BASIC_SET, hex data: 20 01 00 00 

independent of which scene is switched off, or even multiple scenes are switched off using a long press on the right " all off" button. In which case I cannot see any indication which scene was switched off.
However, one can query the current state of the scene activation using:

COMMAND_CLASS_INDICATOR_V1/INDICATOR_GET

Now the controller answers with

Received: COMMAND_CLASS_INDICATOR.INDICATOR_REPORT, hex data: 87 03 15

Where the last number, here 0x15, is the binary value of the 5 scenes. Here 0x15 means bits 5, 3, and 1 were set.
The state of the scenes can be written using

COMMAND_CLASS_INDICATOR_V1/INDICATOR_SET with Value v

The the controller updates its state and the LEDs change accordingly.
What I imagine as a possible way to operate the controller is to have an integer scene number 0-31 indicating which of the 5 scenes are active. Whenever a message is received from the scene controller, the scene controller is queried for its current state and the scene number updated accordingly. When the scene number is written to, then the scene activation of the scene controller is updated.

Thanks. I’m not really sure how bet to handle this as this would need quite a bit of coding to make work and at the moment I’d prefer to avoid putting this into the binding. The best I can currently suggest is to configure the database with all the different channels, and then write a rule to tie it all together.

I’ve not looked at the database for the device and can’t do that at the moment, but if the relevant channels aren’t available, then we can easily add them - just let me know your account on the database site and I can give you edit access.

@Peter_Maunz Did you reach a resolution on this to get everything working? I’m still operating mine through my Vera and would like to migrate it over. Thanks.

I’m very interested in this as well. Any additional success?

@DigiArchiver I tested yesterday and can confirm it’s still in the same situation. Rereading the posts above after trying some other approaches made me realize that Peter is using an Aeotec Zwave stick and directly programmed in the associations using Aeon’s zensys tools. I’m going to give that approach a try as well and will report back.

The other approach I tried was switching over to Z-Way. With a very convoluted route I did get it to work, but unfortunately Z-Ways support of their versions of channels is very limited which made locks all but non-usable and didn’t even work with one of my switches. So now it’s only running my scene controller, so if I can find a way here then I can eBay my Z-Way board and be down to a single solution…

@DigiArchiver I was able to get it to work for turning on and off scenes and associated devices (didn’t try to control the scene lights from external). I put together a quick tutorial of what I did here -
https://community.openhab.org/t/tutorial-cooper-rfwc5-scene-controller-with-openhab2/31731?u=rgerrans

Thanks! We REALLY need the “Indicator” class channel exposed in OH2. That will open up the possibilities. Also, “hail” class would also be very useful. With those three channels I could do anything with rules.

Please define what you want. The defintion above is not a simple channel that maps to a command class - it’s quite a lot of functionality specific to this device. If we can define a class that allows a generic setting of the indicators, and then the device specific functionality is handled in rules, then this would be relatively simple.

What do you want to do with the hail class? Hail is already supported, but again, please define what you want to do.

@chris if it’s any help, under OH1 the ‘indicator’ class WAS exposed and did work. You were able to set the status of the indicator LED’s using this notation (from OP)

Switch DR_Scene1i “Scene 1 LED” {zwave=“16:command=INDICATOR,bit=0”}

where bit is the binary value of the scene selected.

The indicator class is currently implemented - this is not the issue. The earlier request asked for some quite complex, device specific functionality that would take a lot of time, be complex and messy to implement in the binding. What you’ve suggested here would be easy to add and it’s not device specific.

At the end of the day, there needs to be “a way to manipulate the LED’s on the controller” whatever that may be.

The code excerpt I posted used to work on OH1 but does not on OH2. If there is a way to get that working (or any method at all!) to turn the LED’s on or off it’d be great!!

Please remember that OH1 and OH2 are completely different bindings, so functionality that worked on OH1 doesn’t necessarily work on OH2. The item definitions are for start completely different - this necessitated a complete rewrite of the interfaces.

Please raise an issue and I’ll take a look at adding this when I get a chance.

I understand the architecture is different, There is no problem using a different syntax, etc… on OH2, whatever works to allow for LED control to happen is fine here!

I have formally opened an issue below:

Please open the issue in the zwave issue tracker - it will not be tracked in the OH2 issue tracker and will be lost (sorry). (I only noticed as I was going to rename it to something more generic, but I’ve not got any access to manage this list).

The earlier request was merely asking the same thing in a less succinct way. In OH1 this worked, in OH2 it doesn’t. You say the indicator class is implemented. How can I utilize it without a channel for it in OH2? What method do I use to address it? If there is a way for me to create/address the channel that would be great.
As for “hail”, that’s the patent avoiding alternative for “instant update”. It would be used to so as to know when any button press occurs or indicator lights change as, according to Cooper, that hail should be happening whenever there is a state change. Currently, I can only pick up every other button press as the “off” presses don’t show anything anywhere. Only the “on” presses. Is there addition Zensys tool configuration of the device I can perform to alter that behavior?

I disagree that the earlier request is the same - it asked for some device specific functions (at least that’s how I interpreted it). In any case, we can easily add a channel for the indicator class - no problem (as I said earlier). It’s not at the top of my priority list though.

Yes, I’m familiar with the hail class :wink: It should be implemented in the same way as OH1 - if not, then you could provide a log so we can look at it.

As far as I know there is no configuration available for the hail class. It is a simple (and deprecated!) command class only used on old devices.

Thanks Chris,

As I said, It was my failure to communicate it effectively. It was in fact the same thing, I just didn’t communicate it effectively. I should have just said what Phinnay said.
I’m sure, based on your extensive knowledge, that you know what the hail class is. Some things are exposition for other readers. This is an open forum :slight_smile:
I see you and I are in the same line of work. I may hit you up on LinkedIn or such. Thanks for the huge effort on this binding and any help you can give on this device. It’s the nicest keypad option I found when looking for z-wave scene controllers for two locations in my house. They are supposed to be for anyone in our house without a remote handy or understanding of the voice activation to press and kick off the whole house. Lighting, Sonos, etc.

Also, for my edification, if “Hail” is old and deprecated, what method(s) are newer devices using to implement that functionality and not patent infringe? Thanks.

Ok, we’re obviously talking cross purposes. By the earlier sugestion, I was talking about this -:

It wasn’t written by you.

I don’t know - I’m assuming the patent issue has been resolved by the Alliance. All I’m going on is that in the standards docs, it says that hail is deprecated.

Go for it :slight_smile: .

If someone can create an issue so this doesn’t get lost in the depths of the forum, then I’ll look at adding the indicator channels when I get a chance.

@chris anything ever come of this? Will we see the indicator channels in any of the new builds?