@jmgregory I noticed your comment of the Zen16 and Zen17 as being similar. They are in that the switches can run the relays but they are different in that the Zen17 switches can be turned into sensors that can monitor things seperately. The Zen16 does not have this capability. Hope that makes sense...
1 Like
Can still use Zen16 to do that.
Either use the Switch on Zen16 directly for the purpose, or create a virtual sensor of the type you want, create a rule to change the state of that virtual sensor when the switch's state changes.
And seems like Zen16 has timer settings while Zen17 doesn't.
I think that can also be used as workaround for your contact sensor issue until there is a fix in the new firmware.
In fact, for my purpose for garage door, how the contact sensor is reporting now is perfect 
BTW, my Zen16 is in attic so can't compare now, but the relay click sounds quite loud on Zen17.
You can use the Zen16 as a sensor as you describe but then you cannot use the relays for something else as the sensor state is sent by the relay turning on. The Zen17 allows the sensors to work independent of the relays also working. Essentially two sensor child devices are created and two relay child devices for a total of 4 where on the Zen16 there can only be two child devices.
Good catch! The Zen17 instructions do say that the relays can be timed just like the Zen16 but those parameters are not set up as configurable in the current device handler. @bcopeland is this something that can be added to the handler?
1 Like
Yes
2 Likes
This looks fantastic! I absolutely love my 16's. "In Theory" the sensor inputs should allow me to put my drop down projector screen on Hubitat and I can ditch the old IR remote.
Finally had some time to get mine wired up out in the garage, but no joy so far... I have a feeling I'm gonna need to wait for new firmware and/or an updated driver. Or maybe I've just completely misunderstood what this thing is supposedly capable of! 
So far, I've wired R1 NO/C directly directly to my GDO, then wired 2 separate reed sensors at S1/C & S2/C to monitor the fully-open & fully-closed positions respectively.
In Hubitat, I'm using "Dry Contact" as the Input Type for R1/2, and I disabled Input Trigger for R1/2 (my understanding is that's what should allow using Inputs separate from Relays?). I excluded re-included after changing my Input Types to Dry Contact.
I was expecting to be able to do 3 things (see 3 devices, I guess?) - to control R1 uniquely (GDO up/down), and get a unique on/off (open/closed) indication for each reed sensor Input (S1/2). But all I get are the 2 childs for R1/R2 - nothing for the reed-sensor Inputs at S1/2.
Likely some operator error involved here thus far, but I'm gonna let the firmware and use-case documentation mature before putting more brain cells against this... It's promising though - I hope I can get this working eventually!
1 Like
This is actually the exact setup I have going and it's working perfectly. After you configured everything, did you get your child devices for the sensors? That's what seemed to take me forever to get created. Not actually sure what made it work, but after switching settings back and forth multiple times, multiple excludes, etc, they finally showed up. So, I have a total of 4 child devices, 2 Relays, and 2 sensor inputs.
EDIT-Just noticed you said you configured them as "Dry Contact", you actually want them to be "Contact Sensor".
1 Like
Ah, I wondered about trying "Contact Sensor" instead - I'll give that a shot! I was concerned that may make it look for a z-wave door sensor or something like that, but it's worth a try!
Man, I'm super glad to hear that I'm not going crazy with respect to expecting separate sensor vs relay inputs - that's great to hear you finally got 'em all to show uniquely!
I'll keep hammering at all variations of the ol' on/off switch (speaking metaphorically), and hope something good shakes loose eventually!
ETA - I realize now how ridiculous it was to say that blurb about z-wave door sensors (um, yeah, dealing with wires here lol) - it's been a long day...
Winning - Contact Sensor worked like a champ - thank you! Finally got my 4 unique child entries showing.
Now I realize what @Levahj was saying earlier about the backwards open/closed status thing - glad Zooz will fix that in an upcoming f/w update.
This is great progress though - this is fun to play around with!
Here is the Virtual Garage Door driver that I used. Works like a champ once you get the rules defined to control it:
/**
- Virtual Garage Door
*/
metadata {
definition (name: "Virtual Garage Door", namespace: "ryan780", author: "ryan780") {
capability "Actuator"
capability "Contact Sensor"
capability "Garage Door Control"
capability "Switch"
command "confirmOpen"
command "confirmClosed"
}
}def open() {
log.debug "open()"
on()
}def close() {
log.debug "close()"
on()
}def on(){
sendEvent(name: "switch", value: "on")
runIn(3,off)
}def off(){
sendEvent(name: "switch", value: "off")
}def confirmClosed(){
sendEvent(name: "door", value: "closed") //added for HE dashboard
sendEvent(name: "contact", value: "closed") //added for HE dashboard
}def confirmOpen(){
sendEvent(name: "door", value: "open") //added for HE dashboard
sendEvent(name: "contact", value: "open") //added for HE dashboard
}
2 Likes
That's awesome - thanks for that VGD driver code!
Are you using this with rules you created (via Rule Machine presumably?) or a community app?
Until I get carve out more time to play with this, I cobbled together a hacky dashboard setup that works OK, but I look forward to putting together a better looking solution eventually. Thanks again for your help!
I've got a combination of rules to control it. For each door, I have 2 basic rules:
"[When Garage Door 1 turns on, turn on Garage Door Relay - Relay 1]"
"[When Garage Door 1 turns off, turn off Garage Door Relay - Relay 1]"
And 1 Rule Machine rule:
1 Like
I just set up a Zen17 using a C VC input connection. "Contact Sensor" didn't seem to work for that. Switching to "Water Sensor" works, switching between "wet" and "dry".
I thought I had seen a post on how the input configurations of the Hubitat driver set up the ZEN17, but couldn't find it. If someone has that info, please post it. Some input configurations don't create the sensor child devices, and apparently some configurations ignore the C VC inputs. The driver input descriptions are zero help.
From the installation guide that comes with the Zen17, the "contact sensor" seems to be meant for a door sensor, which I believe would be a closed circuit when the door is closed. If I put a jumper wire across S1 and C, the child Sensor 1 device reports "open." If it is reporting the status of a circuit, then it is reporting open when the circuit is closed, and if it is reporting the status of a door, it is reporting open when the door would be closed. The "toggle switch" or "dry contact" choices for "input type" make better intuitive sense for a generic switch that is either in an open or closed status, but neither of those choices allow the input reporting to be separated from the relay action.
1 Like
For a unpowered sensor (like a wired magnetic reed-type door/window contact sensor), use the S1 / C (and/or S2 / C) slot, not the C/VC slots.
Using the "Contact Sensor" attribute for those currently results in a backwards open/close status - based on posts earlier in this thread, it sounds like Zooz is going to fix that in an upcoming firmware release (hopefully soon!!)
ETA - some setup-related info here (from a Zen16 thread where Zooz first mentioned they were realeasing the Zen17): New Zooz ZEN16 Multirelay
Yeeeeah, this driver needs some more work. In addition to exposing the auto turn on and auto turn off parameters, the behavior of the child sensor devices needs to be straightened out. According to the docs and other posts, the relay input types which are supposed to create child sensor devices are:
04 - Leak Alarm (capability WaterSensor, values dry / wet). Seems correct in the driver.
05 - Heat Alarm (don't know what this would map to or what values are returned by the device).
06 - Motion Alert (capability MotionSensor, values active/inactive). Looks okay, haven't tried it.
07 - Open/Close Alert (capability ContactSensor, values closed/open). This currently assumes a N.C. contact switch, which almost nobody uses and is supposed to be corrected in firmware.
08 - CO Alarm (capability CarbonMonoxideDetector, values clear/detected). This currently creates a sensor with the attribute of carbonDioxide. Oops.
09 - CO2 Alarm (no capability listed in the Hubitat docs, but there must be one). And of course, this one currently creates a sensor with the attribute carbonMonoxide.
10 - Dry Contact (capability Switch, values on/off)
Options 05 and 10 do not currently create a child sensor. I don't know what you could map "Heat" to, but the "Dry Contact" should create a sensor with the values of on/off. If there is no use for Option 5, it should be removed from the drop down.
Regarding dry contact vs. voltage inputs, there is no documentation explaining how the voltage input (VC terminals) works. The documentation suggests that the voltage input is only for direct control of the relay, and has nothing to do with the Relay input type (which is only relevant on the S1 and S2 terminals).
I have also noticed some slow response on the relay controls via ZWave. One of the three units I have is sometimes VERY slow to actuate after a command is sent (5-10 seconds if not longer), and sometimes it seems like commands queue up and the suddenly process, leading to a fluttering of the relay. I recognize that these things are still in "beta" and that's why we are getting them so inexpensively right now ($21.95 is an absolute steal under the current sale), but I hope Zooz gets them stabilized soon, because right now I don't think they are ready for "production" in my setup.
Tagging @bcopeland on this for the next revision of the driver.
1 Like
Yep, I'm eagerly awaiting a f/w update too. Getting a fix for the flip-flopped contact sensor states (mentioned higher up in this thread) would be especially awesome.
IIRC, in a ZSE11 thread earlier this week, @agnes.zooz mentioned new f/w for that device should release next week, so I'm hoping that means all of their latest beta devices (zse11, zen17, zen32) may get new firmware. Hope springs eternal!
Overall though, I'm digging my Zen17 - it's a cool device.
I have been thinking about why there even needs to be a differentiation between child device types in the device itself, when the sensor could just return '0' or '1' and the driver could make the distinction over what kind of child device you would like. Then I realized that there are other automation platforms in the world besides Hubitat (really?), and there may not be the same flexibility in their driver model, or if they even have one, to interpret the results in that way.
Incidentally, the reason I would like a functioning "Switch" child is because I am using the Simple Sprinklers app with one of the ZEN17s. On my current timer, I have an outdoor sensor which aborts the current schedule if the sensor is wet. There is a similar function to abort the schedule in Simple Sprinklers, but it will only work with a switch. If I connect the sensor to the ZEN17 sensor inputs, I need it to look like an on/off switch, not an open/close sensor.
@agnes.zooz, can you power the ZEN17 with this type of power supply?
It is rated for 24VAC, but it isn't regulated so the voltage may be a bit higher.
I asked Zooz support if they had the new firmware yet and @agnes.zooz responded to me and sent me 1.04. It fixed the flip-flopped contact sensor states which is what I really needed for one of my applications.
A small source of frustration for me is that the Zen17 has the ability to time the relay's (either on or off) but the Hubitat driver needs to be updated to provide the ability to set the timers. What is frustrating is that the Zen16 driver is completely full featured in that regard yet the Zen17 that came out after the Zen16 is not. @bcopeland, pretty please when you get a chance 
Lastly, so you all know, I used the built in 'Device Firmware Updater' App in my C7 to load 1.04 but it was very funky. The first two times I tried, it was super slow. The update counter (% complete) was maybe going about 10% every half hour. Then it would finally fail after 1-2 hours giving me a 'failed update' message. I then tried again and left it overnight. Came back 10 hours later and it was stuck on 80%. Either stuck or at that point going WAYYY to slow to see even a small change. Rebooted, tried again and it failed in the morning. Then evidently after one more try it worked. I didnt know it did until after I removed it from the hub and re-included it.
Heard maybe this was all due to me being too far from the hub when trying to update the firmware so I recommend if you have the same problems to move closer and try again.
Edit- One last fairly important finding I had is that I have included the Zen17 with full S2 security and have also included it without security. I could swear in my very unscientific experiment that the contacts would take 2-3 seconds to show open/closed with security enabled and less than 1/2 second when no security is enabled. Very significant difference! THis could be the reason why @SteveZed had been seeing significant delays. recommend he try with and without security to report to all if he sees the same thing I did.
1 Like
Thanks for that update!
I'll ping Zooz for 1.04 later this week if there's no other news from them here by then.
TBH, fixing the flipped sensor states is my only real beef so far, so I'm glad to hear 1.04 (at least) takes care of that.
Did you do the update with S2 or no security? I've only updated one type of device so far (Aeotec 7 repeaters) - they would only update with no security. Which is fine - I thought trying to have a good S2 "backbone" for my mesh may be a good idea, but stuff like this changed my mind. Maybe S2 will improve someday, but it seems immature & wonky right now.
Thanks again!
1 Like
