Does it consume a lot of resources?
I'm trying to avoid as many apps as possible.
Was just going to ask about this... Jeff, one of the reasons I asked about the Refresh thing back up in post 59 was that I remember having issues with my Z55 and Device Activity Check -- DAC kept saying it was offline each check-in.
And based on all this 1.3 release-notes stuff, heck, maybe it was offline that whole time lol... But at the time, I thought it was maybe because doing a device Refresh didn't show anything in the logs.
When you gave me that line 437 tweak, I booted DAC back up and it's all been great since then.
Now I suspect that was all just a coincidence and my Z55 may actually have been offline back then. Who knows I guess.
It only runs a check once a day (at a time you configure), and only takes a few seconds. So I would say it is pretty light. It does not subscribe to any device events so the other 23.9 hours of the day it just sits there doing nothing.
1 Like
I just use it for a few key things -- my Zen55 here, water leak sensors, and a few of my not-often-used contact sensors. To me, the peace-of-mind provided is well worth whatever resource draw.
1 Like
I have it setup for every single device that plays nice with it. Better to find and fix a misbehaving device before the family finds it!
1 Like
It does absolutely nothing unless you run something from the app (for example, there are--intentionally--no device event subscriptions). For most users, this is probably the easy once-a-day schedule mentioned above. Technically, you can also link to a local or cloud report or run a notification on demand in response to a switch or button event, and you can do that on whatever schedule (or not) you want, perhaps with a rule.
Otherwise, it's just sitting by, "sleeping," like most apps.
Remember that you can check App Stats (or Devices Stats) if you have any concerns.
2 Likes
Mine are quiet as church mice, but they all usually work when I spit on them, lol.
on mine at least - I had to power cycle and it updated fine. hopefully that fixes he problem.. although on mine even through it "fell off" it would still chime in on a test.
I never did test it with a smoke detector, so I wouldn't know.
I think the firmware notes does use the word "apparent".
Any chance the ZEN55 can surface which detector is alerting?
No, that is probably not even sent over the interconnect wire. They use some sort of electrical pulse to send either smoke or CO to the other detectors and the ZEN55 picks it up just like a detector would.
My alarms that have the voice alert to tell you which one went off, it only announces it on the one that alerted, the others just make the alert sound.
The only way you could know is if your detectors were not interconnected to each other and you had a separate ZEN55 on each one, connected to the interconnect wire.
Thanks. Sorry if I missed it, what detector are you using that provides this feature?
This one: https://www.amazon.com/gp/product/B002UQW8OS
It says it is battery powered, but that is a backup. It is a hard wired interconnect. Since I already had the wiring in place and was replacing existing detectors I specifically looked for the hard wired interconnected models. I actually already had an Ecolink Firefighter audio detector before the ZEN55 came out, which is still in place. I should probably get the ZEN55 I have installed as well.
2 Likes
Looks like in the new firmware the device now sends IndicatorReport events every 6-ish hours, which can be used as a heartbeat indicator.
Central Smoke Alarm: Unhandled zwaveEvent: IndicatorReport(value:0, indicatorCount:3, indicatorValues:[[indicatorId:80, propertyId:3, value:0], [indicatorId:80, propertyId:4, value:0], [indicatorId:80, propertyId:5, value:0]]) (ep 0)
Just adding this method to the driver should work:
void zwaveEvent(hubitat.zwave.commands.indicatorv3.IndicatorReport cmd, ep=0) {
logTrace "${cmd} (ep ${ep})"
for (Map<String, Short> indicator : cmd.indicatorValues) {
Short indicatorId = indicator["indicatorId"]
Short propertyId = indicator["propertyId"]
Short value = indicator["value"]
def desc = "Indicator ${indicatorId} property ${propertyId} set to ${value}"
sendEventLog(name:"indicator${indicatorId}_${propertyId}", value:value, type:'', desc:desc, ep)
}
}
2 Likes
Nothing on that page disputes my truth. Similarly, the Kasa WiFi switches need the phone app to setup but not afterwards. The difference is those $12 switches work unlike the $120 Next piece of junk. Mine was tossed in the garbage and replaced with a SC7010BV.
Probably, I have the audio one next to my wired CO / Smoke (SC7010BV) in the bedroom hallway. The difference for me is I do not need to EVER replace a battery unlike the audio unit. Quite frankly, I use mine to turn on EVERY light in the house and slowly flash all outdoor lights so every know which house it is as well if a fire occurs. Most fires are at night, having every room and outside lit up before wires get damages was why I wanted such a unit. Also, all lights on daytime does not hurt.
Code added at the end.
Probably should add this for an update.
2 Likes
Hi everyone.
The main reason I'm back on this thread is because I didn't mark the box I installed it in, lol. A post of mine gave me a clue, and I found it on the first try!
I got a valid CO alarm from a ZCombo in the garage, so I thought I'd check on the ZEN55 (house) side of things.
I didn't see anything in logs, device set on Info, or events. Should I? Admittedly, the logs only go back to 1/31 when I tried the nifty reboot and wipe past log feature, lol. The thing checks in once a day, right?
What's the latest update? Is it worthwhile and reliable? I haven't checked for quite a while.
I tested the hardwired interconnected alarm system, and the ZEN55/Hub worked, sending the correct notifications.
Disclaimers:
I know I should get Device Activity Check up and running
I know I should have a regular testing program for the smokes/co
I know this may have been gone over before
I know I'm lazy
Sorry
Turn on Debug logs, check the "Last Activity" at the bottom of the device page, then click Refresh, give it a few seconds and then refresh the device page. Last Activity should have updated and you should see some debug logs. Because this device does not have a battery it does not check in on its own.
This is one of the devices where I really should have a built in health check on it, due to the nature of the device. I will try and figure something out and post a new version in the next couple of weeks.
The DAC app would take care of doing a daily refresh for you, and letting you know if its not responding.
2 Likes
Thanks!
