Yup. For sure all the zooz mosfet based switches need that constant load even when they are off or they loose their minds.
That's an interesting thought. Thanks for the info - it's helpful. I am still experimenting. My first mistake was adding all device DNIs in the group to all the device's associations - that was festive and chatty.
After that I set the switches to just associate with the dimmer and then only the dimmer associate with all the switches. Worked much better...
Oh I did that at first as well - lol. Although my situation is simpler with just two switches.
Now I just have the one switch with the second switch listed as a group two association.
I'm not sure how well it's going to work but we'll see - just implemented last night. The other things I've tried have had their quirks - mirrorsync, RM rules, Node-RED Sequences etc. Of course when I say "quirks" I really mean MY ability to properly set things up not necessarily the underlying systems.. At least with the associations it's as direct as possible.
I haven’t tried mirrorsync before. I have used “switch binding” successfully for a long time between a virtual switch and a Zen27 when I was having issues with Alexa telling me that the switch was not responding. I only removed that about a month ago since the Alexa skill now has the option to respond without waiting for the device to respond.
In my workshop I have the lights split on two switches - seemed like a good idea 10 years ago when I wired them up. Maybe four or five minutes ago I put in two zen26s and put the association in right away - same setup, paddle only, and it’s been 100%. So it can work. But again, just two switches so a simpler setup.
UPDATE New Version 1.4.4 Published
This version adds full proper supervision support as outlined in this staff post: [GUIDE] Writing Z-Wave Drivers for S2
I would consider this experimental at this time, it is disabled by default and has a toggle in the preferences. There are certain Zooz switches which do not properly respond to the supervised commands. The ones I know have issues are the ZEN21, 22 and 26. The ZEN27 is confirmed to be working working with it as well as the ZEN7x series. Zooz is aware of the issues and working on firmware updates. I have been using this on all my devices which behave correctly for a few weeks without issues.
WHY you might ask? Mostly for proof of concept. I think the supervision is more useful for critical devices such as locks but wanted to see how it would work.
Firmware Updates: I am aware of some new parameters in firmware updates from Zooz, notably the 10.x firmware for the ZEN7x devices and also 3.04 for the ZEN27. If you have a ZEN7x switch and want to use the 3x up or down taps I would recommend requesting the update and info about the new parameter. It allows you disable the inclusion/exclusion mode 3x tap function which I found were conflicting with the scene button events on the 7x switches. You will have to use something like the Basic ZWave Tool HubitatPublic/basicZWaveTool.groovy at master · hubitat/HubitatPublic · GitHub custom driver to manually set the parameter at this time.
I plan to include new parameters as options in the next version, I need to re-write the entire parameter handling code so it is easier to maintain with all these different models and versions. This will also allow me to better support backwards compatibility for older firmware without the "Pending Changes" issues.
This is great! Whoever at Zooz decided that there would be no way to disable this obviously did not test the switches with toddlers. Now if I can just disable changing all preferences through taps on the switch that would be great. About every 3 days or so my toddler figures out how to make the LED indicator light turn back on for the Zen21 in the bedroom and I go to bed only to realize my whole room is being lit up.
The new parameter disables this also. Basically it disables all the "tap" settings changes besides factory reset and a few other. Here is what I got from Zooz on the ZEN27. So far I only have an update for the ZEN27 and all the ZEN7x models. No ZEN21 yet unless they are keeping secrets from me.
Disable programming from paddle
0 – programming function from paddle enabled (switch will behave according to the documentation for paddle press)
1 – programming function from paddle disabled (switch will NOT perform the following paddle press functions: 2) exclusion, inclusion, 3) change LED indicator mode. Switch will still perform functions 1) on/off, 4) factory reset, 5) range test tool and central scene triggers (if central scene enabled).
That's great to hear. Hopefully @agnes.zooz can tell the engineers that we would love this parameter to be added to all their switches. I recently updated a couple of new Zen77s to version 10. I need to see if there are firmware updates for any of the other switches I have.
We're working on it so if your switch supports OTA, then this should be available for your model shortly.
Thank you! My toddlers are always changing the settings at the paddles. It's annoying to fix too because it doesn't seem to report back to Hubitat that a setting changed so they become out of sync.
Same here! Toddlers are outsmarting my smart home!
@jtp10181 I have a feature request if it's possible. I want to be able to set the dimmer level without actually turning the light on so that the next time it's turned on, it goes to that level. This is apparently called pre-staging and is device dependent. So I'm not sure if the Zooz devices support pre-staging or not.
Run the Param Commands > Refresh option to refresh all the parameters. Then if something got changed it should show "Pending Changes". Then just hit configure or save at the bottom and it should push back your settings and sync it up again.
If you wanted to get really ambitious you could probably even automate the refresh daily and then have a notification pushed out if there are pending changes!
Yeah I have seen talk of this on other devices. I will have to see how it is done in the driver exactly. The Zooz switches turn on any time you set the level to anything but 0, so I think that prohibits it from working in the desired fashion. Might be possible though to stage a level on the driver and NOT send it to the device, and then as soon as the device is turned on send the level immediately. Side effect would be it would probably see it go to the default/previous level then quickly change. I think you could do this with a rule also.
Hi Agnes, since the 7x series is all new, there is no reason for you to limit FW availability like the 2x series correct?
So will it be downloadable from your support site without a support ticket being raised?
At the very least, maybe it could somehow be hard-coded into Hubitat, so you can just push "update" button, and it automagically fetches the newest version.
We don't currently have plans to publish the firmware for any of our devices but we have already supplied HE with the files so just waiting for them to be uploaded to the platform to make the process quicker and easier for everyone.
Wow, that is great! Probably will be a relief for you to not get 100 firmware updates at a time when someone posts on here that they are available.
Thanks again for doing this.
Maybe this is an upcoming feature? As far as I know right now the user has to manually supply the firmware updates for the Firmware Updater app available on the C7. For any other Hub the user has to use a driver and provide an URL to the update file.
Right now, the only way we know about the Zooz updates is if you post a changelog, or typically it is discovered by someone on this forum posting that they were given a newer version from Zooz support and there is not a changelog posted
That is awesome thank you for this!!!!