Thank you for the detailed report, that will help us make the right changes in the next release. I'll post here as soon as that new firmware is available.
5 Likes
I noticed the same issue, plus some of the rest of what you noticed. (Hubitat's driver doesn't seem to expose all the LED parameters, including the default of being "on when dimmer is off and off when dimmer is on," which is confusing since the four buttom buttons don't directly control any circuits, but I'm assuming this terminology in the manual makes sense if you're using Z-Wave Association?) Assuming that the ZEN32 uses the "local protection" I've seen in other new Z-Wave switches/dimmers, the behavior of enabling local protection happening to disable more than you might expect is not uncommon (not just on/off but sometimes almost also anything else via Z-Wave), but I don't think it matches users' expectations, so hopefully they can change this behavior. Sounds like they're working on it (yay, Zooz!).
Are you taking more requests? 
Three taps on the large button puts the device into exclusion (or inclusion, but that part is hardly a problem considering it wouldn't be on a network yet) mode and causes the LED to blink blue. If you routinely use the "three taps" scene on this button, this is jarring, though likely not prone to disaster (unless someone nearby happens to have a Z-Wave controller in exclusion mode; not impossible, of course). I'm not sure what others think, but it seems to me like it would make more sense to use something that doesn't also correspond to a regular-use feature of the device (e.g., more than 5 taps or holding a specific other button while doing the three taps on this one?).
1 Like
Noted! It's always a challenge to change something like inclusion/exclusion button sequence because of all of the published documentation that's already out there and we figured most users would be just having 1-2 actions per button but we'll see what can be done here. Thanks for the feedback @bertabcd1234!
@agnes.zooz I completely second what @bertabcd1234 says here. We use the triple tap on at least one dimmer or switch in every room as a "turn on all the lights I need to see something" command. It's local to each room so if you're standing in a dark bedroom and you just need all the light you can get right away this is a quick way that everyone knows to achieve it. With triple tap also being the include/exclude I've already received quite a few "hey is something wrong this thing is blinking" complaints. It is a fair bet that I could be working on the system and someone inadvertently excludes something. That's happened here at home before! So please in a firmware update address this with some sort of failsafe. Perhaps you have to hold one of the four scene buttons while performing the triple tap or something like that?
I echo this too. As I am using the ZEN32 as a pure scene controller I use state machines in my Rules to determine in what mode a particular room is set. So if you're in the kitchen in "cooking" mode, I would want the top left button LED (button 1) to be lit and none of the others. But tapping on one of the others will adjust the LED and since RM should be driving everything here that's confusing. There should be a way for the Hub to have exclusive control over any/all of the LEDs so that the button presses/multi-taps/holds/releases always are sent to the Hub but then it is up to the Hub to tell the LEDs what to do/how to respond. I would extend that to the relay.
Goodness I hope so! @agnes.zooz Zooz made an awesome device in the Zen32 so I suspect you are about to get many requests… To add my own $0.02… I would like to see the LED colors and LED brightnesses have more range of color options. In fact, it would be tremendous to see a hue choice. As someone who likes to color code things and make things match, exposing a hue angle (0–360°) type parameter, especially through custom commands and Rules, would enable some really elegant color coding throughout a home. It also could give some nice matching options with other brands' color adjustable LEDs and LED bars (such as the excellent Inovelli LZW31-SN dimmers). Of course it would be difficult to achieve a perfect hue angle to hue angle match across brands. But if the parameter is exposed, we could figure out with some easy experimentation that hue 16° on Inovelli matches nicely with hue 20° on Zooz and hue 19° on Leviton.
2 Likes
I have had 2 of these installed for about a week. I installed them in a couple of places where I had wired Load directly to Line behind a Pico Remote. (Yes, I know this isn't legal everywhere and one of the reasons I wanted to make switch).
At this point, for this use case, I like the Scene Controller better than a Pico. 
Now, I am going Full Shields to protect me from the Pico Fanboys!!!!!!! 
I actually made a post probably 9-12 months ago looking for a wired ZWave Remote and this fits the bill. I have 2 more yet to be installed.
1 Like
We'll most probably add a setting to disable any button-related menu functions (like changing the settings, entering inclusion/exclusion) so that the buttons will function for control and scene control only for normal operation.
Can you provide an example of how that would work so I can better understand the expectation since you mention both the LED indicators and relay here?
Thank you for the feedback here, we'll see what we can do here!
Awesome to hear! Now I really want to send one of these to @mike.maxwell 
3 Likes
@agnes.zooz Can the Zen32 be used with a ceiling fan that has an existing remote.
Thought is to use it in smart bulb mode. Using the existing remote and automations to control the fan.
You could do this if you already had the ceiling fan automated with Hubitat. I would use Rule Machine (or a custom app) to be triggered by the Zooz button presses, and then send the commands to the fan.
Yeah, main concern is whether the switch is rated for a fan.
The fan is currently integrated through Bond.
If you won't be switching the fan and as long as it's not rated for over 3A, then you should be OK here. Typically, the inrush current and the wireless receiver on top of it, could easily damage an electronic switch but since you'll be using the ZEN32 to keep the power on and won't be switching the system, you should be fine here.
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.
