Zcombo smoke/CO detectors not sending z-wave command when triggered from smoke

[jgrundvig (Joe Grundvig)]

Hello,

I’m new to the forum, but I’ve been using OpenHAB 2 for about a year. I have a Raspberry PI 3B with a Gen5 z-wave stick. I’m running version 2.3 with the 2.3.0 z-wave binding. I have 9 First Alert Zcombo smoke alarms, among many other z-wave devices. I thought everything was working great until I accidentally set off a smoke alarm while cooking, and did not receive a notification. 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 don’t see any activity for those z-wave nodes in the log when triggering them with smoke. I only see the command in the log when I trigger them with the test buttons.

Can anyone confirm that Zcombo smoke/CO detectors actually work with OpenHAB2 when triggered with smoke? Maybe there is something in the z-wave binding that needs to be changed?

While doing a web search to diagnose this issue, I came across a forum about using Zcombo detectors with Samsung SmartThings. They said that the Zcombo will send them a notification when triggered with smoke, but not with the test button. This makes me think that the OpenHAB z-wave binding is just looking for the wrong data from the detector. It also makes me wonder if the detector sends different data for smoke vs. CO detection events?

Anyway, I appreciate any help with this issue that I can get. I’m really not a fan of these Zcombo units, but I really can’t find any other affordable options in the U.S.

Thanks

[rlkoshak (Rich Koshak)]

@jgrundvig

It also makes me wonder if the detector sends different data for smoke vs. CO detection events?

I can say for sure this is not the case. It only has the one ALARM channel that it reports for any ALARM.

Make sure that the Association Group is set to Controller.

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.

[jgrundvig (Joe Grundvig)]

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)?

Thanks

[jgrundvig (Joe Grundvig)]

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

[chris (Chris Jackson)]

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).

[jgrundvig (Joe Grundvig)]

Sounds great! I’ll update to the latest snapshot and proceed from there. Thanks

[chris (Chris Jackson)]

You probably should have a read of this post regarding the upgrade -:

ZWave binding updates

I have now merged the development version of the ZWave binding into master, so it will be available in the 2.4 snapshot version. If you are using the ZWave binding, please read this post as the binding contains some breaking changes so you will need to manually update your configuration. Firstly though - the major enhancements (there are tons more smaller updates) -: Security has been added using the S0 security class. This should allow all devices supporting security to be included into the…

[jgrundvig (Joe Grundvig)]

Thanks.

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.

Thanks

[chris (Chris Jackson)]

It shouldn’t take any time at all. Probably it is better to delete the old controller and use the autodetected one .

[jgrundvig (Joe Grundvig)]

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.

Thanks again for all the replies!

[chris (Chris Jackson)]

Then you probably need to check the logs to see what is happening - otherwise it’s just going to be guesswork I’m afraid.

[jgrundvig (Joe Grundvig)]

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.

openhab.pdf (129.1 KB)

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

[mhilbush (Mark)]

@jgrundvig

openhab.pdf (129.1 KB)

If you post this as a plain text file, we can load it into the log viewer to better see what’s going on.

[jgrundvig (Joe Grundvig)]

Thanks. I’m not sure how to upload the plain text file here, it only seems to accept certain formats. Here is a link to it though. https://drive.google.com/open?id=1xSSe2eT857CdooQy7FEBbAHBArcPdFmf

[mhilbush (Mark)]

@jgrundvig

I’m not sure how to upload the plain text file here

As you already figured out, for large files, the best way is to put it on a file sharing service, and include the link in the post.

[mhilbush (Mark)]

There’s definitely a difference between the 22:49:12 message and the 22:57:29 message.

2018-11-13 22:49:12.663 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 22: Alarm Type = SMOKE (1)
2018-11-13 22:49:24.206 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 22: Alarm Type = SMOKE (1)
2018-11-13 22:57:29.687 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 22: Alarm Type = HOME_HEALTH (13)

It looks like the HOME_HEALTH alarm type doesn’t cause an update to the alarm_general channel.

@chris probably needs to weigh in on how that alarm type should be handled.

[jgrundvig (Joe Grundvig)]

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.

[chris (Chris Jackson)]

@mhilbush

It looks like the HOME_HEALTH alarm type doesn’t cause an update to the alarm_general channel.

I don’t think anything does.

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.

[mhilbush (Mark)]

@mhilbush

It looks like the HOME_HEALTH alarm type doesn’t cause an update to the alarm_general channel.

Yes, these appear to be V1 alarms.

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).

WDYT?

[jgrundvig (Joe Grundvig)]

This is interesting:

ZCOMBO Configuration

I’m not sure how to translate this from their system to here exactly, but here’s what I’m seeing: 0 = no notification 1 = alarm smoke silenced 1.255 = alarm smoke 2 = alarm CO silenced 2.255 = alarm CO 9 = alarm malfunctioned 9.255 = alarm malfunction silenced 12 = alarm test silenced 12.255 = alarm test 13.255 = alarm heartbeat 14 = alarm CO sensor end-of-life silenced 14.255 = alarm CO sense end-of-life I’m not sure how they discover these signals - though I do know their bread an…

Do you think HOME_HEALTH(13) is the periodic heartbeat, SMOKE(1) is real smoke, SMOKE(12) is the test button, and SMOKE(2) would be CO?