I don't get why companies reuse numbers like this. They could have named it the Zen116, or 16-2, or 16B, 16.2, or just about anything except the Zen16.
Then they complain people are applying wrong firmware. Gee, I wonder why???
2 Likes
I don't plan on buying any of these at the moment, so I am not sure my opinion is valid. But that never stopped me. 
Only thanks to your Zen17 configuration tool is that device usable. Otherwise, you are mostly blindly setting things and hoping it works correctly. There are so many options and when you change types your child devices change, which is quite different than most any other device I have ever used. Albeit you aren't doing this often, the initial setup can be somewhere between confusing and frustrating.
I like the option 2 flexibility, but I also like the ease of the first option where it doesn't mess things up by switching device type. But on the other hand, are people switching device types very often?
So I guess I would slightly lean toward option 2.
That's what I was thinking as well, it should be mostly set it and forget it. If you do change to something else you probably need to re-do any automations anyway.
1 Like
@agnes.zooz Good drivers really do drive sales. For whatever reason Hubitat tends to deliver less than complete system drivers for complex devices or even less complex devices with lots of options. Jeff's drivers make it significantly easier for users take full advantage of the capabilities of your devices. I hope you recognize and value his contribution.
2 Likes
Is there a reason that child devices get recreated when changing configuration? As opposed to just changing the child driver? Would it be useful/worth the effort to create some combo/omni virtual device driver with all the options?
On the plus side for Zooz, they always put out an Advanced Settings doc which has everything you can set. That's the beauty of Z-Wave and parameters, vs Zigbee where you're totally driver dependent for all the bells and whistles, unless you're a developer.
Now, I haven't looked lately, but as I recall, the ZEN16 driver is easy to set, whereas the ZEN17, with the "companion driver", not so much. I think I forewent that approach on a ZEN17, and just set the parameters manually, which is easy enough.
They do send me some sample devices when asking to make drivers, which I get to keep. So they do take care of me. Otherwise I would not necessarily be buying every new devices they come out with just for the heck of it. If anything it would be interesting to know how many people would buy stuff by clicking links from my driver posts.
Using the system component drivers, and there is no way to pragmatically change a child driver from the parent code. I am however planning on making the re-creation an extra step with a toggle setting. The plan is that you COULD change the child device to any component driver with the proper attributes and it would work. So if you don't want to have it get deleted you can manually change the driver. If you don't want to deal with that just flip the switch and the driver will do it for you (delete and re-create). This is the next thing I am going to tackle.
I will of course expand all this awesomeness over to a ZEN17 driver as well!
3 Likes
It's also kinda interesting that they are doing this upgrade as 700... When Zooz first talked about releasing something like this (a year or so ago?) and it didn't materialize quickly, I just assumed they were waiting to go 800 with it.
They must be sitting on a pretty healthy stockpile of 700 chips!
They will probably quietly change it over to 800 eventually. Maybe they were too far down the path with the 700 chip to abandon it?
1 Like
I am about ready to pull the trigger on this driver. Does anyone have a non-critical ZEN16 v1 they could test it on? Mine is on the garage ceiling , attached to my garage door opener and I would rather not mess with it. I think I have this coded in a way it would work fine for both the v1 and v2.
Might have to do the latest firmware on my old Zen16 though and try some refreshes on it at least, see what sort of stuff it sends me.
My v2 is arriving tomorrow, but it would be replacing my Z17 out in my detached garage too... Weather is supposed to be ~50 this weekend (shorts weather again 
), so I'd love to give it a whirl.
But I have a couple family things to deal with, so I'm not confident I can carve out enough time to deal with a swap on that scale.
I'll more likely focus on the new 800 Z15s from the comfort of inside instead, and hope & pray for another warmish upcoming weekend.
Posted the driver in my relays package:
1 Like
Hi Jeff -- posting this update here in this thread vs the Relays Advanced thread just to help keep that more-permanent thread cleaner...
I'm happy to report your driver works GREAT with the new Z16!
Unfortunately, the relay Auto-Off functionality isn't working, but I'm certain that's a Zooz firmware issue - they confirmed it was broken on the Zen17 fw 1.3 too. Z17 fw 1.4 dropped today, and they told me 1.4 will supposedly fix it, but my Z17 was already excluded when I saw the 1.4 fw this morning. I'm guessing they just didn't get that fix in the Z16's 2.0 code. But I'll submit a ticket with them today about that.
I'm just using one relay (R1) for my GDO ("0" value for param 21), but I'm using all 3 sw/snsr options for 3 dumb wired reed sensors - one for GD full closed, one for GD full open, and one for the garage service door.
As we suspected, the "0" value for params 12-14 works great to decouple the Ss from the Rs. I admittedly did not try the "2" setting for p 12-14 - I'm still puzzled by that one, so I'll ask Zooz about it when I tell them about the Auto-Off issue.
At first, none of the sensors were updating and after trying all sorts of reconfigurations & hail-Mary's for longer than I care to admit this morning, I was about to smash the darn thing on the garage floor... But then I noticed your Param 2-4 note about power-cycling the device. And of course, that worked - sensor statuses are all now updating lickety-split 
I also verified that your driver parameters are all setting correctly by comparing the Basic ZW Tool parameter report -- parameters all matched up exactly in both.
This driver rocks -- thank you very much!!
1 Like
Yeah 12-14, Send Sensor Status only is what you want. Not sure what the point of the setting 2 would even be (Send All status but do not activate relay).
I let Zooz know about the power cycle issue. At first I thought something was wrong with the sensor notifications but then since they usually tell you to exclude the re-include when changing those I thought maybe a power cycle would help. Strangely enough it works right using a depreciated command class, which they have in there for compatibility on other systems, but I wanted to use the current notifications class.
1 Like
You've probably already heard something similar from Zooz about the Param 12-14 value options, but I just got this response back from Nikke at support:
Both 0 and 2 disable actual control of the output from the inputs but with value 2, the device will send a report from the input to the hub when triggered as if it was coming from the output even without the output being physically triggered if that makes sense. It's useful only in edge cases and value 0 is recommended for classic decoupling of inputs from outputs.
Nikke also said they'll ask their devs about the Auto-Off bug -- I'll follow up on that when I hear more.
1 Like
We absolutely do recognize it and value Jeff's contributions! We'll definitely look into referral options going forward 
3 Likes
Zooz confirmed that the Auto-Off bug exists, but only if you have the Ss decoupled from the Rs. This was the same bug the Z17 had on fw 1.3.
Zooz implied that's fixed now in the Z17 fw 1.4 (I'm not able to confirm), and they said to expect same fix in the Z16v2 fw 2.1 which they hope to drop before EOY.
The new 16 is still working great!
Hi Jeff,
I'm changing things up on my new Z16, and discovered a minor issue -- not sure if this is driver related or firmware related... I figured I'd run it by you first before asking Zooz.
Long story, but I'd now like to use DC Motor Mode (P24) to deconflict R1 and R2 from being on at same time.
When I attempt to set P24 = Enabled via the driver (and then hit Configure), I get this:
^^^^ this "Pending" message stays persistent through repeated Config and Refresh attempts
If I reset P24 = Disabled via driver, then everything syncs clean and all is as-expected with the logs.
This is NOT a big deal -- it's super easy to work around with tweaked rules, but I'm just curious if you can tell whether or not it's a firmware issue. I'm happy to supply any add'l info that may be helpful.
Thansk a ton!!
ETA - in case it's helpful, here's how my params are currently set up (w/ DC Motor = Disabled):
Seems like the device is not accepting the value of 1, so it just refuses it and keeps it at 0. May be a bug or possibly a built in undocumented restriction from your other settings?
1 Like
Yeah, I suspect it may be something tied to another parameter setting or similar too.
I'll run it by Zooz -- many thanks!
