[RELEASE] Zooz ZEN32 Scene Controller (community driver)

Community Apps and Drivers Community Drivers
,
#1

Greetings! As I recently mentioned in another thread, I've been working on a driver for the new Zooz ZEN32 scene controller device to expose all button taps (Hubitat's maxes out at double taps, as usual) while otherwise being as Hubitat-like as possible in implementation. Code link is below, or use the raw URL, https://raw.githubusercontent.com/RMoRobert/Hubitat/master/drivers/zooz/zooz-zen32-scene-ctlr.groovy, to import directly:

This driver exposes most device parameters in some way. Some LED parameters are not exposed as preferences because they can instead be handled with the setLED() command. For example, with buttons/LEDs 1-4, a setLED() command with a level of 0 will set that LED to off (or "always off" per the documentation description). This is different from the Hubitat driver, where this is a preference only, so the LEDs can now be turned on and off by commands--and apps--and not just manually via preferences. (Actually, looks like Hubitat's can do that now, so either I mis-remembered or it was added.) Using the setLED() command with a non-zero level (and color) will also keep the LED always on. I think the Zooz docs mean that options besides "always on" or "always off" for these LEDs sync the state with that of an associated device, but I do not use Z-Wave Association or have any way to configure that in this driver, nor is it my intent to use the device for this purpose (I was aiming for hub-controlled LED indicators you can use to show whatever status you want and scene/button events you can use for any purpose).

Now, for the button events: to get all 5 taps for each of the 5 buttons exposed as "standard" button events in Hubitat, there are 25 possible button numbers. Singe taps, holds, and releases are the typical buttons 1-5 pushed, held, and released. Multi-taps add 5 per additional tap to the "base" button number, giving possible events that look like this:

Image: button mapping for ZEN32 with this driver, where 'pushed' button numbers correspond to the 'base' button number plus 5 times the number of taps minus 1
Image: button mapping for ZEN32 with this driver, where 'pushed' button numbers correspond to the 'base' button number plus 5 times the number of taps minus 1702×562 9.23 KB

As usual, this is community code (and not supported by either Hubitat or Zooz), so exercise the usual care. Zooz also still considers this a "beta" device, so it's possible some things may change and the driver may need to be adjusted in the future. I'll try my best to keep up. Let me know if you use it and have any thoughts!

8 Likes
Zooz Zen32 Scene Controller
#2

This looks good. Now I want to get one, but it looks like its sold out.

#3

I am struggling trying to figure out how to utilize this switch the best.

I am basically wanting the buttons to operate individual dimmers or groups of dimmers throughout the house.

If the dimmer I am wanting to control is on, I want the LED to be off and vice versa.

I am wanting the button press to toggle on and off the dimmer. I am wanting the hold and release to slowly dim until released, and I am wanting double press to activate a scene.

Your driver seems to be the only way to address the LED issue, but I am struggling on how to write a rule. Can anyone help me? Or can anyone share an example of a rule they have used?

Great job on the driver! Now if I can just implement it LOL

#4

If your other devices are Z-Wave, you might be able to use Z-Wave Association to do what you want. Hubitat's built-in driver doesn't support this (I'm not sure any of theirs really do), but there are probably ways to set it up, or I could somehow add it to mine (but it wasn't really created with that use case in mind). If they aren't Z-Wave--or they are but you prefer a hub-based automation instead--my driver can definitely work. Here's one example.

Say you want the top left small button to toggle on/off a light. This is button 1, and a single push will give "button 1 pushed" (if you're using multi-taps: note that a double tap on this button is "button 6 pushed," and other assignments as above, in order to assign all possible actions a Hubitat event). You could use Button Controller to create something that uses the ZEN32 as a device, then assign "button 1 pushed" the action of toggling your other light.

Then there's the LED. Here, you'll need a rule or custom app. My recommendation would be a rule. If you want the LED to reflect the switch state of a device called Dimmer 1, then I'd do something like this:

Trigger events: Dimmer 1 *changed* (choose "Switch" for the trigger capability--not "Dimmer")

Actions to run:

IF (Dimmer 1 is on) THEN
  setLED(1,"white",0) on ZEN32
ELSE
  setLED(1,"white",100) on ZEN32
END-IF

The setLED() thing here is a custom command, which you can do by creating an action under Set Mode or Variables, Run Custom Action > Run Custom Action. Choose the ZEN32 as the device (any capability it supports will work to get it selected, like "Switch" or "Dimmer"--it will ask but doesn't matter beyond this), choose setLED() as the command, and create three parameters: the first as a number (integer--the button number 1 to 5), the second as a string ("white", "blue", "green", or "red"--no quotes), and the third as the level (technically anything 0-100 will work, with 0 being converted to off in my driver and anything above that getting rounded to the nearest value the ZEN32 actually supports: 30, 60, or 100).

You could also really do this all in the same rule if you wanted (maybe using a conditional action to check if the dimmer is currently on or off, then running the opposing command and optimistically setting the LED), but I think the above is better because it accurately reflects the dimmer state as Hubitat actually sees it, not according to what it should be set to.

#5

This is great information. Thanks for the quick response! I'll let you know what I end up with.

#6

errorgroovy.lang.MissingMethodException: No signature of method: user_driver_RMoRobert_Zooz_Scene_Controller__ZEN32__544.setLED() is applicable for argument types: (java.lang.String) values: [1,white,0]
Possible solutions: setLED(java.lang.Number, java.lang.String, java.lang.Object), getAt(java.lang.String) (setLED)

#7

I get the above error in the log when attempting to test my rule.

IF (Entryway Lights(on) is on(T) [TRUE]) THEN
setLED('1,white,0') on Bird Room Switch
ELSE
setLED('1,white,100') on Bird Room Switch
IF ( FALSE)

#8

You are using a single string parameter. You need to use three separate parameters of type number, String, and number, in that order, each with the appropriate values (LED number, color name, and level, respectively).

#9

Awesome! Ok. That makes sense. I understand now.
Thanks for your help!

#10

Just throwing it out there, but I would kill for the driver to allow me to set Association groups (similar to how Innovelli's Red Series drivers allow for Group 2 to be set). I started using association because of those red series switches and it is amazingly reliable and fast, moreso than any other sort of rule engine products I've used. Plus it's nice that it all still works even if your hub gets destroyed or is in the middle of rebooting, etc.

Side note that I tried the generic Inovelli association app to do this, and it didn't seem to work (plus it only supports a small number of groups, nowhere near enough for this switch!).

#11

Yeah, Inovelli's app requires the driver to implement specific commands to set the associations (which all of Inovelli's drivers do). It wouldn't be too hard to add those here, though I'm not sure what to do if their tool maxes out at group 5 (which it looks like it does but this one appears to use up to 11) except, I suppose, let you use the commands directly from the driver page to do whatever it is yourself. I didn't do this because I don't really use Z-Wave Association myself (much less on a device with this many possibilities for it!) and it's a bit of extra work I'd have a hard time testing, but I'll consider it.

#12

Try this ZWave Tweaker driver I ported from ST (and just finally posted). You can set regular and multi-channel associations from it. It has a pretty rough interface for now. You just install it as a custom driver, switch your device to it, and then switch it back when you are done.

Eventually I want to convert it into an app where you can select the device you want to configure from a drop-down menu.

BTW @bertabcd1234 feel free to borrow the code from my Zooz drivers for the associations if you want (I borrowed it and adapted it from the Zooz ST drivers). Although with 11 groups you might want to do it from a single command instead of having many preference settings. I was going to make a driver for this ZEN32 myself but you beat me to it. I left for a vacation right after I got mine in the mail.

#13

Nice, thank you for this pointer! As @bertabcd1234 pointed out, the Inovelli tool stops at group 5 which makes it a no-go, so I'm happy there's another option! Appreciate it and this driver :slight_smile: .

#14

Thanks to @jtp10181 for a couple suggestions/fixes: I've updated the driver to zero-pad the firmware subversion as needed (so 1.1 will now display as 1.01, which is how most manufacturers advertise them; this should be less confusing) and fix a typo I made when trying to send a BasicGet, which would only be run when manually doing a refresh().

1 Like
#15

Okay, I’m not sure where I’m going wrong here. I’ve set a separate rule to change the led color of the Zen32 buttons based on the on or off state of a switch.
The rule turns the Led red for off or blue for on.
However, it will only turn the led red. It flashes each time the state of the switch is changed, but remains red. What have I done wrong?

image
image750×1063 139 KB

#16

Looks like you're using strings instead of numbers for the first and third parameter types in the second setLED() call and the third parameter in the first. I can modify the driver to convert these better (you'll get unexpected results for some strings right now) or throw an error, which I don't think you'll get in most cases as-is, but that would be my recommendation.

#17

Okay, that was it. My bad, I noticed that but swear I used a number.
One other weird thing is led on button 5 (the main relay) flashes as the led 1 color is updated. This is annoying. Why is this?

#18

Yes, that is a quirk in the current (or at least original?) firmware:

[EDIT: Nevermind, that was a different problem; I guess a quick flash is expected when changing any parameter?]

#19

I just received FW 10.0 today. I don’t know when 10.0 was released, but it contains this bug.

#20

I think there was a mix-up here. You may be seeing a flash on the main button since it confirms a setting has been changed. The bug we were addressing was relevant to the LED's not working correctly in smart bulb mode. We haven't received any reports of the advanced setting confirmation flash to be an issue. Are you not seeing the flash when changing other settings?

Download the Hubitat app