I did my ZEN17 firmware upgrades with a Zstick and PC Controller Software. I could not get the .gbl format firmware files to work properly with the Community Firmware Upgrade tool on the C5. If you don't already have a Zstick (also helpful for busting ghosts on the C5), it's on sale this weekend:
The Silicon Labs UZB-7 700 chip version is always $19.95 (not on sale) from Digi-Key. That’s where I got mine, based on a recommendation in this forum.
https://www.digikey.com/en/products/detail/silicon-labs/SLUSB001A/9867108
1 Like
So, I finally connected my Zen17 to my GDO wall switch (Genie DirectLiftPlus 3060). The good news is, the Z17 works...in that, when I turn the switch ON, it starts the GDO. I have to turn it OFF and ON again to stop the door (unless it opens all the way), and OFF and On again to close the door. This is all ok, as it's exactly as I expected because that's how my wall switch works.
The problem, however, is that I can't get my wall switch to work. I even tried reversing the connections, but that didn't work. I got a Zen16 as well that I guess I could try, but I was hoping to use that for a different project (need three connections.)
What contacts are you using on the z17?
Just like the directions say:
GARAGE DOOR OPENER: 2 bell wires from the opener to R1 C and R1
NO; 2 wires from the wall switch to S1 and C.
I realized I had reversed these the first time (as seen in the pitcture) but the Z17 worked correctly. In neither case did the wall switch work.
That wall switch is not a simple on/off contact switch. As you can see, there are multiple functions on it (light, door control) which are represented to the opener via some sort of encoding. A simple surface mount doorbell button will work instead.
I avoided involving the hardware door switch (I also have a Genie opener) by buying a cheap Genie compatible remote and hooking that to the relay. Here is the one I got:
https://www.ebay.com/itm/123963473925
I also use the Zooz Garage door app to combine the remote and the door open/close sensor into a Garage Door Device
You will also need an open/close sensor (either a hardwired contact switch through the ZEN17 or a Z-wave or Zigbee contact switch) to determine if the door is closed or not.
Did you try connecting it to the NO-C on R1 (nect to the wires from the opener) instead of the S terminals? It's another way of adding control from the wall switch if it's a more advanced one.
2 Likes
You read my mind. I was actually planning on trying that next. I'll let you know if it works.
[EDIT]
Yep, worked perfectly. 
4 Likes
This is exactly how mine is setup, except instead of the wires coming from the garage door opener going to S1/NO-C, they go to the dumb switch. Same result, just different wiring points.
Is anyone still having or just having issues with the relay turning off or back on after 5 seconds with the built in Hubitat driver?
I have the Zen17 hooked up between my fireplace switch and the control module. The switch is connected to S1 and C and the control module is hooked up to R1 no and C. The Relay 1 input is set to "Toggle Switch state change". It seems that the Zen17 works fine with the toggle switch. each time i flip it the relay clicks and the fireplace does what it is suppose to. If i use the child device in Hubitat though more often then not the switch will flip back to either on or off after 5 seconds of the turing it off or on. Doesn't matter where the starting point is. In my test this morning it turned on and stayed on fine which was the first action. After that it took 3 attempts to get it to turn off for it to stick in that state.
Only error i see in the logs is:
2021-06-10 10:44:35.148 am errorjava.util.ConcurrentModificationException: null (supervisionCheck)
Are other seeing this as well. I did just upgrade the firmware to 1.04. Had to exclude it and repair with any security. After it updated fine i went ahead and repaired it with S2 again.
Mine is set up differently as I don't use the inputs to control the actual relay, but I do notice that the relay can get gummed up (for lack of a better term) if activated several times in a relatively short period... It seems like it's often slow to catch up on its state and that can induce confusion on subsequent activations.
I use mine out in my garage, so it's rare that I ever activate the relay more than once quickly back-to-back, but when I have done testing out there going up & down a couple times in a row with the garage door, I have noticed the relay often bogs up its state.
I haven't been able to capture any helpful logs or info, so it's just something I'm living with...
Hopefully the driver for this device will mature over time - the Z17 is still a relatively new device.
This is the log information for the child device. What is interesting is that I wasn't doing it fast, or atleast i didn't think it was. It was over a min after the initial on command that initiated the off command. Then you can see it turned off off and right back on 5 seconds later. Later in the log you can see where I was flipping the connected toggle switch. That seems to work like a champ pretty much no matter how fast I flip it.
I had to search to find this. I was trying to figure out why the heck I couldn't get heat sensor option 5 to give me a child device!
There are dry contact heat sensors available, so I would hope that this gets fixed. Did the firmware update fix this, or is this a Hubitat driver issue?
And it sure would be nice to have ALL the parameters exposed in Hubitat driver without having to use the Basic Zwave Tool.
It's a driver issue.
I'm going to get on my high horse for a minute.
Fundamentally a great device on paper, the Zen17 can only be utilized at a fraction of its capability because a driver has not been written to utilize its full capabilities. You would think the manufacturer of the device would help in some way to write the code for the hub manufacturer but the synergy is just not there. I see this as a fundamental flaw in the current business model between device mfg's and hub mfg's and its not just Hubitat.
Adoption of Smart Home technology to the masses has been much slower than ever hoped and this example is big reason why. Its just not as plug and play as it needs to be to become truly adopted by the masses.
This has spurred on the development of new standards by the big three (Apple/Google/Amazon)
for the very frustrating example that is going on here.
I love Hubitat but I am, like most others here, a huge tinkerer and wanna be part time programmer. But this is hugely frustrating when Hubitat posts a driver that only utilized 50% of the devices capability. Most likely a resource issue both on the device mfg side and the Hubitat side in being able to put in the the time to get a full capability driver....
2 Likes
Here is hoping that @bcopeland can fix this driver and add all the capabilities in 2.2.8. Either that, or someone much smarter than me could do a community based driver.
IIRC there was a major reporting difference in how it reported for this specific type and it seemed to be basically identical (with a different name) to another type.. But if there is an immediate need, I can update the driver..
2 Likes
Well... that was part of the story.. The other "heat sensor" there isn't a capability present for that..
2 Likes
So if there isn't a Hubitat capability, maybe hide this option, or map it to "dry contact" or another one of the capabilities that are present in Hubitat?
I think the thing many of us are requesting throughout the thread is to expose the timer parameters. There are 8 or so timer settings that are not exposed through this driver. (Parameters 6 through 9, and 15 through 18) It is very hard to make this work for a garage door opener without having those timers in the UI. You can swap to the Basic Zwave Tool, but that is very time consuming when you are trying to "tune" the timers to work properly. The LED on parameter (#5) also is not in the driver, but that is a lower priority, it doesn't affect the basic usability of this device.
The other feature request that I see here (and I would like to see too) is the ability to reverse the sensors in software (open=open, or open=closed). Not sure that is possible, but it would make this a lot more usable if you could tweak these for various sensors.
Ok.. I can do that..
Ok..
3 Likes
Not an emergency, but 2.28 would be nice to see...
1 Like
