[DRIVER] Zooz ZEN Switches Advanced (and Dimmers)

I have a bunch Zen23/24 V2s on my 2nd floor - they do not respond to physical changes at least consistently. The really sad thing is I never noticed this until I started to incorporate motion sensors into the mix and needed a way to detect physical switching (to temp disable motion sensor function)...

The switches seem to have issues with reporting and this does not appear to be a driver thing as far as I can tell.. I've tested them both on HE and Home Assistant. It could be a reporting parameter but not sure.

The REAL annoyance is not being able to update the firmware... so am slowly swapping them out.

I purchased them all at the same time, and the other three still show firmware version 2.00 (because I had not upgraded those). They also still show "synced", but I have not recently attempted to use the configure button for them. I noticed that you updated the driver in July and August, and I wonder if something about that – when combined with me using configure on the one switch – is why that one is now showing "pending"?

I'm not overly concerned about it since you said it works even though it's showing pending, but just trying to give some more details in case it helps troubleshoot what's going on.

UPDATE

This is minor update. Added the new parameter available on current ZEN72 firmware. Fixed the issues with the ZEN30 and getting stuck on 1 Pending Change due to factory set lifeline association (it now can identify the multichannel association so it wont keep trying to set another one).

The setLevel update may be of interest if you are doing any gradual level transitions. Unfortunately the 2x models will only go up to 254 seconds, but the 7x models support the current zwave specs and you can go up to 127 minutes technically. Instead of having the hub step your level slowly, sending dozens of commands and possibly causing a choppy transition, you can can just set the level with an extended duration (in seconds) and let the switch do the transition smoothly. Input is in seconds but anything over 2 minutes will be rounded to the nearest minute (the command must be sent in minutes once you get past 127).

[1.6.3] - 2022-11-22

Changed

  • Enabled parameter 7 for ZEN72 on new firmware
  • Set Level Duration supports up to 254s for 2x and 7,620s (127 mins) for 7x

Fixed

  • Fixed lifeline association checking on ZEN30 - @es_ferret
  • Convert signed parameter values to unsigned
6 Likes

That took care of it.

Thank you!

Great driver, however I’m having one issue with a ZEN04 switch when from time to time it does not an issue a switch off event although the switch turned off. I do see a coo and-off event but no switch off as seem below.

In addition, there are also a lot of 0V voltage events. Less critical, but worth noting.

Thanks again.

UPDATE

NOTE: Setting a parameter from the new command is like setting a temporary parameter. The Preferences will still have the old parameter so if you run a Configure it will set them all back how they were saved in the Preferences.

[1.6.4] - 2022-12-13

Added

  • Command to set any parameter (can be used in RM)
3 Likes

Can confirm that on my Zen74, the Set Parameter command is working both in the device detail page and through Rule Manager! This change genuinely adds serious functionality to my dimmers, thank you so much.

I'm not sure if this is unusual behavior or not, but the preferences listed in the device detail page do not update to reflect the newly set values, though the switch is working and the Refresh Params log appears to report the new changes. syncStatus lists "1 Pending Changes."

Also under the preferences page, parameters 28 and 29 may have had their values reset, as they had no selection listed despite reading as default before. Under the dropdown for "Z-Wave Ramp Rate to Full Off" (#29), one of the selections that should probably read "Instant Off" is instead listed as "Instant On."

I've been messing with my Zen04's. I noticed the Pending Changes before also. I think this is part of the temporary nature of the parameter change. If you hit Configure or Save Preferences, Pending Changes turns to "Synced" or whatever, which is what used to be there. I think it's something you want to see when you do the temporary parameter change.

Its intentional, I forgot to add the note on this post like I did for the plugs. Its not that it is not possible to have it change the menu to reflect the new setting, but I thought it would make more sense to keep that the setting so its like your default, and using the command sets a "temporary" change. I could certainly make it override and change the menu.

NOTE: Setting a parameter from the new command is like setting a temporary parameter. The Preferences will still have the old parameter so if you run a Configure it will set them all back how they were saved in the Preferences.

This was due to a change in 1.6.3, the default changed from -1, which was a hack, to the proper value of 255.

Fixed, run a repair in HPM.

2 Likes

I've got a ZEN77, 3.0 hardware, 3.10 firmware, that's showing up as UNK00. I've pressed various combinations of configure, refresh, and refresh params to no avail.

image

Your data section is missing all sorts of info. Did you use the swap apps on this?
Check this post: Two identical sensors, same driver, but different preferences - #14 by jtp10181

I'm confused about when to use the 'Configure' button.

Does 'driver changes' refer to changes to the settings within the driver? Or does it refer to upgrading/downgrading the version of the driver itself?

I'm guessing the procedure is something like:

  1. Change any setting anywhere in the Commands or Preferences section of the Driver's interface.
  2. Click on Configure.
  3. Click Save Preferences.

Am I right? Or did I misunderstand you?

No

Yes

1 Like

Just if you change the driver from one to another, not even needed for upgrading to new versions typically.

1 Like

I just updated my Zen77s from firmware 10.0 to 10.3 and I noticed that everything that is set to come on at a certain % is coming on much brighter. I figured out that it seems like the device is converting my minimum of 10% to be 1% automatically just like the setting in your driver does.

How does the conversion works? Like, if I had the minimum set to 10%, and before I was setting it to 30%... what would be the equivalent? I'll need to go update several rules and scenes. Do I set it 10% of the value lower? Because now.... using 10 - 100, 55% would be 50% now. So 30% would be 27% now? I dunno... it confuses me. Or do I just set it to a flat 10% less? So if the minimum is 10% and a scene is 16%, do I now set it to 6%?

Hm, what firmware was it on before? I dont see anything about that in the posted chagelog.

Its also an optional setting on my driver, it could be turned off, but then if your min is 10% and and the devices is at that level it will show 10% on the dashboard instead of 1% with my brightness correction. Try turning the setting off and see if your percentages seems more like they were before, that will be the real test.

My adjustment just levels the percent out so it always shows between 1-100%, You can see the actual level the device reports in the state variable and also in the event log. Here is an example. my max on this one is 75 because after that it all looks the same. So when the device reports 75% the driver converts that to 100%.
image

I will have to do some investigating on my end as well to see whats going on. This is what I would do to test, turn off the brightness correction first so the driver is not interfering. Set the min/max to 1/99 and set level to something like 10. Light should be obviously dim. Then set min/max to something silly like 50/99 and set it to 10 again. What it used to always do was still set it to the same level 10, and the min was only observed when using the paddle to dim. One more test as well, you could set min/max to 1/20 and again set it to 10. If the device is correcting for the min/max you should be around 50% (when set to 1/99) vs the normal 10% which would be obviously different.

It looks like it was actually added in 10.10. I went from 10.0 to 10.3. I'm not at home right now, but I did have the setting off in the driver.

https://www.support.getzooz.com/kb/article/850-zen77-700-series-s2-dimmer-change-log/

Ramp rate is now calculated with the account of minimum and maximum brightness levels (and just 0 -100 only as before)

Thats is not what I understand that to mean, the 10.10 change only states the ramp rate is calculated based on the min/max, so if you set it to 5 seconds ramp it takes 5 seconds to get the MAX, not to 100%.

However, you are correct, it looks like they basically mirrored my brightness correction calculations directly into the firmware. So if you stack the driver brightness correction on top of that you wont ever get to your min/max unless you use the paddle.

Let me break it down, lets say you have min/max set to 20/80 and brightness correction disabled.
Old firmware, If you set the level to 10, the switch sets the brightness based on a 1-99 scale, and returns 10 back as the level. You can actually go below the min. If you dim on the paddle it will stop at 20 and report the level is 20.

New firmware (10.30 for sure). If you set the level to 10 it actually scales it out to be 10% between 20-80 which according to my formula should be the same visible level as 26% if the min/max was set to 1/99. The switch will actually return back that the level is 10%. If you dim the paddle to the bottom using the paddle it will bottom out at the true 20% but it will report that it is 1% since you are at the bottom of the min.

Basically, when you set the min/max you are moving the mark of where 1% and 99% are in the full range the switch can do. This is the exact same thing the brightness correction was designed to do via the driver.

@agnes.zooz if you follow all of that, what devices have had this change and what firmware versions? I would like to put in a check to disable brightness correction on those models since it will cause unwanted behavior.

In the meantime, anyone using this driver on a ZEN77 with 10.30 turn off brightness correction. Any other ZEN7x model dimmer with the current firmware it is easy to test. Turn off brightness correction. Set the Min to something higher than 1%, using the paddle dim the switch to the bottom. If the level is reported as the min you set, you can turn brightness correction on if you want. If the level is reported at 1% the device is already doing it for you, leave brightness correction off.

1 Like

I have a Zen23 that is not detected, It says unknown.

fingerprint mfr:"027A", prod:"0000", deviceId:"0000", inClusters:"0x5E,0x86,0x72,0x5A,0x73,0x85,0x59,0x25,0x27,0x20,0x70"

Received Version Report - Firmware: 20.15
Set Device Info - Model: UNK00 | Firmware: 20.15

I have 2 of these they are the first ones released I think. The other Zen23 I have is also running firmware 20.15 and its detected. Any ideals?

Update: I also have some Zen21s that are detected as unknown

The prod and deviceid should not be all 0000, thats why the driver is not detecting what it is.
Also, my driver will likely expose many more parameters than your switch is capable of, which will result it in being stuck in "X Pending Changes" on the sync status.

For those old models where the firmware cannot be upgraded, you are actually best off using the built in driver. If you need to clean up some of the extra info my driver created switch to the "Device" driver and use both command buttons that clear the states.