I just got a new Hubitat C7 and a handful of Zooz switches, ZEN21 and ZEN27 to be exact. Found out the posted custom driver to access the advanced settings does not work with S2, which is an easy fix actually. But, I found this driver that Zooz links to for SmartThings and I like it a lot better, code wise and the log messages. It is really well written code from what I can see so far.
So, from the looks of it this if an official Zooz driver as it says it is copyright Zooz 2020. Should I reach out to them about posting forks of it? I should just read the Apache license also since I am not super familiar with it.
Anyway... I already have ported it to Hubitat and have it installed on my hub for some testing. Fixed a few bugs I found as well, which I will probably report upstream eventually. I hate to do all this work and keep it to myself as this driver to me is much smoother than the other custom Zooz driver. What's a recommended course of action here? Any issues posting it as a new release even though there is already one for this switch posted?
My understanding is; as long as you keep the original license, credit to the original author and document that you have revised it, you are free to redistribute the code.
My belief is the license has two basic goals:
Not allow others to charge for the code
Not allow others to patent any portion of the code.
Suggestions needed!
I am getting deeper into this trying to test out the "scene" functions which can be anywhere from a 2x tap to a 5x tap up or down. Not sure the proper way to handle it in the driver, and also how to capture it with the rule machine (or anything) so I can act on it. The ST driver is set for 1 button only and it sends events with name "button" and values like up_2x or down_4x, etc.... The other custom zooz drivers posted for Hubitat have it set to 8/10 buttons and for a 4x up it would send name: pushed value: 7 (for button 7). I think I am leaning towards using the button numbers because thats how zooz documents it. Also it seems like the rule machine is setup to handle this easily, where-as I am not sure how to capture the "up_2x" event after some initial poking around. I just dont want to re-do all the code if it is fine how it is. Trying to keep this close to the ST driver if possible so any updates on there can be merged with mine.
I think sticking with the Zooz-mapped button #s is the best route. It's all documented and there's a lot to be said for maintaining consistency. Yes, it breaks with consistency from the ST driver, but the device manufacturer specifies it this way... seems like once you're done someone should back-port to ST so they have a driver that matches Zooz docs. Also, it will work with RM this way (a big plus).
Thanks that's what I suspected. The way it is now with the 1 button and custom values can it even be captured in the rule machine (easily)? Maybe it is something that works ok in ST but not in Hubitat. I did see that Hubitat depreciated the "Button" capability and changed it up so maybe that's where the difference is. I see lots of custom tinkering in my future so trying to do it "proper" from the get go. My wife rolled her eyes when I said I got a new toy I could program.
On Hubitat, "button" is not an event name at all. The event name is "pushed", the value is the button number, and you don't need data. So that would be:
Also, "Button" is not a capability on Hubitat. You have "PushableButton", "HoldableButton", "ReleaseableButton", and "DoulbeTapableButton" (sic.), depending on what events of "pushed", "held", "released", and "doubleTapped" you do. The Zooz can report all of those, but it's a matter of how you want to report everything since I think they support 3 taps and Hubitat doesn't natively (I like to do odd numbers for up taps, even numbers for down taps, and ignore doubleTapped since it doesn't help, with held and released having their usual meanings, but that's just me).
Driver porting is usually easy, but the button thing makes it a bit more involved.
PS - Someone (now a staff member) already wrote a Hubitat driver for this if you don't want to use the built-in one and wanted to start with something that's already written for Hubitat:
(Off the bat, it just looks like it would need minor modification to work on a C-7 if paired with S2, but on a C-5 or with either S0 or no security, it should be fine. I'd replace either the contents of the two secureCommand() methods with zwaveSecureEncap(cmd) or just replace all references to them with the same. The built-in zwaveSecureEncap() method accepts, like both of these methods, either a Command object or a "formatted" String command and takes care of everything for you if S0/S2 is used.)
Thanks I had figured most of that out with some research but its good to see confirmation that I was going down the right path. I started off using that driver you listed below but I didn't like the way it was logging things among other stuff. I found this ST driver and liked the structure of the code a lot better so I wanted to start with that. I am using the one from Bryan as a reference and also the Hubitat example CentralSceneDimmer (I will have to give credit in my notes to both).
@dsegall posted in that release thread thread an updated driver which works on S2 and he added some of other missing button functions as well already.
I did stumble across in the firmware changelog about the zwaveSecureEncap so I had already put that into the driver from dsegall when I was originally messing with that driver. I have it in the ported ST driver as well that I am working on.
Got all the buttons working correctly per the Zooz docs and programmed some stuff on the down double tap (IMO great for setting your favorite dimmed setting somewhere between nightlight and full on).
I think it would make sense for the doubleTap since Hubitat has built in support for it, to also send the doubleTapped event. For example a down double tap per Zooz should report button 4. The regular down single tap, hold and release all report on button 2. I think to make it easier to create rules I should add a second event for the doubleTap and send both pushed 4 and doubleTapped 2? Any thoughts? Then you could use either one when making rules, just dont use both I guess.
Or is there a way to "name" the buttons so that in the rule manager it could be selected as "down_2x" instead of "button 4"??
You can't "name" buttons, unless you wanted to create custom attributes (a change in which is, by definition, an event), but then it wouldn't be usable in Button Controller and other apps that expect the standard button events.
Whether you make two taps down be button 4 pushed, button 2 double tapped, or both is up to you. I personally don't see the need to generate two events for the same real-world action; you only need one to make it usable in Hubitat, and then the other just clogs your history with things you aren't using. For double tapped in particular, it should be noted that Hubitat's button model doesn't let you specify which button numbers support which actions, so if you habe a a device that supports four or five taps, for example, and are using button numbers as high as 10 or more to accommodate all of those events, apps like Button Controller will offer "double tapped" choices for all of those, too--not a problem since you can ignore them, and not a unique problem since it also happens with "held" and "released" (only suported on buttons 1 and 2 under this numbering), but one that I figure doesn't need to be made even worse. But what you do is totally up to you and your preferences.
But what you do is totally up to you and your preferences.
