[DRIVER] Zooz ZEN Switches Advanced (and Dimmers)

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.

Just ran across this while searching for a solution to "UNK00" - pressing "refresh" in the Z-Wave screen caused it to properly discover the model.

It's a ZEN73 FWIW.

1 Like

Hello, I've got V3 Zen30 that doesn't like to refresh its status after a rule turns it on or off. I can go to the device page and manually refresh it but it doesn't do that on its own. Any ideas?

Turn on debug and run a configure. There should be a log message about the lifeline association being set, which should be there but worth checking.

The only other settings that could prevent it from reporting are the "Smart Bulb - When Paddle Disabled" settings. If you are using the smart bulb mode at all.

What firmware do you have? Its also possible whatever version you have is not sending automatic reports when the status changes.

Also what security is it paired with? You can see it on the zwave details page.

Lifeline association is there, no smart bulb mode in use, firmware version shows 3.10 on the device page, and it's paired with no security.

If you press the buttons physically does it report the status to the hub?
I have a ZEN30 v3 on same firmware, 3.10. Just tested mine from hub and physically, everything seems to be working as expected for me.

I think the most likely possibility is it is a zwave mesh issue, the commands are able to make it to the device but the return trip gets jammed up somewhere and is not making it back consistently. The other possibility is it is sort sort of hardware/firmware issue. Possibly a combination of parameters causing an issue. You could try setting a lot of the parameters back to the defaults and see if that makes any difference. Otherwise you might have to open a case with Zooz.

Now THAT explains why my ZEN77's brightness levels were all different after upgrading the FW from 1.03 to 10.30!

It was driving me NUTS and I had to set the brightness levels on the dimmers and in my Room lighting rules! They were WAY too dim.

I guess I will turn off the correction and test and reset them AGAIN.
I went through alot to determine the correction factors for the dimmers and had them set pretty good, for me, then the FW update messed everything up.... RATS!

Anyway, gives me something to do.....

Does this mean I fixed something or everything is/was fine?

Lifeline Association (MC): [[nodeId:1, bitAddress:0, endPointId:0]]
Lifeline Association: []
...
Adding missing lifeline association...

Probably it just had not detected the association yet, so it tried to set it and then discovered it was in fact set. If my driver had set it, I think it would do the regular association not the multi-channel.

A missing lifeline association would have the symptoms of the devices acting on commands but never sending any voluntary status reports back to the hub unless the hub asks for it (such as a refresh).

Hello @jtp10181
I've just purchased the few of the (very new) Zen54.
These are a very unique, in-wall relay that serve as a dimmer, not as a switch.
(Strange, after I purchased them, they were apparently taken off THESMARTESTHOUSE web site....)
Will one of your drivers work for this device?

If I have one I can make a driver for it (possibly even without one). I think Zooz also sends all new stuff over to Hubitat so they can make drivers. They have been known to send me stuff as well with a request to make a driver for it. Have not heard anything for this one yet.

It looks very similar to the ZEN51 but for dimming LEDs. I could probably take my ZEN51 driver and adapt it to the ZEN54 without too much trouble.

I also sometimes have the issue of the light or fan reporting the opposite of what it actually is on a particular Zen30. It's one of the newer V3 zwave 700 series ones also on firmware 3.10. I never saw this until I setup a room lighting automation to turn the fan and light on and off with motion. I think there is a potential issue with sending both the switch and relay commands at the exact same time.

Most often it seems to be that the fan doesn't turn off, but the light does. If I look at the device page, it'll say both are off.

I was wondering if the driver has a way of integrating a small delay (maybe as a configurable setting) if a command is sent to both within a very short time frame. I don't have any logs of when this has happened to share. It usually goes unnoticed or is noticed well after the fact when passing by the room. It also doesn't happen super often.

EDIT: Oh, and if it matters I am using your custom driver for the relay so that Google recognizes it as a fan and not a light.

I am going to have to start logging issues on GitHub. Too many little random things for me to keep up with in the threads between all the drivers.

If you have reported any issues or even feature requests and you use GitHub please add it as an issue. Otherwise I will start adding stuff myself.

I could add a feature to force a slightly delayed refresh after an on or off command is sent? That is probably the easiest fix. It would be an option you can turn on if having this issue.

1 Like

Well I was messing around with my Zen30 v3 today and noticed that the deviceModel shows as UNK00. Tried the data edit route but it won't stick after hitting configure on the driver. Does anyone know the values for deviceId and deviceType for this model? Also, the deviceModel should be ZEN30 right? Or is it something different? Any info would be greatly appreciated!

Use this driver: [RELEASE] Z-Wave Universal Device Scanner
Press the "Get Info" button, it will ask for the info from the device and put the "data" back in place how it belongs. Then switch back to the ZEN30 driver and run a Refresh, then Configure. Refresh the page you should have all the options back again. You may need to adjust settings back to how you want it.

Also, for any ZEN30 users, I have found out a possible issue with the lifeline association on some models. If you have issues where the relay button presses register as the main switch I may have a fix coming for it very soon.