Zooz Modules Advanced Drivers HPM Package also includes:
[Zooz ZEN54 10V Dimmer] [Zooz ZEN53 DC Motor Controller]
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!
Current Version: v1.0.0
All device features are implemented but I have not fully tested the smoke/co alarm detection.
- Specifically tuned to this device
- Events include digital/physical type and avoids duplicate info logging
- All useful device parameter settings are exposed
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.
Find on Hubitat Package Manager (HPM):
Package Name: Zooz Modules Advanced Drivers
HPM Install Docs: HPM Documentation
OR Manual Download from GitHub
Direct Import URL: [zooz-zen55-dc-signal-sensor]
Full Repository Link: https://github.com/jtp10181/Hubitat/tree/main/Drivers/zooz/
Donations: ---->>>> PayPal.Me <<<<---- Never required, always appreciated!
Support me by purchasing at TheSmartestHouse.com through my affiliate link!
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.
I'm glad Zooz came up with this... I'm still rocking a couple Halos, but when those go EOL, I'm planning to use these.
Man, I'm gonna miss those Halos when they go - such great devices!
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...
I freaking love my halos. Have already cracked a few open and changed the 18650 cells. Wonder if we can repurpose for an afterlife ?...
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.
If your alarms are interconnected you are supposed to add the ZEN55 to the last one in the chain (not sure why it matters).
If they are not actually interconnected but have the red interconnect wire you can still use it, but it would only monitor that one single alarm.
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 installed a zen55 device and using you driver and have it set in HSM to send a notification when smoke or carbonmonoxide is detedcted.
Custom message to send
%device% Smoke: %smoke% Carbon: %carbonMonoxide% %date% %time%
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
below is the event log for zen55 device
You can only use certain key words with the % replacement.
This this instead, the %text% should get the "Description" as shown in the event log.
%device% %text% %date% %time%
%text% did not work also..
dev:2162023-06-09 01:34:22.103 PMinfo3214SmokeC02: carbonMonoxide set to clear
dev:332023-06-09 01:34:09.275 PMinfoMessage:[3214SmokeC02 %text% 06/09/2023 01:34 PM], was sent to LM-Q710.FG
app:652023-06-09 01:34:09.264 PMwarnAlert Smoke 3214SmokeC02 detected
dev:2162023-06-09 01:34:09.222 PMinfo3214SmokeC02: carbonMonoxide set to detected
dev:2162023-06-09 01:33:59.442 PMinfo3214SmokeC02: smoke set to clear
dev:332023-06-09 01:33:52.513 PMinfoMessage:[3214SmokeC02 %text% 06/09/2023 01:33 PM], was sent to LM-Q710.FG
app:652023-06-09 01:33:52.465 PMwarnAlert Smoke 3214SmokeC02 detected
dev:2162023-06-09 01:33:52.407 PMinfo3214SmokeC02: smoke set to detected
I guess %text% is not implemented in HSM then? @support_team
Your only other option would be to make two separate rules, one for Smoke and one for CO and then use something like this for the alerts:
%device% Smoke: %value% %date% %time%
%device% CO: %value% %date% %time%
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.
Smoke or CO Detected on %device% at %time%
Use %value% instead of %text, this is the template I use for my mobile phone notifications:
%time%: %device% triggered %value%
@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
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.
I use this app: [RELEASE] Device Activity Check - Get notifications for "inactive" devices to check on all my devices daily, and it can be configured to send a refresh to mains devices if the device has not sent any updates within a certain time period.