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.
Yes, different signal and the alarms have different noises as well. The sound for CO and not the same as for smoke, It is defined is some standard but I do not know where I can reference them.
I had no problem fitting the Zen55 in a middle box. They appear to have use standard metal ceiling fan boxes which are actually bigger than a typical switch/receptacle box.
Oh bother! Now come the programming! Oh well, at least it should work when I make the App. I really want it to only turn on all the lights and flash others if detected. No text, etc. Between the noises and lights it should be enough. It also allows a safe exit since most fires occur at night.
I posted a minor update to GitHub to fix issues with the fingerprint, so now the driver should properly match to supported devices when they are paired. Did not increase the version since it mostly benefits new installs but if you want to update anyway just run a repair in HPM.
While I like my BRK relay setup, it doesn't differentiate between CO and Smoke.
I just ordered a ZEN55. I'll put it in one the boxes that used to hold a separate CO alarm.
Thanks for the driver.
Not sure how feasible this is (I'm no programmer) but would it be possible to modify the driver to create child devices for Smoke and CO so you could differentiate them through HSM. I know that other companies do it (inovelli does it with their switches to control notifications that other apps can activate). Right now I'm using global variables rule machine and hsm (just setting it up so not sure how it'll actually work together just yet)
It would be possible yes, but not something I am really interested in doing.
What is the issue exactly? The smoke and CO alerts are two separate attributes so you can pick them separately in apps.
Are you trying to get a different notification in HSM based on which one alerts by using a different device name? This is an HSM issue/bug, creating child devices would just be a workaround. If HSM supported the %text% variable like RM does then you could use that. Or a way to include the attribute name in the alert would also work.
You could include just the smoke in the main panel and then add a custom alert for the CO, then you could customize the message for each one.
