I have a new Honeywell Z-Wave In-Wall switch (#39354) that gets identified as a "GE Enbrighten Z-Wave Smart Switch". There is a preference that works to set the LED indicator mode (on when off, on when on, always off). Would there be a way to expose this via the driver so that I could set this as an action that could be timed, etc.? Thanks.
Welcome to the community.
Is this the Z-Wave Plus version? Jasco sells this switch branded for Honeywell and for GE.
You can tell if it’s the Plus version by looking at the in, out clusters. Plus version has 0x5E, non-Plus does not.
If it’s the Plus version, Jason Bottjen’s (@JasonJoel’s) driver should do what you want.
I assume you understand how to install user-contributed drivers. If not, details are here:
https://docs.hubitat.com/index.php?title=How_to_Install_Custom_Drivers
It is a Plus version. I added and set the custom driver, but I'm not sure how to control the indicator LED with an action? Is it a custom action with a parameter? Thanks.
Well, I don’t have this device, all of mine are GE/Jasco smart motion switches/dimmers using Jason Bottjen’s (@JasonJoel’s) component drivers.
Right now, by reading the code and looking at how this driver behaves with a virtual device, seems that it’s a parameter you set on the devices page. But it seems a straightforward task to add a set of commands to be controlled as actuators in a rule, one for each LED mode.
However, thinking about it, this seems like the sort of thing that should be set once as a parameter as the operating mode for the switch, not a command that one would set with an actuator command. The LED Indicator Behavior parameter is set in a straightforward manner by the selector for the parameter.
Yes, the preference setting works even for the default driver but I was interested in being able to automate this with an action. Can you please point me to an example of code for a custom command?
No version of the drivers has this ability currently. You would need to add the code to one of the user drives to do this.
RM rules can only interface with COMMANDS, not PREFERENCES. So you would add a new custom command, and then a new method to send the zwave config change when the command is done.
See below. NOTE - I did NOT test this out, and it could have errors. I don't have any plans to add this command to my version of the drivers, so this will have to be an exercise for you to do on your own on your own private copy of the driver. Have fun!
Command something like this:
command "LEDBehavior", [[name:"LED",type:"ENUM", description:"LED Behavior", constraints:["0" : "LED ON When Switch OFF", "1" : "LED ON When Switch ON", "2" : "LED Always OFF", "3" : "LED Always ON"]]]
And a Method something like this:
def LEDBehavior(value) {
if (logEnable) log.debug "Setting LED Behavior to ${value}"
value = value.toInteger()
sendEvent([name:"LEDBehavior", , descriptionText: "$device.displayName LEDBehavior set to $value", value: value, displayed:true])
return delayBetween([
secure(zwave.configurationV2.configurationSet(scaledConfigurationValue: value , parameterNumber: 3, size: 1).format())
,secure(zwave.configurationV2.configurationGet(parameterNumber: 3).format())
], 250)
}
Then you should be able to adjust the "LEDBehavior" custom command in an RM rule, etc.
3 Likes
Works perfectly. Thanks very much! (Note it didn't like the syntax of the command initially - apparently it expects an extra set of brackets around the parameter arguments.)
I searched about this and could not find any information: Could you tell me what the "Association Group 3" is? Thanks.
On this device assoc group 3 sends basic set association commands when double tap is done.
I don't use associations at all, so no idea how well/if that works.
You can typically learn what any parameter or association group does by looking the device up on the zwave alliance webpage:
https://products.z-wavealliance.org/regions/2/categories
Oops. I went back and edited the post in case anyone else tried to copy/paste it.
1 Like
The Associations are working well with the new Honeywell switches. Setting the associations allowed me to remove 8 now unnecessary rules.
1 Like
Aside from the known caveats of associations (status updates don't get sent to the hub on most devices, impact of secure messaging, god help you if return routes get messed up, and the association messages are NON routable [as they are broadcast] so the devices need to be "close" to each other in the mesh), they can be handy for some.
That said, I would still rather have 8 rules in the hub than magic invisible commands. 
1 Like
Well, the status updates seem to be consistently sent with these switches and I don't fully understand the potential routing issues, but you do have me rethinking my decision :).
I'm surprised, actually. I thought the GE devices were one of them that did not send an update if manipulated by an upstream association. Cool that they do, though. That behavior is all over the place across manufacturers.
The routing issue I alluded to is an interesting thing, but applies more to controllers, so likely doesn't apply here with only end devices being involved.
If your associations are working as expected, I think you are fine leaving everything as-is.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
