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).
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.
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:
@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.
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…
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
Happy to finally get this sorted out. I’m glad you had that can of CO!
@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 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).