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

Tags: #<Tag:0x00007f745f7a7be8> #<Tag:0x00007f745f7a7af8>

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?

It think it’s nice :slight_smile: .

I’ll have a look shortly and will probably update the database accordingly.

Thanks! I don’t mind doing the DB updates (unless deletions are needed). There were a couple things in the list that I think need your input first.

T’is done -:

The only question is there is no “test” alarm, so I used the tamper channel. Maybe we should add another alarm type for testing - WDYT?

I’ve updated your access so you have full (or nearly full) control now. The only downside is you will get some “spam” when people request review so if you prefer, I can remove this again…

Thanks! Looks good!

I would be inclined to not add it unless we think there will be other devices that could take advantage of it. I actually think tamper is a pretty good match.

Thanks. I’m pretty sure this will be a drop in the bucket compared to all the other emails I get. LOL

1 Like

This is awesome! Thanks for all your work on this!!!

What do I need to do to get the changes?

Happy to finally get this sorted out. I’m glad you had that can of CO! :+1:

@chris usually puts out a new version of the binding every few days. You need to install that version of the binding. How you do that depends on whether you’re running the snapshot, milestone, or stable release of OH. I seem to recall you said you were on a recent snapshot build. If so, you can install the next snapshot that contains the new binding, or just update the binding as described here.

I’ll keep an eye out for when the next version is available, and I’ll post back here.

You’ll also need to delete and rediscover your ZCOMBO things in order to pick up the new/modified channel definitions.

I’ve kicked off a build with the updates, so hopefully it will be ready in an hour or so…

1 Like

The build is done. However… I would recommend against installing a snapshot release after and including build 1427.

See this post. Depending on what DateTime methods you use in your rules, those rules could be badly broken by a recent ESH change.

If you want to pick up a new zwave binding, and don’t want to install a snapshot for the above reason, use the method explained in this post.

FYI, the issue with the DateTime methods in rules was fixed in build 1430.

I updated the binding and everything is working perfectly! After setting up the new channels and writing some new rules, my ZCombo alarms now send my phone the correct notifications based on what triggered the alarm (CO, Smoke, Test button). :+1:

Thank you!

2 Likes