Hi, new to Hubitat -- migrated from SmartThings for all the reasons everyone already knows.
I have a ZEN30 question -- I've read various posts on this thread but still in need of some help.
From the changelog, I am using driver "[1.4.0] - 2021-01-12 (@jtp10181)". I am on firmware version 1.0.7 of the switch. C7 HUB with version 2.2.4.158. I've pasted my existing ZEN30 switch configuration below. Here are my questions:
I have "Dimmer double-tap UP disabed (Parameter 18) and I have both the paddle & z-wave enabled on the dimmer (Parameter 19). Double-tapping on down sometimes comes in as a button 2 push instead of a button 4 push. Is the issue the way I am tapping, or is this a known issue of some type?
Tap-and-hold on either paddle reports the correct button number and event, but... If the light is already off, and I do a "tap-and-hold" on the down-paddle, it turns the light back on. I do not have an automation that is causing this -- it is being done by the switch. Is this considered "correct" behavior? Is there some way I can prevent this from happening, other then by disabling the physical dimmer paddle? My ZEN26s do not exhibit this behavior, but they aren't dimmers :-).
Thanks for any help or feedback you can provide and for all the great reading I have found out in the many posts on this community forum!
For the ZEN30, button 2 is a down 1x tap so it is not registering a second tap. I noticed in testing as well it seemed to be more picky than the other switches for registering the multiple taps. There is a point where it feels like you are pushing the paddle in but it has not clicked the trigger yet, so that might be the cause also. I noticed the paddle on the ZEN30 has a different feel than the other ZEN2x switches.
For the down button hold, first thing is turn off the night light mode, that is activated by a down hold which turns the light on at the percent set. I tested on a ZEN27 and found with the night light mode off, you have to hold it down significantly longer before it turns on (at the lowest dim level for me). But a quick hold and release did not turn it on for me. I don't have my ZEN30 in the wall yet and its not connected to my test rig at the moment.
Both of these issues you could also report directly to Zooz on their site, the first one might be hardware related, or they might be able to adjust it in a firmware update. The second one could be intentional by them or maybe an oversight where it turns on even if night light is off and then they could fix in the firmware.
Brilliant! That solved the problem. Holding the down-paddle no longer turns on the light, & now that you point it out, it makes sense.
I feel like I have had the same experiece. Now that I can use tap-and-hold, double-tap reliability is not a concern for my use-case anymore. I was only using double-tap because of the problem with "tap-and-hold".
I have a follow-up question. I have both ZEN26 and ZEN30 switches, all on latest firmware. I am realizing now that I have 2 copies of your driver from different points in time -- see image below.
The change log on the ZEN26 driver shows "## [1.3.1] - 2020-12-29 (@jtp10181)".
Should I actually be using both, or is the one named "Zooz ZEN30" actually a unified driver for both devices?
Thank you again for the great work and the fantastic help!
The ZEN30 has its own because of the child device its easier to keep it separate. The ZEN26 I merged all the switch drivers into a unified one which you could update that driver directly by overwriting it with a copy/paste. Also the Package Manager should match it with the new one and update it also, at least that was the intent when I setup the json file. Unified for regular switches: https://raw.githubusercontent.com/jtp10181/Hubitat/main/Drivers/zooz/zooz-zen-switch.groovy
@jtp10181 - Firstly thanks for the amazing work on the drivers.
I'm using your Zen30 driver and have sort of an issue using button controller.
From the posts above I see that a double tap registers as button 3 and 4. However, in Button Controller, I'm not able to see them as options from the drop down. Any ideas as to why this would be happening ? Screen shots below.
I can tell by all those extra state variables that you have not pressed the configure button since switching to my driver. I suspect the "numberOfButtons" attribute may not have gotten set correctly yet because of that. So trying doing the configure, and then check the Current States in the top right for the numberofButtons, should be 10.
When installing the advanced driver for the Zen30 should the Type listed for the Relay be "Generic Component Central Scene Switch" it would not let me change it to the new driver.
Also, for the parent device, should the syncStatus say 1 Pending Changes. I noticed the example above said synced.
Yes I am using that generic driver for the child device since it does what is needed. No sense in making it more complicated unless needed.
If you have a pending change, try hitting Save Preferences to sync it up. Also do a Configure if you have not done that yet. If it wont go away turn on the debug logging and do a save again, post a screenshot of the debugging messages from the logs and also a screenshot of the Device Details > Data section at the bottom
NEW VERSION 1.4.2 - see changelog for full details
Added command to change the indicator color for models which support it. You can change the color from Rule Machine to give you a visual alert (ex Doors unlocked RED, Doors locked GREEN). Make sure you also set the LED to be always ON so you can see it if the light is on or off.
Came up with a better way to test and disable unsupported parameters for older firmware. If you have firmware at or above the minimum supported you should NOT need these new commands!
Param Commands > Hide Invalid - this is quick and just hides the ones that are not responding at all but does not work for all firmware.
Param Commands > Test All - recommend turn on debug logging FIRST and have log open in another windows. This will test each param one at a time, takes 1-2 seconds per parameter. When it is done it will hide all that failed the test. Reload the page to see.
Param Commands > Clear Hidden - if things got hidden that should not have you can clear it with this and try again.
The switch would not function when I tried to maually turn on the dimmer or the relay. I had to cycle power at the breaker and I remove the advanced and installed it again and everything is working now. I also installed the new version of the driver that came out today. Thanks for your help.
My Zen30 has stopped working 2 time when I use this driver. It will not turn on or off at the switch or using Hubitat. When I press the dimmer paddle or Relay the Leds on the switch turn on or off but the lights connected to the switch do not turn on. I need to cycle my circuit breaker to get them working again. Do you know what is causing this?
If it wont even work with a physical tap it sounds like a hardware/firmware problem. I cant think of any way the driver would cause it to lock up. When its stuck did a physical press on the switch change the on/off status in Hubitat? Also instead of the breaker you can just pull the air gap out to kill the power to it (it is to allow you to safely change bulbs due to the dimmer). Its the tiny little piece below the relay button if you hook a fingernail under it you can pull it out slightly to cut the power.
I feel like mine has done this before also but its just in a test rig on my desk and I keep sending it tons of commands so I figured I did something bad to it. But maybe there is a hardware or firmware issue causing the problem.
I do not have the zen30 but I agree with @jtp10181 that this sounds like the switch is getting itself into a knot.
I have had similar issues with zen26/27 and more recently with a zen21.
Zen26/27 - all issues were attributed with not having enough load to keep the switch happy. With the zen30 I see there is a relay for the fan so that won’t be the issue. What is the load on your dimmer. Can you confirm that your led bulbs are rated as dimmable? If not, they may not pass enough current in the off state to keep the switch happy. How often is you switch getting into this mode? Could you temporarily replace one of the bulbs in the fixture with an incandescent bulb to see if it solves the issue. Or connect an Aeotec bypass or other load resistor across the fixture load.
My zen21 issue was self inflicted. I was already using one to control an exhaust fan so I put a second one in my ensuite driving two smaller exhaust fans. Every few days the switch would become unresponsive (usually after power on) and I would have to power cycle (no air gap on the 21). Adding a snubber circuit (I decided across each fan instead of at the switch) has fixed my problem. It’s been good for about three weeks now.
So all issues were attributed to external connections and nothing with the actual switch.
I have (3) 18w LED bulbs on the dimmer and they are rated as dimmable. I have had the switch in use for 1 week and it has become unresponsive 2 times. I will try to see if there are any issues when using an incandescent bulb. I will also try to get a firmware update to see if that fixes the issue.
@jtp10181 thanks for telling me about the air gap. I was not aware I could use it to kill power to the switch.
I'm having the same issues on my ZEN26, ZEN27, and ZEN22 switches. Same behavior, switch will freeze up. Pulling the disconnect reboots the switch to normal operation. For the switches w/o the pull out disconnect I have to flip the breaker.
I'm skeptical to think it's the load, I've see the issue when I have 10 x 6w LED bulbs at the fixtures.
I'll reach out to Zooz. I'm running the 2.08 firmware on the Zen26's, 3.0 on the ZEN27's, and 3.07 on the ZEN22's.
Were you having this issue with the standard driver also? Could try switching one device to the standard and see if it still does it. Also make sure you have my newest driver. There is one thing I had in 1.4.0 and changed in 1.4.2 that maybe could cause an issue. The 'refresh' command was refreshing all the parameters, I did not realize that refresh could trigger on its own periodically. If this triggered on multiple devices at once it could possibly jam up the zwave network due to all the commands.
