[DRIVER] Zooz Relays Advanced (ZEN17 / ZEN51 / ZEN52)

[jtp10181]

Zooz Relay Drivers with the goal of exposing all advanced features and settings.

If you are using this driver PLEASE like this post.

Supported Models: Driver v1.1.2

• ZEN17 Companion ONLY - Min Firmware 1.04
• ZEN51 Relay - Min Firmware 1.40
• ZEN52 Double Relay - Min Firmware 1.40

---

Instructions For ZEN52: By default this driver will work with the child devices created by the Hubitat system driver. For that to be less confusing there is only support for up to 2x button pushes posted on the parent device (using momentary switch). If you need to use 3x or higher, switch to the 'Device' driver, delete the child devices from the command button. Then, switch back to this driver, press Configure. Once that is complete, turn on the "Scene Events on Child" setting which will send the events to be posted on the child devices.

---

Instructions For ZEN17: The driver is a companion to the stock Hubitat driver with the goal to make configuration easier. Since the advanced stuff of creating the child devices and catching the z-wave messages from the device works well on the stock driver why re-create it?

1. SWITCH to this custom driver
2. Refresh to confirm firmware/model (then refresh the page)
3. Sync from the Device (command button)
4. Adjust parameters not found on the main driver.
5. Switch back to the Hubitat built-in driver
6. Press CONFIGURE to make sure the childs are setup correctly.

---

Features:

• All configuration variables available with designated defaults per Zooz
• ZEN17 Sync from Device to grab existing settings as a starting point

---

Reporting Issues
Please use GitHub to report any issues so each one can have its own conversation and tracking. Please provide as much info as you can including model, firmware and the "configVals" data string. Issues · jtp10181/Hubitat · GitHub

---

Must PRESS CONFIGURE BUTTON and check all your parameters after changing to this driver.

Find on Hubitat Package Manager (HPM):
Package Name: Zooz Relays Advanced Drivers
HPM Install Guide: HOW TO: Install Hubitat Package Manager (or any other User App)
HPM Docs: https://hubitatpackagemanager.hubitatcommunity.com

OR Manual Download from GitHub
Full Repository Link: Hubitat/Drivers/zooz at main · jtp10181/Hubitat · GitHub

Donations: ---->>>> PayPal.Me <<<<----
Never required, always appreciated!

[SoundersDude]

Very cool, thank you for releasing this!

[jtp10181]

UPDATE

Just posted a new driver for the ZEN51 relay, with a ZEN52 Double Relay driver soon to follow. I have min firmware listed as 1.40 which was released recently. I have not tested on anything below this, so it may work fine but Zooz advised me to update them to 1.40 as soon as received them so I am assuming some bugs got fixed.

[hydro311]

Thanks Jeff! I replaced an old Qubino Flush with a Z51 in my unorthodox bath-fan setup, and although I'm not using any fancy options with the Z51, I still much prefer the easy-to-undertsand parameter setup you provide in your drivers. Thanks again!

[jtp10181]

UPDATE

Added ZEN52, in order to make it less confusing to support up to 5x button taps I am sending the events to the child devices if you turn a setting on. You will have to delete the child devices and re-create them with my driver so they are unlocked and using the central scene component driver which supports button events. More details will be added in the main post shortly.

[0.2.0] - 2021-08-22

• Initial Release of ZEN52
• Minor fixes for ZEN51

[jtmpush18]

Hello @jtp10181
A quick question about this driver for the Zen51 and Zen52:
These two devices are "switches" as opposed to "dimmers".
I also understand that there are many button taps that may be interpreted by the Hub.
Does that mean that I can change the power output depending on the number of button taps, and so simulate a dimmer?
For example, can I trap 5 button taps and so turn it on 50%?

[jtp10181]

There is no options to adjust the power output that I am aware of. They are just dry contact relays I think, so whatever you put into them they pass through when you close the relay. The ZEN51 for sure has a separate power input from the switched input. From memory the ZEN52 may share the inputs so it might only work with full line voltage, would have to double check the wiring on it.

[jtp10181]

UPDATE

This update was really about adding Association Group support (single channel) per a request. In the process I found an issue with my code for the lifeline association on the ZEN52. Anyone using a ZEN52 please run a configure after updating, and if you then have "Pending Changes" either save preferences or run configure again.

[1.0.2] - 2023-02-28

ZEN51/52

• Added Association Group Support
• Fixed made some typing more lax to prevent errors
• Fixed lifeline association configuration for ZEN52

ZEN17

• Minor cleanup and code sync with shared functions

[bill.d]

Great driver. I just installed the ZEN52 in a closet with a physical door jamb plunger light switch. I'm using it to turn off the light if the door gets left open. Would it be possible to add the state and events of the relay to the child driver? I'd like to track the state of the door itself. I believe the information is there as the switch events are marked physical vs. digital. Thanks!

[jtp10181]

So basically you want to track if the door is open or closed based on the physical switch triggers? I think that would actually make sense to do with a virtual contact sensor and then RM. Only hang up might be when you shut the light off with a timer, the physical closed event will trigger an "off" on the relay, I am still sending the event to the hub but it doesnt post it to the event log because its a duplicate. I could try and test it out? I have a ZEN52 right here for testing already wired to a toggle switch and a light.

[bill.d]

@jtp10181

So basically you want to track if the door is open or closed based on the physical switch triggers?

Exactly

@jtp10181

I am still sending the event to the hub but it doesnt post it to the event log because its a duplicate.

This is the issue. There's no way to write a rule due to the filtering even though the type (physical/digital) is different. I guess if you can get it in the driver the status should probably be open/closed for a relay.

[jtp10181]

Hold my beer
I have an idea for RM. I will see if it works.

@bill.d - This works! Using the fact that a button press will always be logged. In this example I have the Scene Events on Child turned OFF, but it could work either way just would need to change where to look for the button press.

There is a slight chance it could get out of sync but another open / close should get it back. The 0.1 second delay is so that the button event when turning on doesn't trigger the Wait that follows. I tested it a couple of times turning on and off quick and it seems to work still.

Here is your use case, switch turned on physical, contact opens. Switch turned off digital, no change. Physical switch turned back off (button pushed), contact closes, light stays off.

[bill.d]

I'll take a look later today. Another alternative for me is to use the 2nd switch to monitor the door status as I don't use the 2nd output. I'm far from a coder, but I can slowly poke around some drivers. But your driver with the Z-Wave code is much harder for me. It looks like the device is sending all the info necessary to populate and manage a 'relay' attribute since your driver can tell physical vs. digital. It would seem to me that you could use the physical vs digital handling reworked slightly to manage the relay state? Thanks again.

[jtp10181]

It’s really a trick to determine the digital activation. A state variable is set if any commands pass thru the driver to turn on or off. Then the next state change from the device is determined to be digital. Anything else is considered physical.

Yes, it could be added to the driver but would need to be on the parent unless a custom child driver was created. The child drivers do not have an attribute I could use.

I will have to think about how that would work with the different switch modes though. I don’t think it would apply to momentary mode, etc….

Is there a reason you don’t want the rule? It will be no less accurate than code in the driver. I sort of like the idea of having a separate virtual contact sensor as well.

@bill.d So I decided to do a quick mod so you can try it out. It will set S1 and S2 attributes on the parent device based on the status of the inputs. Was only adding a few lines of code. I posted the original driver to the Gist first, then the update so if you click the "Revisions" section you can see what I changed. ZEN52 Driver with extra option to track state of S1 and S2 inputs. · GitHub

[bill.d]

Thanks, it looks like it works, appreciate your efforts. Another alternative might be optional contact device for the relays? The reason for avoiding a rule is that the state really is one that should come from the device. The prefs have NC/NO capabilities for the relay. Maybe the relay state reporting is something that Zooz could add via firmware? I think I'm set for now.

[jtp10181]

The relay state is the switch on/off status in the child. You are looking for the input state really and the device does not report the state of the input, I am just making a good guess just a guess based on if someone told the driver to activate it or not. So using the rule or the modified driver I made gets you the exact same results in the end I think.

I am not sure what impact the NC/NO setting would have on this, I only tested this recent stuff with the defaults. I would have tested the entire driver with those options originally but I don't remember what it did exactly to the reporting from the device.

[bill.d]

I just checked, it's the same value is reported for the physical state whether the relay is set to NO or NC. Maybe I'll send a feature request to Zooz to get the switch state reported.

[bill.d]

Me again. I just picked up a ZEN17 and think there is opportunity to improve the stock driver.

• The first one is more about instruction/documentation. One cannot decouple the input switches from the relays for non-sensor input device types. Yet that's not clear and one can make the decoupling setting in the driver. Maybe dynamic pick lists, highlighting of incompatible settings, or just text noting the possible incompatibility.
• There are 2 input sensor device types that don't create child devices: Heat Alarm and Dry Contact.
• The way I'm using it I'd like to use the contact sensor and to have it report as a switch. The default device is a 'Generic Component Contact Sensor'. When I change the device to 'Generic Component Contact/Switch' the driver automatically deletes the child sensor and re-creates it using the 'Generic Component Contact Sensor' driver. The device should at least accept the combo driver, if not make it the default.

@jtp10181 I'm grateful for your efforts to make all these drivers work well.

At the same time I don't think it's the best user experience. Hubitat tends to release minimum viable drivers and doesn't appear to have a process to go back and improve them (there are several in this state, not just Zooz devices). @agnes.zooz I don't know how Zooz works with Hubitat to add and manage the built-in drivers, but of the devices I use Jeff's 'advanced' drivers for all are better than the current native versions. I'd suggest that you hire Jeff to be your Hubitat driver maker and get his drivers built into Hubitat. Hubitat has recently incorporated some user drivers/apps into the built-in category recently that also continue their open branch too (Kasa and Webcore). @bravenel I don't know where built-in driver updating/improving lies on your priority list; there are several that could use some freshening.

@agnes.zooz also note that your instructions are out of date about child device creation for Hubitat at least. The child sensor devices change without needing to exclude/include the ZEN17.

[jtp10181]

Thank you for the praise, it is appreciated . As far as I know Zooz sends sample devices to Hubitat staff so they can make official drivers for the devices. I create drivers either because I have the device and don't like the built in driver, or sometimes I am asked to create one and sent a sample device.

The ZEN17 I saw people having a hard time with configuration so I decided to make this companion driver, since it would be pretty complicated to make the full blown driver with all the different child types, etc...

I suspect the reason the system drivers are often very basic is maintenance. For my advanced drivers every time Zooz comes out with a new version or adds settings I have to update the driver to accommodate it. This has stabilized quite a bit recently, far less drastic changes so my drivers continue to just work.

For your contact sensor/switch problem, a possible solution would be to create a virtual device with a combo contact/switch driver, and then mirror the ZEN17 child to the virtual device with an RM rule. I know its a work around but it would get you what you want for the time being.