The long awaited ZEN16 v2 is here where the inputs can be separated from the relay contacts, and they can be set as sensor inputs to change what notifications the device sends out.
So... I am working on a driver (of course).
Looking for feedback on how to handle the sensor status.
I like the idea of a single child device for each Sw/R pair, and just having both attributes on them. This would make it easier to implement and also if you change input types the child would not need to change. One drawback of this is if you use the input and relay for totally unrelated things (ie leak sensor and garage door control) there is only one device to set a name on.
The other option would create 3 child devices for the relay status, and then optionally if you set the input to a sensor type, a new child would be created for that sensor. This has the advantage using system component drivers and you can set the name independently. Code will be a little more complicated but nothing I can't figure out. Each time the input type is changed the sensor child would need to be removed and re-created (driver will handle this).
Custom child driver that has relay (switch) status and sensor status (3 child devices total)
Extra child device for each input set as a sensor (up to 6 child devices total, this is how ZEN17 system driver works)
Other (explain in reply)
0voters
I actually have an idea where I might be able to virtually de-couple the input/relay on the ZEN16 v1 as well! Mine is currently on my garage ceiling so I will have to test it with the new driver once its done.
Thanks for taking this on, Jeff! Until earlier today, I didn't realize this new guy was out either (sneaky Zooz!), and I'm now trying to compare advanced config options to the Z17... I'm curious to see how this works out in the wild.
But as of today, winter has arrived here in MN, so I think I'm done monkeying around with this kind of stuff out in my detached garage this year, so if this is looking more & more like a spring project for me.
ETA -- I think my vote is for option 2, since I'd like to use the 3 sensor slots for 3 different dumb reed contact sensors within the garage, but I'd only be using one of the 3 relays for my actual GDO (other 2 relays not used at all).
Dang this thing has soooo many settings. So tedious adding all the preferences.
I think I do have a game plan for using separate child devices (in my head anyway).
If this works out, I should be able to easily port this to the ZEN17 and replace my companion driver with a fully functional driver.
Can anyone make sense out of this? It looks like both option 1 and 2 are doing the same thing as far as the switch reports go. I get the difference between 0 and 1, the NO vs NC makes sense and works as expected. Everything in the ( ) after each setting makes no sense...
Parameter 21: Decide whether you'd like Relay 1 to be normally open (NO) or normally closed (NC).
Values: 0 – normally open (relay reports off when it's open / switch is off and on when it's closed / switch is on); 1 – normally closed (relay reports off when it's open / switch is on and on when it's closed / switch is off); 2 – normally closed (relay reports off when it's closed / switch is off and on when it's open / switch is on). Default: 0.
Here is my current solution in the driver (See Docs aka I have no idea what this does)
Ha, yes... I'm struggling with understanding both those (21-23) and 12-14.
It seems 12-14 are the options to separate the relays from the sensor/switch inputs, but what's up with the 2nd sentence in the intro blurb here -- am I on crack or is that not saying the relays and switches cannot be independent? Is that an unintentional fragment left over from the v1.0 hardware? Confused...
And for 21-23, I have no idea what's up with that 3rd option - it's headache-making lol
Overall, I wish Zooz had instead just made a 3-relay/sensor version of the Z17 instead of stuffing these changes into the old Z16 form factor here. I feel like this route is just going to result in massive confusion for Zooz trying to manage v1-vs-v2 resources -- these are now 2 very different devices in terms of options.
But if they just made a 3x version of the Z17 instead, it would be a ton easier to keep documentation and resources straight.
Probably, I am just ignoring that since I have the device right here, I am seeing what it actually does. I do have the ability to get just the sensor status and it is easily separated from the relay status the way it comes in.
Its actually not that bad, I think I might be able to make this driver reverse compatible to v1 ZEN16. The ZEN17 has all the extra input options and also both NO and NC contacts for the relay, so it is a distinguishably different product, more advanced. With the number of connection points the Zen17 would need to be quite a bit larger for one more relay. The ZEN16 is more basic and because of that is more compact and 3 relays fits into about the same form factor. Really what they did was extend the most popular option on the Zen17 over to the Zen16. I think it was a good move.
I thought this driver would be a huge headache but with the work I have done recently on the Plugs driver with multichannel stuff it is making this a breeze. I am actually almost done (I started it today), just working out the creation of the sensor child devices.
Right on - that perspective makes good sense - thanks for that additional color.
I'm just glad to hear it's all steadily falling in place for you -- it's a major confidence boost knowing you've put it through its paces!
I think I'll order one up now -- we'll probably get another warm break sometime in Nov before winter really sets in, so I suppose I should be ready to capitalize. God knows I'll otherwise just be jonesin' to do it all winter lol
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???
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?
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.
@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.
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!
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!
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.
