Zooz ZEN77 Advanced Driver issue

I have many Zooz 77 dimmers. I like to have them set up so that a single tap turns to full brightness, and a double tap turns to a pre-set brightness. I've done this by adjusting parameters 12, 18, 25 with the Advanced Driver (v1.5):

The issue I'm having is that when I double tap, the light first goes to full brightness, then dims to the set level, instead of turning on directly to the set dimmed level. This is really annoying at night, since I use the double tap to go into rooms where I don't want to turn the light to full brightness.

When I change over to the built in Zen77 driver, it behaves as it should (single tap to full brightness, double tap to pre-set dimming level). Contrasted with the Advanced driver behaviour on double tap that first turns it to full brightness, then dims to the pre-set dimming level.

Is there something I should change, or is this a driver issue?

I should note that I also have a Zen72 dimmer, with the same settings, and same driver. It behaves as it should. The Zen77 does not.

The reason I don't keep it on the built in ZEN77 driver is that the built in driver causes a different problem: The switch status on HE doesn't update when a physical button is used to turn the light on or off. So it was disrupting my automations reliant on conditional expressions using switch on/off status. The Advanced Driver fixes this. But then causes the above dimming issue! Very frustrating.

Which advanced driver are you using? If it isn't a built-in driver, you should probably put this in the thread from the driver author.

1 Like

Hmm, good point. I will crosspost it there. It is v1.5 of the one by Jeff Page, jtp10181.

I'll keep this post live as well. Hopefully someone can comment on the built-in driver not updating the switch state with physical button pushes.

Should have just tagged me so I saw this, but I have already replied to your post in the driver release thread. [RELEASE] Zooz ZEN Switches Advanced Drivers - #263 by jtp10181

1 Like

With the help of Jeff, I've properly examined the behaviour.

The Zen77 switch actually has the same problem with both the built in driver and with the Advanced driver. A double tap seems to be registered as a single tap first followed by double tap:

Desired behaviour:

  • Single tap: Full brightness
  • Double tap: Custom brightness (set by param18)

Case 1:

  • ZEN77 dimmer with driver: Zen Dimmer Advanced v1.5:
  • Behaviour:
    -- Single tap: turns on to full brightness
    -- Double tap: turns on to full brightness, then immediately dims to custom brightness level.

Case 2:

  • ZEN77 dimmer with driver: Zooz Zen77 Dimmer
  • Behaviour:
    -- Single tap: turns on to full brightness
    -- Double tap: turns on to full brightness, then immediately dims to custom brightness level.

Here's an example of it working properly with the same Advanced driver and a Zen72 dimmer:

Case 3:

  • ZEN72 dimmer with driver: Zen Dimmer Advanced v1.5:
  • Behaviour:
    -- Single tap: turns on to full brightness
    -- Double tap: turns on to custom brightness level.

I also confirmed again that with Jeff's driver, the switch status in HE immediately updates (desired response), whereas with the built in driver, it does not update until you click "Refresh" (leads to problems for me).

These are ZEN77 dimmers with firmware v10.00, and ZEN72 dimmers with firmware v1.01

Hopefully Zooz @agnes.zooz can shed some light?

Is scene control disabled or enabled on your ZEN72 and ZEN77 dimmers? With disabled scene control it may not register the double tap correctly at all times.


Thank you Agnes for the quick reply! Scene control was disabled on both.

Enabling scene control totally fixed the issue for the Zen77!!! Now turns on to the appropriate dimmed level with a double click. This is fantastic.

Issue was not present on the Zen72 so I haven't enabled scene control there to see if there's a difference.

Do you know why the switch status doesn't update when the physical control is used?

1 Like

It should always report status back to the hub. You may need to exclude and re-include the switch in case it didn't associate correctly on the first try.

The switch status updates correctly when using Jeff's driver, but not when using the built in Zooz Zen77 Dimmer driver. It seems like this would be a driver issue, but you're saying it may be because the built in driver is more sensitive to correct association during inclusion?

It could have been a one-time glitch, the status should get correctly updated whether used with the built-in or custom handler so if you're having issues with the built-in driver after repeated inclusion attempts, please let us know and we'll work with HE to fix it.

Thanks Agnes. I've confirmed the issue on multiple dimmers, both Zen 77 and Zen 72. When using the built in Zen 77 and Zen 72 driver, the switch state does not update when using the physical button even though the light does physically turn on/off. Here's an example of the Zen 77 dimmer

Here's the log of the Zen 77 and Zen 72 dimmers when using their built in drivers. It logs the physical button press, but the state does not update, as seen above.

  • Zen 77 with built in Zen 77 driver (physical button pushes do not update switch state in HE, despite being recognized and physically turning the light on/off)
  • Zen 72 with built in Zen 72 driver (physical button pushes do not update switch state in HE, despite being recognized and physically turning the light on/off)

As you can imagine, this makes the built in driver unusable for routines that depend on reading and acting on the switch state.

@bcopeland is this something that can be fixed in the built-in driver or should we recommend using the custom driver only with our switches for now?

What has changed on these.. Why are they sending basic instead of switch multilevel??

( pardon my unrequested rant... But for God's sake manufacturers stop using basic reporting!!!!!!!! At all. Period. )


As far as I know all the Zooz switches have always used Basic reports when pressed physically, and either Binary or Multilevel when activated via zwave commands. That's is how my driver has always distinguished between the two for the events and logging.

The Zen71, 73, and 76 have parameter 16 where if set to 1 it forces all reports to be Binary reports but I have that forced to 0 in my driver so I can tell which is which. And according to my notes the ZEN72 and 77 don't have this setting anyway.

@JasonJoel is there a reason a device should not use the Basic reporting? It seems to be handy in this instance as long as you code the driver for it.

1 Like

Technically - no, other than it is really generic and not descriptive of what the function is.

Some devices can do basic set on single tap OR double tap depending on how they are configured. So you never know what the basic report is telling you without knowing the device configuration. Not the end of the world, but not great either.

The zwave association explicitly discourages use of basic reports (it is only there for backwards compatibility) in favor of using the more descriptive reporting from the appropriate command class.

Typically to tell physical vs digital, one sets/unsets a flag in the driver - flag ON when the driver initiates a digital command, OFF after event comes in. Then if an event comes in and flag is already OFF, you knew it was a physical command.

But I also have written drivers that used basic reporting when it was predictable/consistent on the device. If it is useful, and the device is going to send it - why not, even though it is a "special case"?

So I guess there is no hard and fast rule on this - more of a style preference, and alignment with association style guidance.

Not always but we had added a different report for physical vs Z-Wave report based on the request from Hubitat engineers specifically :see_no_evil: That was added way back when we released the 500 series S2 switches (ZEN26 and ZEN27) but nothing changed in the way how our 700 series devices report.

@bcopeland let me know if we can send samples to anyone if needed!

Download the Hubitat app