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