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

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. :wink:

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.

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.

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.

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?

This is interesting:

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?

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.

1 Like

I found my Zcombo Smoke/CO detector. Still in retail packaging.

I’ve included it, and will run some tests. Need to wait until spouse is gone as she finds the siren most annoying… :roll_eyes:

Unfortunately, I don’t have anything to test CO detection (such as CO test spray). :frowning_face:

You probably have a CO tester parked in your garage… :wink:

1 Like

So, here’s what I’ve found so far.

@5iver I haven’t tested CO yet. It’s snowing/sleeting/raining out, so at the moment I have no interest in going out to the garage to inhale exhaust fumes… LOL

Action                      Alarm Type              Message Contents            Binding Operation
------                      ----------              ----------------            -----------------
Detect smoke                SMOKE (0x01)            "71 05, payload: 01 FF"     (binding doesn't update channel)
Detect smoke clear          SMOKE (0x01)            "71 05, payload: 01 00"     (binding doesn't update channel)
Detect CO                   CO (0x02)               "71 05, payload: 02 FF"     (binding doesn't update channel)
Detect CO clear             CO (0x02)               "71 05, payload: 02 00"     (binding doesn't update channel)
Press test button           APPLIANCE (0x0C)        "71 05, payload: 0C FF"     (binding sets channel alarm_smoke to ON)
Press test button clear     APPLIANCE (0x0C)        "71 05, payload: 0C 00"     (binding sets channel alarm_smoke to OFF)
Periodic heartbeat          HOME_HEALTH (0x0D)      "71 05, payload: 0D FF"     (binding sets channel alarm_general to ON)

Observations so far:

  • I think it’s a problem that the binding doesn’t update the alarm_smoke channel when it gets alarm type SMOKE

  • What should the binding do when the test button is pressed? Should it update the alarm_smoke channel as it currently does, should it update some other TBD channel, or should it ignore alarm type APPLIANCE completely? Is there such a thing as an alarm_test channel?

  • The device doesn’t support the WAKE_UP command class, and doesn’t appear to ever wake up on it’s own (at least it hasn’t woken up in the 4.5 hours since I included it). When you manually wake it up, it sends a NIF, which the binding treats as a WAKE_UP (just as it does with other devices that send a NIF when woken up).

  • The device does send alarm type HOME_HEALTH periodically as a heartbeat, although I haven’t quite sorted out what the frequency is.

  • There are wake up instructions in the database entry for this device (you can see them in edit mode), but they are not shown when you view the database entry. Does the database not show wake up instructions if there is no WAKE_UP command class defined in the database? Probably a question only @chris can answer.

  • The device sends alarm type CO when triggered by carbon monoxide. We need to add the alarm_co channel to the database entry.

That’s it for now.

Oh wow, this is great information! Thank you for spending the time to do this testing!

I was going to trigger the CO alarm by putting it in a ziplock bag, and then fill the ziplock bag with automotive exhaust analyzer calibration gas, but I can’t find my bottle of calibration gas, it must be in my storage unit. I’ll look again tonight though.

Anyway, this is exciting news. Thanks again for all the time you’ve spent looking into this!

Yep, if we can get this piece of the puzzle, then we should be able to get it sorted out completely. The question will be whether carbon monoxide make it produce the alarm type CO (0x02) or whether it produces SMOKE (0x01). I read on some forums that it sends SMOKE when triggered by carbon monoxide, but I saw no actual evidence (i.e. captured messages) that demonstrate that. I’m hopeful that we’ll find it sends alarm type CO (0x02).

FYI from the spec sheet…

It will alarm at the
following levels: 400 PPM CO between 4 and 15 minutes, 150 PPM CO between 10
and 50 minutes and 70 PPM CO between 60 and 240 minutes.

So depending on the concentration in the plastic bag, it may take quite a few minutes for it to alarm…

I think I have some calibration gas with 6% CO in it, so 60,000 PPM. That probably won’t take very long to trigger it. It is just a matter of finding the bottle…

And, if I destroy the sensor with too high of a concentration of CO, at least it was for a good cause.

1 Like

It took less than a minute to trigger it. I triggered it (node 22), then silenced it shortly afterwards, then I repeated that process. The data is captured near the end of this log:

https://drive.google.com/open?id=1KtU0-ZFUpz0VkZAUpFqTzrub4TDFGGXe

Hopefully this is the last piece of the puzzle.

Nice work! Here’s where it’s sending the CO alarm right at the end of the log file.
ZWave%20Log%20Viewer%202018-11-16%2006-31-30

I’ll update my table above.

@chris I think we’ve got this device fully sorted out. Can you give some feedback on the points in my post above? Thanks!

@chris I was going to add the alarm_co channel to the DB for this device, but it looks like it was edited within the past 24 hours to remove a bunch of stuff – manual PDFs, product image, overview, inclusion info, exclusion info, alarm_smoke channel, etc. Do you know what happened?

What device are you talking about? I had a look at changes to all devices, and there has been very few changes to the database in the past couple of days.

If I look at the ZCombo, there have been no changes for 5 months, so I suspect we’re talking about something else now?

image

I was talking about ZCOMBO, but I was looking at the entry for ZSMOKE. Duh! Sorry about that.

So, you are right, the ZCOMBO has not changed…

So, back to the above analysis and observations regarding the ZCOMBO. WDYT about the observations?