[RELEASE] Cooper Eaton Aspire RFWC5 Keypad driver for Hubitat

Hi @arlomiller, I haven't tested it with the new RM button controller stuff yet. I'll take a look at it this weekend.

RE: double tapping. Unfortunately, the RFWC5 device doesn't support double taps. (Physically and in its firmware, it's not actually a button device. Eaton designed it as a scene controller, and it coincidentally provided enough functionality that I was able to simulate it being a group of 5 buttons. But unfortunately, it doesn't send enough info to reliably detect double taps.)

RE: reliability. Are you still seeing UNPARSED CMD errors in the logs?

@arlomiller - I'm using the driver as a button device via Rule Machine. If you need an example I can share it, though the configuration is pretty simple Button Press -> Set Light Levels.

Like Jwetzel said, there is not hardware level support for multi-tap with this device. You could try to mimic double-tap via RM, but I would suspect that would be a little hit or miss and would add a reasonable delay to processing a single tap.

It's possible that I could add support for double-tap at the driver level, but I suspect that would be hit-or-miss as well. Double-tap depends on timing to such an extent that it really needs to be implemented at the hardware level.

Double tap at the software level sucks. I've tried it 3 times on 3 different drivers, and it never works well enough to be worth it (in my opinion of course).

NEW CODE UPDATE!

I've tested and integrated @tchandle's optimization. It works fantastically, and significantly reduces the response delay when using the keypad in "virtual button" mode. Please grab the latest RFWC5-Keypad.groovy from GitHub at your convenience.

Thanks @tchandle!

Hi @jwetzel1492 I just installed a RFWC5 with the latest drivers but I'm seeing some errors in the log and the following issue.

dev:15642019-12-03 07:57:15.551 pm errorgroovy.lang.MissingMethodException: No signature of method: user_driver_joelwetzel_Cooper_RFWC5_Keypad_866.parse() is applicable for argument types: (hubitat.zwave.commands.basicv2.BasicSet) values: [BasicSet(value:0)]

It happens when turning the button off. The error is generated and the state of the switch doesn't change until you hit the refresh button.

Thoughts?

Thanks, Glenn

Hi Glenn,
Oh, that's interesting. My code is handling a BasicV1.BasicSet command, but it looks like your device is sending a BasicV2.BasicSet command. I wonder if your keypad is a slightly different version than mine.

Can you try editing line 109 of the keypad driver and changing "basicv1" to "basicv2"? Then let me know if you see any other error messages. If that works, I will update the official version of the driver to support v2 as well. Thanks!

Hey Joel, that did the trick. No more errors in the log and the device indicators go on and off instantly. Thank You!

There is another issue that popped up prior. I excluded and included the keypad a few times trying to fix the previously described issue. Everything seems to work except the leds on the keypad just continue to flash, like its ready to be included or excluded.

Any thoughts?

Hmmm, after re-including, did you click the Configure button and wait the few minutes for it to finish? (You can watch its progress on the logs screen)

Joel,

I did that and everything is working with a few exceptions.

  • HE responds perfectly to a button press setting the associated indicator to 1 or back to 0 but the LED's on the keypad continue to light in sequential order.
  • The All Off button doesn't do anything
  • Cycling power to the keypad appears to put it back into setup mode where a single push of the All Off button puts it into Inclusion/Exclusion mode.

The LED's should stop cycling when HE finds the keypad during the inclusion but that's not happening. It's as if it's not getting fully included. So the issue doesn't appear to have anything to do with your drivers.

I tried a second keypad, new out of the box, and received the same result where the LED's continue to cycle even after the keypad has paired with the hub.

I also tried pairing with the old ST hub and it appeared to work. Immediately after pairing with ST the LED's stopped cycling.

Here is some info and images of the keypad for comparison.
Model #: RFWDC
FCC ID: UH2-RFWDC
IC: 4706C-RFWDC



I really appreciate your help but want to be sure I'm not abusing your time.

Thank You.

New update...

I was able to pair the keypad and have the LED's stop cycling by pairing it once (LED's continue to cycle) then pairing it again (LED's stop cycling).

Everything is working except for the All Off button but I think I know why.

This appears to be a slightly different version of the keypad. The All Off button is actually an On/Off button addressable by the hub unlike the other keypad's All Off button that turns off all the buttons locally within the keypad.

In addition, buttons 1-5 can be used to dim lights up and down. Click and hold they dim the associated z-wave device up, click and hold again and they'll dim the associated z-wave device down. Obviously would need a driver to support these.

I'm not concerned with dimming but I may try and figure out what you did and see if I can get the On/Off button usable.

Ah yes, you have the curvy version. Sounds like it has slightly different firmware than the boxy version I have.

On mine, the all off button has to be held for 2 seconds to work.

Regarding dimming: I’ve looked into it, but unfortunately the zwave commands that are being sent back to the hub don’t include the info of which button is being held. So I think the dimming would only work with devices that are zwave associated directly to the scene controller.

I'm not concerned with the dimming but would like the On/Off button to work. I'll give the 2 second push a try.

For anyone using this driver, the new HE v2.1.8 introduced a bug. I've included a fix here:

1 Like

At some point, I am not sure when, my keypad has started SOMETIMES registering a single press as multiple presses. here is the log output after I pressed a button a single time:

dev:702020-03-30 04:46:13.159 pm infoDave's Lamp was turned off [digital]

dev:752020-03-30 04:46:12.795 pm infoDave's Switch (Virtual Button) button 1 was pushed

dev:702020-03-30 04:46:12.278 pm infoDave's Lamp was turned on [digital]

dev:752020-03-30 04:46:11.926 pm infoDave's Switch (Virtual Button) button 1 was pushed

dev:702020-03-30 04:46:11.559 pm infoDave's Lamp was turned off [digital]

dev:752020-03-30 04:46:11.228 pm infoDave's Switch (Virtual Button) button 1 was pushed

dev:702020-03-30 04:46:10.882 pm infoDave's Lamp was turned on [digital]

dev:752020-03-30 04:46:10.558 pm infoDave's Switch (Virtual Button) button 1 was pushed

I have two of these keypads, and they each control multiple different devices and it occurs on all of them. I am using the button configuration.

Any ideas?

I am still having my lights sometimes go on/off after pressing the buttons.

Not sure if relavent, but when I run configure, I get the following debug output:

dev:742020-07-15 05:26:38.826 am debugUNPARSED CMD: SceneControllerConfReport(dimmingDuration:0, groupId:5, sceneId:255)

dev:742020-07-15 05:26:35.347 am debugUNPARSED CMD: AssociationReport(groupingIdentifier: 5, maxNodesSupported: 232, reportsToFollow: 0, nodeId: [1])

dev:742020-07-15 05:26:14.265 am debugUNPARSED CMD: SceneControllerConfReport(dimmingDuration:0, groupId:4, sceneId:254)

dev:742020-07-15 05:26:10.708 am debugUNPARSED CMD: AssociationReport(groupingIdentifier: 4, maxNodesSupported: 232, reportsToFollow: 0, nodeId: [1])

dev:742020-07-15 05:25:49.572 am debugUNPARSED CMD: SceneControllerConfReport(dimmingDuration:0, groupId:3, sceneId:253)

dev:742020-07-15 05:25:46.044 am debugUNPARSED CMD: AssociationReport(groupingIdentifier: 3, maxNodesSupported: 232, reportsToFollow: 0, nodeId: [1])

dev:742020-07-15 05:25:24.947 am debugUNPARSED CMD: SceneControllerConfReport(dimmingDuration:0, groupId:2, sceneId:252)

dev:742020-07-15 05:25:21.394 am debugUNPARSED CMD: AssociationReport(groupingIdentifier: 2, maxNodesSupported: 232, reportsToFollow: 0, nodeId: [1])

dev:742020-07-15 05:25:00.316 am debugUNPARSED CMD: SceneControllerConfReport(dimmingDuration:0, groupId:1, sceneId:251)

dev:742020-07-15 05:24:56.811 am debugUNPARSED CMD: AssociationReport(groupingIdentifier: 1, maxNodesSupported: 232, reportsToFollow: 0, nodeId: [1])

Those messages are fine.

Let me recap, and make sure I'm understanding your setup:

  • You're using my driver, set up with buttons as the child devices
  • You're using Rule Machine to respond to those button presses?
  • When a rule fires, it toggles a smart switch?

thanks!

Correct, well currently it is set up as virtual switches because I wanted to give that a try to see if it did that then as well and it continues to toggle multiple times for a single press. Buttons are the desired behavior though.

not sure if this helps, but I put debug messages in both

def zwaveEvent(hubitat.zwave.commands.basicv1.BasicSet cmd) {
// Fired twice when a button is physically pushed off

and:

def zwaveEvent(hubitat.zwave.commands.sceneactivationv1.SceneActivationSet cmd) {
// Fired twice when a button is physically pushed on

the off event fires multiple times as demonstrated below:

dev:742020-07-14 08:39:04.360 pm debugoff

dev:742020-07-14 08:39:04.289 pm debugoff

dev:742020-07-14 08:39:03.919 pm debugoff

dev:742020-07-14 08:39:03.839 pm debugoff

dev:742020-07-14 08:39:03.780 pm debugoff

dev:742020-07-14 08:39:03.411 pm debugoff

dev:742020-07-14 08:39:03.376 pm debugoff

dev:742020-07-14 08:39:03.346 pm debugoff

dev:742020-07-14 08:39:03.181 pm debugoff

That's very odd, and unfortunately difficult to debug remotely. It really looks like the device is sending multiple reports back. Unfortunately, I've gotten other reports from other folks about devices with slightly different firmware and sending different combinations of reports back.

You may have to debug this yourself, but if you're comfortable doing it, look at line 88, the "Simplification figured out by tchandle". If you put more log statements throughout the parse() method, you might be able to figure out what path it's taking in there for each of the messages.

I got a little more information, looks like it is actually sensing multiple pushes... If this was not happening on two different keypads, I would think it may be a hardware issue. Also, the intermittent nature makes debugging it hard to do. All of this was from a single key press.

dev:692020-07-19 07:49:46.298 pm infoDave's Lamp was turned on

dev:692020-07-19 07:49:46.290 pm infoDave's Lamp was turned on

dev:3612020-07-19 07:49:45.944 pm infoDave's Switch (Virtual Button) button 1 was pushed

dev:672020-07-19 07:49:45.930 pm debugpush

dev:672020-07-19 07:49:45.917 pm debugCMD: SceneActivationSet(dimmingDuration:0, sceneId:251)

dev:672020-07-19 07:49:45.913 pm debugDESCRIPTION: zw device: 03, command: 2B01, payload: FB 00 , isMulticast: false

dev:692020-07-19 07:49:43.744 pm infoDave's Lamp was turned off

dev:3612020-07-19 07:49:43.339 pm infoDave's Switch (Virtual Button) button 1 was pushed

dev:672020-07-19 07:49:43.307 pm debugpush

dev:672020-07-19 07:49:43.271 pm debugCMD: SceneActivationSet(dimmingDuration:0, sceneId:251)

dev:672020-07-19 07:49:43.267 pm debugDESCRIPTION: zw device: 03, command: 2B01, payload: FB 00 , isMulticast: false

dev:692020-07-19 07:49:42.212 pm infoDave's Lamp was turned on

dev:692020-07-19 07:49:42.196 pm infoDave's Lamp was turned on

dev:3612020-07-19 07:49:41.799 pm infoDave's Switch (Virtual Button) button 1 was pushed

dev:672020-07-19 07:49:41.777 pm debugpush

dev:672020-07-19 07:49:41.757 pm debugCMD: SceneActivationSet(dimmingDuration:0, sceneId:251)

dev:672020-07-19 07:49:41.752 pm debugDESCRIPTION: zw device: 03, command: 2B01, payload: FB 00 , isMulticast: false