Zooz ZEN55 DC Signal Sensor driver with the goal of exposing all advanced features and settings. This device also includes a RELAY that can be controlled independently!
If you are using this driver PLEASE like this post
Support my work by clicking the Info & Purchase affiliate link below to buy!
Events include digital/physical type and avoids duplicate info logging
All useful device parameter settings are exposed
Reporting Issues
Please use GitHub to report any issues so each one can have its own conversation and tracking. Please provide as much info as you can including model, firmware and the "configVals" data string. Issues · jtp10181/Hubitat · GitHub
Must PRESS CONFIGURE BUTTON and check all your parameters after changing to this driver.
may sound like a stupid question, but how can I test this without smoking my house and breaking my earbuds?
from what I have read, the smoke detector send 9Vdc on the red wire when smoke is found.
it does not appear safe to connect the negative terminal of a 9vdc power supply to the neutral of the 120Vac (white wire) and the positive side of the 9Vdc to the red wire...
I mean, 120v neutral and negative side of 9Vdc should be the same: nothing. but something I found that theoretical can be, a time, different than reality... lol
I think pressing the test button will work as well (on the alarm itself). My interconnected devices all go off when I do a test on one of them if I recall correctly, which means they are sending something on the red interconnect wire. I actually wrote the driver with the ZEN55 just hooked to an extension cord. Designed to work based on the specs but have not connected it to my system yet to test the input signals, maybe later this week I will get it in there.
and bumb question, I see hubitat read smoke and Co2 as clear (or something like that) how can it diferentiate smoke from CO2? is it a different signal that is sent on the red wire and the zen55 can read both?
Yes, I asked Zooz about this when I started working on the driver, here is the response:
Yes, it can tell the difference when Smoke detector is triggered or CO detector is triggered. We tested with Kiddie and First Alert 2 in 1 smoke/co sensors.
Both of them are using 9 volts; however, if you would connect this to oscilloscope than you would see the difference in the voltage waveform. The smoke has a different voltage waveform than CO voltage waveform.
zen55 will now come with any installation that have leak sensors and electric water valve + a simple rule machine:
if smoke is found and water leak is found, do not turn off water valve.
the more I think about it, might be a couple RL depending if the leak is found first or the smoke... anyway, you get the point
Hmmm.... This wouldn't work with Nest Protects sadly. They don't have the interconnect wire since they use wifi and bluetooth to connect with eachother. They have hot and neutral only Guess I'm sticking to my ecolink firefighters...
halo fan here as well.. unfortunately 3 of my five have died.. so I have a zen55 arriving today.. now just trying to figure out which smoke / co units to pair it with.
My guess would be that it's purely a precaution. Less of a chance of messing things up, like breaking the daisy-chain, or re-using existing wire nuts that may not be approved for 4x #14 or 12, etc
Easier to say "just connect to the last one in the chain"
I get this notification with the %smoke% and %carbonMonoxide% variables not returning a value
dev:332023-06-08 03:41:46.069 PMinfoMessage:[3214SmokeC02 Smoke: %smoke% Carbon: %carbonMonoxide% 06/08/2023 03:41 PM], was sent to LM-Q710.FG
dev:332023-06-08 03:41:29.419 PMinfoMessage:[3214SmokeC02 Smoke: %smoke% Carbon: %carbonMonoxide% 06/08/2023 03:41 PM], was sent to LM-Q710.FG
You are however probably trying to use the built in Smoke/CO section in HSM which you can only do one alert definition for. This is what I have in mine, very generic but that's about all you can do without the %text% support.
@jtp10181 This driver works like a boss -- I decided to replace my 2 old interconnected Halos (small house) and put in a Zen55 too... Just tested the install of everything, and it all worked like a champ!
@agnes.zooz -- thanks for making the Zen55 -- it's a great device for this alarm segment!
As far as the last one-in-the-chain thing... More than anything, I think it's just a box-fill issue... Outside of the last box, the upstream j-boxes are commonly pretty stuffed with junctioning connections, so the last one is typically the j-box with the most open space to comfortably fit in the Zen55. That was true in my case anyway. Aside from that, I don't see a reason why it'd matter where you put it.
@jtp10181 Curious, is there a reason why doCheckIn doesn't call refresh or executeRefreshCmds? Without forcing the refresh, last activity timestamp for the device would never get updated, unless the alarm is triggered, of course. This device doesn't seem to send any zwave messages on its own, unless something actually changes.
I've set up a RM rule that calls "refresh" once a day, but it would be a lot cooler if the driver took care of that
Just wanted to check if there was a specific reason not to do that, before submitting a PR
Most drivers do not try to actively check in on the devices. Battery devices automatically send a wakeup typically every 12 hours which then if the driver posts an event it will update the last activity. Mains powered devices do not send in any automatic updates.