Awesome, got it wired up, we will see how it goes.
I did notice that when z-wave and physical control is disabled the led goes to green and wont change. Anyone else see this?
Really liking this switch!
I have some suggestions, I know some of these were already mentioned
-The ability to triple, quadruple, and 5 times tap
-Larger color selection on the LEDs
-The ability to make an LED constantly blink until the changed to a different color or set it to stay solid.
-The ability for button 5 (Load button) to set the LED to like 20% when off, and 100% when on (similar to Lutron, not sure if there's any trademark/patent infringement there)
Keep up the good work @agnes.zooz and team! This is a really good product, I have 1 now, and plan on buying three more.
1 Like
Yes, this is a bug in the firmware and we hope to address it in the next release. Thanks for your patience here.
This could only be accomplished through a custom driver since it's a HE limitation to allow up to 2 taps per button, we'll see what we can do here!
Noted!
Seems like you could already do it based on how the driver was written where you can set the LED indicator to a custom color/brightness level based on a device state (in this case you would be choosing the ZEN32 switch as the trigger device and the ZEN32 main button LED indicator as the action device) - have you tried programming it this way?
Imagine using the ZEN22 as a controller adjacent to a cooktop. Pressing the big button triggers a rule in Hubitat to enter "cooking mode." Some lights around the cooktop dim up. Hubitat then turns on the relay which is connected to an exhaust fan. All the LEDs turn on now (they were off until cooking mode was triggered on) in white at a very dim level. When the exhaust fan turns on the relay LED turns red indicating that the fan is on.
Each of the four small buttons correspond to different lighting scenes around the kitchen. Activating one scene or another activates its corresponding indicator LED.
A single press of the relay button turns off the exhaust fan. Pressing it again toggles the fan back on. This only happens when in cooking mode.
Triple tapping the big button deactivates cooking mode. The LEDs on the controller shut off as it was at the beginning of this scenario. But to clear out some air after cooking, Hubitat waits 10 minutes to open the relay to shutoff the exhaust fan.
I'll admit that this is quite the contrived example. I struggled to come up with something that told the whole story. But I hope this clarifies. A similar scenario might be a bathroom also with an expeller fan. You might want to use a humidity sensor to automatically trigger the fan on/off but still leave the opportunity for someone in the bathroom to manually trigger it too. If the relay action is decoupled from the switch such that Hubitat actually controls it then lots of things become possible.
One general thought about the ZEN32ā¦ the indicator LEDs on a device like this align really well with indicating home modes, variable states, or perhaps even better exposing the current state of a state machine.
A plug to another forum memberā¦
This app by @jwetzel1492 could make for lots of powerful interactions with a ZEN32. I had to mention it because I just discovered the SSM app and when I started to noodle with it I was staring at the ZEN32 when the light bulb went on above my headā¦
1 Like
If anyone's interested, I'm working on a custom Hubitat driver for this that exposes all scene/button events. Unfortunately, it requires 25 button numbers (5 buttons times 5 possible actions per each, ignoring held and released where the "base" button number is used; I'm ignoring doubleTapped since it only saves a few button numbers and makes the rest of the math harder to do mentally) ... so it gets a bit messy. 
Here's a diagram:
Mathematically, the "pushed" events are for the "base" button number plus (5*(numberOfTaps-1)), so it can at least be done mentally with a bit of work. I'm also open to other ideas, but some sort of button-number-arithmetic is what I've done with similar multi-tap devices like the Inovelli Red Series devices. The only alternative I can think of is child devices for each button, each of which might also have buttons 1-5 pushed for mulit-taps. I'm just not a fan of prolific child-device creation if I can avoid it.
Beyond that, I've got the setLED() command exposed in a Hubitat-like fashion so existing rules/apps can probably use the same driver. If you set the LEDs to be "always on," you can also effectively do what I think the user request is asking for: set them by configuration commands only, not according to relay or associated device state. (Speaking of association, I don't really use it so don't have it in my driver at the moment and am unlikely to add it, plus by "syncing" any LED states with associated devices, it makes it hard to use them as indicator/notification LEDs like I'm aiming to.) If anyone is interested, I might have it polished up enough to share tomorrow.
4 Likes
You can already do all that by disabling manual and Z-Wave control of the relay and using central scene events for the described scenarios. Granted, it will require quite an amount of logic in Hubitat but on the device side, you can treat the relay completely separately from the main button. You can use any of our light switches this way as well so the paddles effectively become remote control buttons for anything in your network, including the load physically connected to the switch 
Please let me know if I misunderstood anything and if there is anything in particular on the firmware side that needs to be adjusted!
Thank you for working on a custom driver @bertabcd1234! Have you considered using the custom attribute for implementing multitaps like @krlaframboise did in our custom driver for the ZEN34 remote switch? This could potentially help with reducing the amount of buttons.
1 Like
I've thought about that, but then you lose the ability to use these devices with these drivers in "standard" apps like Button Controller or even with Rule Machine and a "Button Device" trigger--you pretty much need either a custom app or a custom-trigger Rule. So, it certainly works and makes things a bit less messy in the numbering world, but there are downsides to either approach. The other approach I considered was making each button a child device, but then you get lots of child devices for a single device, which some people also find messy (and you still have to handle the multi-taps, but "buttons 1-5" for each child button might be easier to do in your head, I suppose!).
For anyone interested, here is my first attempt at the driver I mentioned above:
...including all 25 button "pushed" events. 
3 Likes
Using the built in driver, Where in rule machine can I set the color and brightness of the LEDs?
1 Like
Not that you asked and I don't even have the device, but my .02 is that child devices would be cleaner. With 25 button presses I'd always have to reference a diagram. While child devices means more devices on the device page, it is much simpler (for me) to just think of a 1-5 button presses.
Yes, I'm aware that you can do this based off of a rule and triggers, I didn't know if there was going to be a consideration for the firmware/driver since we can set up the LED to be always on, on with relay on, on with relay off, or always off.
However, I'll set up a rule to do just that, thanks!
1 Like
Am I missing something or are there really only 4 different colors for the LEDs? If so, I'm pretty disappointed you can't have each button a different color.
From the manual:
- Adjustable LED indicator in 4 colors and 3 brightness levels
Itās a little confusing, the driver allow selection of:
White, Blue, Green, Red, Magenta, Yellow, Cyan.
But the configuration parameters for each LED have color values of 0, 1, 2, 3, for colors White, Blue, Green, Red, at brightness values 0, 1, 2, for levels bright, medium, low.
See:
https://products.z-wavealliance.org/products/4131/configs
Which driver are you using to get that many options? The built in driver that auto set upon inclusion only shows 4.
The SmartThings driver that Zooz provides on their ZEN32 product page, should be fairly simple to modify for Hubitat.
@agnes.zooz any reason why the smartthings driver would have more LED color options than the hubitat driver?
I'm not Zooz, but I don't see where the ST DTH allows more colors--the ST DTH appears to have only the same: white, blue, green, or red. However, it does use ST's new "custom capabilities" feature (note that this may also affect Hubitat port-ability), so I'm not sure what all of those do, and it's possible one displays more colors somewhere (though I still don't see how that would actually make it possible on the device).
The Documentation on z-wavealliance.com seems a bit confused, with typos. It may be that a firmware change by zoom made it possible to combine colors, with multiple LED components on at the same time to give different colors, rather than just Blue, Green, Red, and White (all LED component colors on).
Here is the support article from zooz that details the settings; parameters 6-10 are listed as providing a choice of 4 colors for each led:
https://www.support.getzooz.com/kb/article/608-zen32-scene-controller-advanced-settings/
Tony, I completely agree, and that more or less matches the config parameters for the device at z-wavealliance.com.
It just doesnāt match the choices in Kevin LaFramboiseās (@krlaframboiseās) SmartThings driver linked to on Zoozās page for the device, which makes me wonder if Zooz didnāt do some sort of a firmware update to allow a wider range of colors by turning on multiple LED component colors simultaneously. Zooz likes to do firmware updates to add features to their products.
