If you’re using a recent 1.8 snapshot, or 1.8 release, then this should be the same as the 1.9 snapshot and I believe it should have the code that initialised based on the NIF frame (ie that should work with the ZCOMBO).
Chris,
Thanks, downloaded the addons package again and moved the .jar file over. Must be newer than the .jar i previously had that habmin showed as version 1.8.0.201508211938 (probably came from apt-get repo).
Did the battery remove/reinsert and it came right up.
Thanks!
lordsiris
To others using this device what are your item settings? I currently have:
Number zcombo_basement_battery “Basement Battery [%d %%]” (Smoke, Basement_Smoke) {zwave=“17:0:command=battery”}
Contact zcombo_basement_smoke “Basement Smoke is [%s]” (Smoke, Basement_Smoke) {zwave=“17:0:command=sensor_alarm,alarm_type=1”}
Contact zcombo_basement_co “Basement Carbon Monoxide is [%s]” (Smoke, Basement_Smoke) {zwave=“17:0:command=sensor_alarm,alarm_type=2”}
At first I got a battery status for a while, but since then it has gone away and I haven’t gotten any other status. Is that normal? The indicator in the zwave binding area is not green but gray, guessing that means it hasn’t woken up in a while?? How often does it report status, or does it just not report anything until an actual alarm is triggered?
Thanks!
I just triggered one of my zcombo’s to generate the node.xml file and upon review of the generated file it looks like this device does not support the alarm_sensor command class, only the alarm command class.
{zwave="5:command=alarm"}
It isn’t clear what you get with this command class. I’ve simply bound it to a switch and I’ll experiment from there. But the big take away is that I don’t think we can distinguish between a CO2 alarm and a smoke alarm. We can just tell if the alarm is going off.
I must have tried this 10 times without success. Attached is a screenshot showing the latest bindings are installed. I did the battery slide trick while holding the test button and did hear a beep. I have a couple grayed out nodes, which I assume are failed bindings attempts (wish I knew how to delete them) when I had put the controller in include mode. How can a new node get included without using the include mode on the controller? I also tried without putting my Z Stick in include mode, and did not see anything happen. Anymore tips? Thanks!
The comment replied to was how to wake the device up. To include, you do have to have the controller in include mode.
So the gray node means included but sleeping? If I slide the battery in and out should it turn green? Anything I have to do in OpenHAB so that the wake up event is detected? Its gray and always gray. Thanks!
I read in this indigo link its very tricky with the timing. Is there way I can force a quick “sync” on OpenHAB? My concern is that on start OpenHAB is not syncing in time.
With the zsmoke it appears you have to push the button on the z-stick first then hold the test button on the zsmoke as you slide the battery tray in. You will see the z-stick do its flash thing and then you have 30 seconds to run to the computer plug the z-stick back in and then add and sync the device in indigo. It only stays awake for 30 seconds (it beeps once when it leaves the awake state) which makes pairing the device in its final resting place a little difficult.
Nothing that complex here. If it has included to the controller, that is all you need. If you want to speed up the process of it coming online, then you can go through the wake-up proceedure a few times, and it should eventually go green. Else, just wait. It will wake on its own and go green eventually too if it is included.
Sorry to revive an somewhat old thread. Ive read through all of these a few times. I’m running the 1.8.3 bindings. I still cant get the Zcombo working right. Ive got it paired to the controller so that it is showing habmin and is grayed out. I do the wake by sliding the battery tray and pushing the test. I can see a ton of information flowing in the logs.
A refresh of HABMIN turns red. pushing test on my detector show no new information in the logs.
I see in the logs “RequestNodeInfo” keeps failing
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