Same issue here. I have 3 of these things and despite multiple variations of trying to get this thing to work I can not get the device to send an ID to habmin, and thus it’s zwave functionality is useless. I can only get a gray icon without a name. Oh well. Probably worth looking into a different smoke detector if you want zwave functionality.
If anyone who is having trouble is curious I finally got this device connected. Not sure if it was the update from 1.8.2 to 1.8.3 that did it or what.
Make sure the Zcombo isnt already included in the network from previous failed attempts. Exclude it for good measure and delete the dead node if its there.
Include on HABmin. slide battery tray out and then while pushing in hold the test button till it chirps. Let the include timer expire. then slide the battery tray out and in while holding the test button a few a more times. I had to slide the tray in and out about 4 times. You can see the flurry of activity in the logs. its green now and working.
Need to buy 20 smoke detectors, wanted to check if it is still not possible to distinguish between CO2 and Smoke alarm.
That is correct. These only support alarm_general and battery-level command classes. You need one that supports sensor_binary or sensor_alarm command classes. You can probably search chris’s zwave db once you find a candidate device to see if it supports the class.
I know this is a relatively old thread, but I’ve been fighting with one of these units trying to include it for several days now, and I hope I can save someone else from the same trouble.
I tried using the built-in Zwave reset (hold button for 10+ seconds while inserting batteries) but that didn’t seem to help. I finally fixed it by using the IMA Tool from Aeon Labs to exclude it. I assume excluding from HABmin would probably work as well. After that I was able to include it using the IMA Tool, and when I plugged the Z-Stick back into openhab and started it up, the new node was there.
To wake up the device, as @Nhoc6131 says, slide the battery tray out, then push and hold the test button and slide the battery tray in. Keep holding the test button until you hear the chirp, then let up. I had to repeat this process 3 times, allowing 5-10 seconds between each repeat, to get all node info in HABmin.
I credit this forum thread with saving my sanity, since I never would have thought to exclude a brand new device right out of the box. http://forum.universal-devices.com/topic/15164-first-alert-zcombo/
My ZCOMBO seems to be working fine right out of the box on openHAB 2 with Chris’s most recent test snapshot Z-Wave binding from Feb 28 2017 (found here).
I looked at the included instructions and did a normal inclusion procedure. Instructions said to put the battery tray out, hold button and push tray in. First thing I did was this and it included immediately. Then, as expected with Z-Wave battery devices, I needed to wake it once to get it to communicate the needed info for openHAB to identify it and set up it channels. I see three channels:
- Heartbeat (alarm_general)
- Smoke (alarm_smoke)
- Battery Level (battery-level)
Does anyone know what the Heartbeat channel is? Is it what it sounds like, it goes off periodically to let you know that the device is still alive?
I plan to check my logs and events after a day with this on my network to see what it’s doing and decide how to set up the logic on it.
Shame that Z-Wave device manufacturers’ documentation is so poor.
After configuring my Items, I just did a wake (pull battery tray out, hold button and push back in) and see this in my event log:
2017-03-02 11:42:09.185 [ItemStateChangedEvent ] - SmokeDetectorSWBedroom_Heartbeat changed from NULL to ON
2017-03-02 11:42:57.437 [ItemStateChangedEvent ] - SmokeDetectorSWBedroom_BatteryLevel changed from NULL to 98
So, to answer my own question, it seems that the Heartbeat (alarm_general) is just want it says, a heartbeat. I’d expect this channel’s item to always report “ON” and so absence of a report in the wake period of this device would indicate that something’s wrong. I don’t know what that wake period is yet, but expect the logs to reveal it over the next day or so.
I am disappointed that the CO alarm cannot be distinguished from the smoke alarm, per comments earlier in the thread.
Does anyone even know for sure that the Smoke (alarm_smoke) channel will fire on a CO alarm?
I see that we are calling the channel “Smoke”, but I believe this only comes from the Z-Wave binding’s database. I see no mention of the alarm being smoke-specific in any of the official technical documents. Maybe we need to have that name changed to “Alarm” or “Smoke / CO Alarm” if we can prove that it indeed is used for both?
Going a step further, is it possible that some metadata attached to the alarm message indicates smoke vs. CO and would allow distinguishing the two? I’d love to have my system announce what kind of alarm we’re getting and give specific instructions for confused alarm-hearers to follow for maximum safety, like “Do not just disable a CO alarm and go back to sleep.” The one’s a common mistake people make, and it’s deadly.
Here’s what I see when I hold the “test” button to do a test.
2017-03-02 14:32:57.880 [ItemStateChangedEvent ] - SmokeDetectorSWBedroom_Smoke changed from NULL to ON
2017-03-02 14:32:58.506 [ItemStateChangedEvent ] - SmokeDetectorSWBedroom_Heartbeat changed from ON to OFF
2017-03-02 14:33:14.946 [ItemStateChangedEvent ] - SmokeDetectorSWBedroom_Smoke changed from ON to OFF
2017-03-02 14:33:14.969 [ItemStateChangedEvent ] - SmokeDetectorSWBedroom_BatteryLevel changed from 98 to 100
So I was wrong. The heartbeat does change to OFF sometimes.
The heartbeat channel is pretty much always on but it is updated every hour or so, I’ve set my MapDB persistence to everyUpdate and just run a cron rule every 6 hours that checks lastUpdate for each item in my SmokeHeartbeat group to see if it has updated in the last 12 hours. updatedSince doesn’t seem to work for this case but this at least lets me know that they are still working.
It might be nice if the binding set that channel to on momentarily, then off again but this method works.
I believe the device itself doesn’t distinguish between smoke/CO. Though I’ve never been able to trip the CO alarm to see what the messages look like but I bought these things when I was using SmartThings and I remember that was the behavior there too.
This is indeed a heart beat. I’m not sure how often it “beats” but it is sent several times a day. I’m still on the release so only have the two channels. Indeed the logs will show.
All I can say for sure is that the alarm channel triggers when manually testing the alarm (at least it did in OH 1, the last time I tested it). It stands to reason that a combo alarm that doesn’t alert on the CO would be pretty worthless so I have to believe it does. Perhaps I’m naive.
The alarm implements the ALARM command class which does not have any way to distinguish between alarm types. It used to be just called “Alarm”. At least that is what it is called in the Release version of the binding. I don’t know if Chris discovered something about the device or someone made a change forgetting about the CO or what happened. I agree, unless we know it doesn’t trigger for CO, it should be called Alarm, not Smoke.
No. First Alert cut corners and only impelmented the generic alarm command class, not the more useful sensor alarm command class. To distinguish between alarm type you will need to get a different device, one that implements the sensor command class.
You can use the Expire binding to set the heartbeat Item to NULL if it hasn’t received an update for awhile to track whether it has fallen offline.
Switch AlarmHeartBeat { channel="...", expire="12h" }
In the above, if the Item is not updated for 12 hours it will be set to NULL. You can write a rule to trigger based on that. Based on watching logs, you can probably use a shorter expire time.
That is easily implemented in a rule.
rule "Reset heart beat"
when
Item MyAlarmHeartBeat received command ON
then
MyAlarmHeartBeat.postUpdate(OFF)
end
2 Likes
duh, I never thought to do that. Unfortunately, I tried that for each of my smoke detector heartbeats and even though
MyAlarmHeartBeat.lastUpdate
will print out the correct time in a log entry and my MapDB store looks right when checked through the REST api,
MyAlarmHeartBeat.changedSince(now.minusHours(24))
will always return false
and
MyAlarmHeartBeat.updatedSince(now.minusHours(24))
will always return true, even when i change it to minusMinutes(1)
I just gave up and replaced both calls with:
var currentTime = now.millis
var beatUpdate = beat.lastUpdate.millis
if(currentTime - beatUpdate > (((1000 * 60) * 60) * 24))
etc
Sorry for stealing the thread.
Did anyone tried to trigger the zcombo with smoke? This thread helped me get things going and I can see that smoke alarm channel getting triggered when test switch pressed but when I actually let it off using a candle smoke, there was no triggers. Did I miss something? does anyone know how to debug it?
I tested it once a long time ago and it worked. I’ve not tried testing it in OH 2 but it seems to me that if it works when you trigger the alarm test it should work with actual smoke.
But in my experience, these smoke/CO detectors are not feature rich nor reliable enough to rely upon the zwave triggers for anything. If you really need that you would better off selecting a different alarm. Lots of people love the Fibaro alarms.
Thank you for the quick reply. I was planning on using this to turn off the outlet that powers the 3d printer. I have heard enough horror stories that I dont want to leave the printer running for 24/7, unless I rig something to notify and to prevent damage. Im going to do more digging and if it is not working as it intended. I’m going to send it back. There is no value in buying zwave smoke detector if it is not triggering the zwave channel when there is a actual fire 
. I do have a fairly new device, manufactured in may 2017. Hardware could be slightly different.
Anyone have this working in 2.3? Cannot get it to switch from ‘uninitialized’ no matter how many times I’ve performed the inclusion process
@derfNamttog Yes, I have the ZCOMBO working in both 2.3 and 2.4. For me, it included fine and was recognized as the “ZCOMBO Smoke and Carbon Monoxide Alarm”. I’m curious if (a) you ever got your ZCOMBO to initialize and work normally, and (b) if you tried excluding the ZCOMBO from your ZWAVE network and then retried the include?
To elaborate on it “working”, I have the 4 switches (smoke, CO2, test, heartbeat), and number battery percentage. To note, the battery value did not first appear until I performed the alarm test. Apparently that woke up the device to send a report.
Perhaps I could be of more assistance if needed. Good luck. 
Finding this thread now since I’m in the process over move over my whole ZWave house over to OpenHAB from SmartThings after briefly touching on Home Assistant and OpenZWave.
I think I’ve tried every trick in the book but the ZCOMBO seems to get stuck on initialization. I’ve tried excluding and including it probably 20 times now. I’ve tried waking it up with the battery-out-button-down-battery-in method outside of the inclusion window but the zwave log keeps saying it’s either stuck in state MANUFACTURING or NIF_FRAME as seen below. Any ideas here?
This is after I wake up the ZCOMBO but outside of the include window:
04:06:40.230 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 49 84 50 0A 04 A1 00 20 80 70 85 71 72 86 0D
04:06:40.231 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationUpdate[73], type=Request[0], dest=80, callback=132, payload=84 50 0A 04 A1 00 20 80 70 85 71 72 86
04:06:40.232 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationUpdate[73], type=Request[0], dest=80, callback=132, payload=84 50 0A 04 A1 00 20 80 70 85 71 72 86
04:06:40.233 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - lastTransaction null
04:06:40.234 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 0
04:06:40.235 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Last transaction: null
04:06:40.236 [DEBUG] [ave.internal.protocol.ZWaveController] - Incoming Message: Message: class=ApplicationUpdate[73], type=Request[0], dest=80, callback=132, payload=84 50 0A 04 A1 00 20 80 70 85 71 72 86
04:06:40.236 [DEBUG] [message.ApplicationUpdateMessageClass] - NODE 80: Application update request. Node information received. Transaction null
04:06:40.237 [DEBUG] [message.ApplicationUpdateMessageClass] - NODE 80: Application update - no transaction.
04:06:40.238 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
04:06:40.239 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
04:06:40.488 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 80: Is awake with 1 messages in the queue
04:06:40.489 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 80: COMMAND_CLASS_WAKE_UP not found - setting AWAKE
04:06:40.490 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 80: Start sleep timer at 2500ms
04:06:40.491 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 80: Got an event from Z-Wave network: ZWaveNodeStatusEvent
04:06:40.493 [DEBUG] [ave.internal.protocol.ZWaveController] - NODE 80: Node Status event - Node is AWAKE
04:06:40.493 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'zwave:device:168ea7b4898:node80' has been updated.
04:06:41.741 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 80: WakeupTimerTask 1 Messages waiting, state MANUFACTURER
04:06:42.991 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 80: WakeupTimerTask 1 Messages waiting, state MANUFACTURER
04:06:42.992 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 80: No more messages, go back to sleepI just went through this about a month ago.
I woke the unit up over and over and over again, usually about 20 times each time I tried, for a week to no avail. I would wait about a minute between each wake before trying again.
Eventually, I decided to watch the log update live, using tail, and just wake the unit over and over as fast as I could instead of waiting between wakes. Using this method I could see the unit advancing through the intialization in the log. I think it would take between 5-10 rapid fire wakes to get through each phase of initialization.
I don’t know if it’s the proper way to do it but it’s the only way I could get both my units working. Just be careful not to break off the battery door. 
Well I’m almost numb trying this but I think openHAB has changed since this trick worked. I saw a discussion on the ZWave addon repository that @chris is considering updating the timeout when adding devices. My issueis that WakeupTimerTask 1 Messages is just not willing go forward past the MANUFACTURER state and it doesn’t seem like the ZCOMBO is sending messages of that type.