@chris anything ever come of this? Will we see the indicator channels in any of the new builds?
It’s an open issue at the moment - at some stage I’ll likely add this, but for now it’s not top of the list (sorry).
no worries, as long as it didn’t get forgotten. Holding off on purchasing additional scene controllers until it’s all worked out.
checking in to see if any progress has been made in the binding for this device.
I just came here for same. Wishing I at least had the OH1 behavior back. This device is rubbish under OH2. I have two. One at each end of the living space and they were perfect before for overall scene triggers for Openhab. Now they are wonky as hell.
Any other updates on these?
One of these, and a half dozen associated Cooper switches, are pretty much all I have left to migrate from Homeseer to OH. Unfortunately the scene controller and the lights hanging off it are the most used devices in our house, so I can’t really have the behaviors break on it.
While having the device channels set up properly to get the behaviors working with rules would be great, it seems a bigger issue is just that OH2 doesn’t have away to manage scenes in general? It adds a lot of latency to go controller -> scene trigger -> rule -> {device 1 | device 2 | device 3 | device 4} It moves the whole set from instant response to a second or two of lag.
As far as I can tell, there’s no way to device and manage Z-wave scene definitions, either? Unfortunately I’m using a Razberry z-wave controller, so using the Zensys tools to configure things that OH can’t do isn’t an option…
sadly, no updates. We’ve been hoping @chris had time to look at it but it seems this thread has all the info there is on getting this device to work at all with OpenHAB.
I’ve used rules instead of scenes with the RFWC5 with no trouble, nor any real lag, you checked over the code and made sure everything’s kosher there? anecdotal i know but anything helps!
Look at what? Do you mean the indicator class? This thread above is very old (over 12 months) and there have been additions to add this class earlier in the year.
Or am I missing something else?
my concern was the indicators, I was not aware this was added! Is there any more information or a specific version I can review the changelog?
No specific version - it’s included in the binding.
I’m not sure the device specification for the RFWC5 is correct, however. Its on my list, probably this weekend, to crank up the logging and see what is going on, but I don’t get any events from it at all. (I generally want to see if others have had luck before digging too much into it, because I’ve burned hours digging into OH stuff only to discover they were known to not work). Anyway, I’m still trying to figure out why. The “to-the-device” commands, like controlling the indicators, don’t do anything.
Now, that may be an issue with the indicator command class – do you know if anyone has been using it? All of the Cooper switches I’ve got have separately controllable indicators, and with Homeseer they could be controlled (although I’m not sure why you would on the switchers). In OH2.4, they don’t do anything. I have no idea if the commands aren’t working, or the way to script them isn’t the obvious “indicator.sendCommand(ON)” in a rule.
Am I correct, too, that the ZWave binding doesn’t have a mechanism to define scenes on the network? I can see there’s at least some shim code in there, I assume there’s no way to use it (even in rules) to actually interact with those definitions? The tutorial @rgerrans put together requires using the Zensys tools with the controller disconnected from OH to set things up, which doesn’t work for people who aren’t using USB sticks.
I get info from my RFWC5 in OH2 ‘debug’ logging, even before the official support update. Check your pairing, it might be wise to pick up a Zensys controller just to troubleshoot your connection. Worst case, Amazon has great return policies when you’re all sorted!
the indicator class is needed to sync several scene controllers together - example, in OH1 I had two of my RFWC5’s that had duplicated controls so someone could turn on the outside lights from both the poolhouse AND the garage. I structured my rules so that when this button was pressed the indicators on the controllers in both those location reflected the status of the outside lights.
I’m going to mess around with mine later and test things out, excited to see progress on this!!
Did you have any luck looking at it?
I cranked up debugging on mine. What I found is that none of the channels do anything – its not even all that clear to me what they’re supposed to do because the descriptions for the channels don’t really make sense relative to what the controller is supposed to be doing, and they don’t match what Homeseer had for configuration.
More so, though, even with associations on all the groups set to the OH controller, I see no events when anything is done locally on the switch, which makes me think the RFWC5 may not work at all without real scenes programmed into it. (That’s the only thing I can think of – it knows there’s no devices associated with any of the scenes, so its not reporting them.)
I’m not sure if that’s why the indicator channels are also not doing anything.
I may see if I can add Homeseer as a secondary controller this weekend, and use it to define some scenes on the controller and see if the messaging behavior changes.
@chris – is there a way (via rules or otherwise) to set association groups other than through the UI? Some digging into how they got this working with SmartThings seems to suggest it can be programmed via associations as well as the scene commands, but you have to set the associations properly – its basically device,level,device,level, etc…
I think that’s why the controller isn’t seeing button activations in the device. But, it does seem like people have really flailed to get these working properly in most of the non-commerical Z-wave systems. (Vera and Homeseer both handle them properly, but they “understand” scene controllers…)