If it isn’t then the detector doesn’t send the alarm back to the controller and therefore OH doesn’t pick it up.
If that doesn’t work you will need to put the binding into DEBUG or TRACE logging to capture and log the message traffic. Then post the logs here and tag chris.
I have three of these but I can’t remember the last time I tested them. I am mainly concerned that they beep on alarm and report their battery to me. I don’t rely on the actual alarm coming to OH.
Thanks for the reply. I’ll check out the association group later tonight. Would that cause just the issue that I’m having (battery life, test alarm, and heartbeat all work fine)?
Well, putting setting the association group to the controller didn’t change anything. Still notifies with the test button, still doesn’t notify when triggered with actual smoke. I’ll look up how to put the binding in TRACE or DEBUG and capture some data. Thanks
DEBUG level will be fine - please don’t use TRACE as it’s not required.
I would however strongly suggest that you use a newer version of openHAB - at least 2.4M4 is recommended, and it will not be possible to resolve this unless you are using at least this version (and preferably the SNAPSHOT as any changes will obviously be added there).
How long should my zwave controller take to initialize after the upgrade? I followed the instructions, but my z wave controller is not transitioning to online, it is just showing “initializing,” I used the old controller Thing, and I’m just ignoring the one in the inbox.
I tried that after writing my last post. No success. I tried making a new one with the same ThingID as the original, still no success. I tried rebooting, shutting down and unplugging the stick, waiting a few minutes, powering back up, etc. Still no success. I removed the stick and it still showed as “initializing.” Maybe the upgrade changed some of the permissions with my serial port or something? Anyway, I restored from my backup I made right before the upgrade and everything is working as it was before. Maybe I’ll try again when I have more time to tinker/troubleshoot.
I spent a little time tinkering tonight and got it running with the latest snapshot. I put the z-wave binding in debugging mode, and captured some data while setting the smoke alarm off with actual smoke and then I set it off using the test button.
I triggered it with smoke around 22:49:12 and I triggered it with the test button around 22:57:29. It is node 22. There is a bunch of junk in there for other nodes. If needed, I can disable the other nodes so it doesn’t clutter up the log. Also, I can trigger it with CO and send the log. I really suspect the alarm makes a distinction between being triggered from smoke, CO, and the test button.
Thanks. Yeah, I saw a difference too when quickly looking at it. When a get a chance (in a few days most likely), I’ll capture a better log file. I’ll trigger it with smoke, then CO, then the test button. It’ll be awesome if we can get these smoke alarms to do what I feel like they’re capable of doing.
These alarms look like they are probably V1 alarms, so there is actually no formal definition of what the alarms mean, so I don’t know what this alarm actually is?
Once you have the logs and an understanding of what the alarms do, we can look at how to decode them.
I take back what I said. It actually appears to be the opposite of what I said.
SMOKE is not causing an update to the alarm channel. This is generated by the detection of real smoke.
HOME_HEALTH is causing an update to alarm_general (see log viewer above at 22:57:29.700 immediately after the receipt of the HOME_HEALTH alarm type). This is generated by the device when the test button is pressed.
So,
real smoke causes alarm type SMOKE and does not update the alarm_general channel (see 22:49:12.637)
test button causes alarm type HOME_HEALTH and updates the alarm_general channel (see 22:57:29.656)
This is consistent with what was reported in the first post.
All 9 of the smoke alarms report battery life correctly, and send notifications when the
test button is pressed, but they do not send the notification when triggered with
smoke (I’ve tested them several times now with actual smoke).
I dunno. He said he pressed the test button at 22:57:29, which coincides with the receipt of the HOME_HEALTH alarm type. OTOH, I can see alarm type APPLIANCE (12) in the logs around that same time.
It’s quite possible that HOME_HEALTH (13) is a heartbeat (although it seems to arrive at irregular intervals), APPLIANCE (12) is when you press the test button, and SMOKE (1) is when it detects real smoke.
I think I might have one of these new and still in the box. If I can find it, I may run some tests.