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
}
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 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.
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.
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.
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.
Did the update with no security. I think it was the very first time I included the device about 2 months ago that I included with Security. Saw the 2-3 second delay for the relays and contacts and then just for shits and grins tried including it with no security and have not had any delay issues since. BTW i have had so many zwave issues of various degrees and have heard so many bad things related to including anything with security that I just dont inlcude anything with security just to take that particular variable out of the equation. Unless, for example the Ring2 Contact sensors and keypad supposedly do not work correctly without it.
I have a C5, so there is no S2 issue for me. My mesh (checked via PC Controller and a secondary Z-Stick), looks okay, the ZEN17 has plenty of neighbors as well as a direct connection to Hubitat. Delays/hangs seem to happen if you try to quickly toggle a relay via ZWave. The first On/Off commands will run immediately, but an On/Off command sequence issued a few seconds later will not. Here is an example:
The first on and off sequence works properly. The second On command is sent at 11:35:45.428. I sent another Off command at 11:53:47.079, BEFORE the relay actually turned on at 11:53:47.613 (an over 2 second delay from the on command). Now the relay (and the sprinkler zone it is controlling) is stuck in the On position. The Off command from 11:53:47.079 is never executed, and a subsequent Off command at 11:56:32.844 is also ignored. If I then send another On command, a subsequent Off command will actually shut the relay off. Now fortunately, this is just a test run, and the sprinkler valves are not actually connected to the ZEN17... but this is why I won't switch them over yet. I don't know if the 1.04 firmware addresses this issue, but I will request it and see if it helps.
Interesting... I just tried the same thing and had the same happen to me with the same type of log findings you did when I tried flipping the relay at 1 second or less. Then I waited 5 minutes to let the mesh 'rest' and now I can click the relays on/off at a cadence of about 1/sec and have no issues. In my water valve use case there would be no reason to ever flip the relay in less than one second so I think I am okay with the performance but of course you will have to judge if it works okay for your use case.
Some more data. I changed the power supply I was using to a 24VAC alarm power supply and moved it 3 feet away from the ZEN17. Device 1566 is the ZEN17 itself, 1568 is Relay #2.
Who the heck knows. Only thing I can think of is a Mesh issue since you moved the device. Try again in a few hours from the same spot and if it rights itself the Mesh is the only explanation. Otherwise there are Gremlins in your C5...
Just as another point of information, I just received a second Zen17 today from TheSmartHouse. This device is so full featured I had to find a reason for a second one. This time to run some Velux Skylight blinds using their KLF200 dry contact interface unit to their RF blind and window regulator system.
Anyways.... Used the same 1.04 firmware file I received from Zooz last week but this time included the device 10ft line of site from the Hub. Last time I updated firmware the device was 40ft through a wall from the hub and was a cluster fxxk. It is true what I heard from others on this forum using the Device Firmware Update App on the C7. Distance matters. Updated within 20 minutes or so the first time. Hope that helps everyone who comes after me when they update their firmware.
And you dont even have to exclude and re-include your device. Just went in and hit 'refresh', 'configure' and 'save preferences' and the firmware showed updated to 1.04 in the device screen and it works the way it should.
I bought 5 more + 3 bought a few weeks back which I used 2 for 2 garage doors and 1 to be for driveway gate. Can't resist $22 price. Is it the cheapest for dry contact x2 device not line voltage powered?
Going to wire back more sensors in house from previous owner's security system unit I found other uses
Not sure i understand the question. They dont give off any appreciable heat so you can put as many as you want next to each other I would think. It is a very cool (no pun intended) device. My only beef with it is I feel the electrical connection screws to the relays are backwards. Meaning you cant access them if you attach the unit with screws to the wall the way it was designed. I want to be able to mount the unit on a board and then connect the wires to it. Therefor I use double sided Velcro tape to attach them to whatever I am working with.
I just remembered these are Zen16's. My two Zen17's are awaiting a few other things before that project is completed.
That’s a subjective preference. I prefer the way they are so that, when mounted, the terminals aren’t exposed. Connecting to the terminals (at least for me) is a one-time event. After that, the terminals should be covered.
