I threw out the fact that other vendors appear to use Group 4 and do association differently in an attempt to get them to make direct associations working in a true 3-way setup like other vendors seem to.
All of that could have been avoided if they had a matching remote.
I have had no luck with associations but to be honest it was probably the way I set things up. Found it to be too slow in some cases (beyond 3-way), didn't like the "popcorning" of the relays and sometimes switches would get out of sync. Once I shifted to button only / smart bulb mode for the ancillary switches things started working much better.
@Ken_Fraleigh I found a bug in the v3 wanted to see if the V2 has it also. When I command the relay button from the hub, the reports the device sends back tell the driver that the relay switch AND the main toggle dimmer have both turned on/off. Have you noticed this on the V2 at all or can you test?
This update is all about the ZEN30, merging all prior updates in with the ZEN30 driver! I had a few updates hiding in the ZEN30 that I merged back to the switch and dimmer also. Tested with ZEN30 v1 and v3 hardware.
The ZEN30 v3 has a firmware difference which may cause both the dimmer AND relay to be set to the same status after controlling the relay button via the hub commands. This is tested and accounted for in this driver update.
Added support for the new ZEN30 parameters also, see the Zooz docs for more info:
Zooz ZEN30 Changelog
Zooz ZEN30 Advanced Settings
Many of you will start seeing Bad manifest for Zooz Switches Advanced Drivers from an HPM update. Now that the Unmatch feature is in there I was able to finish moving my manifest to a new spot on my GitHub. If you get this error go to HPM Settings > Unmatch and unmatch this driver. Then do a new matchup to get on the correct manifest file.
HPM fails on the new update installing the 3rd driver zen30 then rolls back.
I tested it last night and also just ran a full repair, works fine on my end. Are you on current hub firmware its possible I added something not supported on an older firmware. Also, check the logs, it might be generating an error in there.
I am on .135 on a C-7. I have 1-Zen30, 6-Zen71 2-Zen72. Just received today 22 more 700 series switches. I will be busy this weekend. Anyway I even changed the driver of the one Zen30 back to the HE driver and it still failed. Again it installs the first two and crashes on then Zen30 driver install and then rolls back.
They are on firmware .138 now, there is a slight chance something I changed recently did not work on .135, might be a simple syntax thing.
You could try a repair in HPM but might do the same thing.
Next would be to try manually installing the code, you can go in and edit the ZEN30 driver code, hit import and put this url in there for the import: https://raw.githubusercontent.com/jtp10181/Hubitat/main/Drivers/zooz/zooz-zen30-double-switch.groovy
If the code has an error preventing it from installing, it will give you details at the top. If you tell me the error there I can then see what the problem might be.
Imports fine from the raw link.
I was able to get it installed manually. Then upgraded to .138, ran repair in HPM and after that all is perfect.
Thanks
Did you install over top of the existing driver or add a new instance? If you added a new one outside of HPM make sure each driver is only in the driver list in the hub UI once, and you may need to run the "unmatch" in HPM and then re-match it just to make sure future updates get applied correctly.
Nothing too exciting, mostly just reorganized the code so I can more easily sync changes of some functions with all my drivers. Found a couple of bugs during testing. More to come on some other projects.
Forgive my ignorance but I don't see what I'm looking for in this thread or elsewhere.
I've got Zen27 and have set Smart Bulb Mode - Local Control (#15) to Disable Paddle and Z-Wave Control (2) AND Smart Bulb - Dimming when Paddle Disabled (#20) to Report Each Brightness Level (0)
But it seems that holding to dim is changing the actual power level. If held 5+ seconds the device seems to turn off. The only way to get it back on is to pull the air gap (since paddle and zwave load control are disabled).
Am I missing something in the device config that creates this corner case? I'm trying to make the load stay on always but control the Hue bulbs with the dimmer paddle. I'm aware that I could use the Hue remote (which I have) but I'd prefer to have a native looking set up for this.
Using the new Room Lighting app works fine for on/off control with this setup.
I'm controlling the Hue brightness by capturing the level and pushing to the bulb group.
What device firmware and make sure you have newest driver as well, if you use HPM do an update or repair.
I just tested with both smart bulb settings enabled and my lights stay exactly the same no matter which button I press or hold. I see the level change being reported to the hub but light stays, this is expected behavior. My device is firmware 3.04
I'm on firmware 3.04 with your latest driver.
If you press and hold the dimmer down to 0, does your switch turn off?
Just tested again, set min brightness to default of 1 and turned off brightness correction just in case. Holding down goes to 1% and stops, it does not go any further. Not sure why yours is going down to 0% unless it is one of the other settings breaking something.
I updated the ZWave controller firmware on my C-7 and this is no longer an issue.
I didn't realize it was a separate update from the hub firmware itself.
That's really odd that the zwave update fixed that, I never would have even thought to check that. Glad its working now.
I can see why that error might come up but I cannot figure out how you got into this state. First thing I would try is go to the device page and run the Configure command. If it is still throwing that error, if you are able to edit the driver code and on line 181 uncomment the "debugShowVars" command and save. Then go back to the device and run that command, get a screenshot of the log output. Downside is that editing the code should in theory wipe the variable I want to see, and the driver will rebuild it and possibly fix itself by the time you press the button.
Depending on what you find here, maybe I need to add something to Configure that would force the stored parameters list to get rebuilt.
EDIT: Forgot to mention, while looking at this I realized I have some old code that is forcing the physical Ramp Rate setting to be passed in zwave commands. I think this still is OK on the ZEN30 due to lack of settings available. On some of the other switches they just added a bunch of ramp rate settings so I might be overriding that in the driver by sending the duration in the command. I made note of it and will check it out, if anyone notices any issues with the ramp rates let me know.
Download the Hubitat app
