It's got 8 pending changes.
I thought this was acting okay, but I didn't check test the smoke detectors for a while.
Then, I see the post above, and though updating firmware wasn't a bad idea.
Oy.
I forgot which box I put it in.
Sounds like you may have experienced the issue which that the firmware update fixes! Falling off the network. Check the "last activity" a the bottom of the device page, although I think possibly doing a configure might mess with that which I assume you did, to get the pending changes message,
Yeah, I did something, refresh or configure, that put a new date there.
How do I recover?
edit: For something that's smoke detector related, you'd think reliability would be a priority, geesh.
Did you try to power cycle it yet? That would be step 1.
If that does not work I assume you need to pair it again, either try to exclude and include or factory reset it and do a z-wave replace to get it back into the same node. If you try the exclude and it does not remove the device from the hub, the replace would be your best bet to avoid creating a ghost.
I just tried that while you were typing.
That did it; it's synced.
It's now updating.
It could've been off line for months.
Geesh. Another reason to regularly test the smokes.
Get this app, problem solved. I would have been notified within 24hrs if the device did not respond to the hub. My drivers are specifically coded to work well with that app and only post events if the device responds (the only exception is if you press configure).
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
