I purchased a First Alert ZCOMBO Smoke and Carbon Monoxide Alarm (link and link) a couple of years ago. As voiced by a few regulars on this community, I do agree that the zwave implementation on this alarm is not so good. From time to time, when I needed to (wanted to) do a fresh install of OpenHAB, I often have a hard time getting this device discovered by the zwave binding. I have read a few recent postings of people having similar problems, and wanted to share what seems to work for me. I hope you will find this to be useful.
Java Version 8 Update 241
Controller is a Aeotec’s Z-Stick Gen5.
OpenHAB 2.5.2 Release Build
If the alarm has previously been paired with the Z-Stick, you will need to un-pair it first. Unplug the Z-Stick and put it into exclusion mode (by holding the button for 2 sec so the orange light is flashing). Then, exclude the alarm by following the alarm instructions.
Do NOT attempt to pair the alarm with the Z-Stick unplugged and in inclusion mode (blue light flashing).
After the alarm is unpaired, plug the Z-Stick back into the USB port and restart openHAB.
After openHAB is online, add a new Thing and select the Z-Wave Binding. Click “Scan” for the binding to search for a new device. At the same time, following the inclusion instruction from the alarm. This will allow the binding to discover the device.
You should now be able to add this device as a thing.
Previously, when I paired the alarm with the Z-Stick unplugged (in inclusion mode), I was unable to get the alarm discovered by the binding (shown as an Unknown Device). It seems the trick is to pair the alarm only when the Z-Stick is plugged in and OpenHAB running.
The log below shows the binding is able to discover and identify the Thing Type as zwave:brk:zcombo_00_000 after Step 4.
It helps, it helps, it helps!!!
I have spent many many hours banging my head against my two FA detectors. I thought I had tried everything and gave up.
I used your procedure and, after a few retries, probably because I’m a klutz, I got them both identified as Things. I am sure your step 2 is what does it.
Some things I also did (maybe because of klutzness) were to:
(1) Delete the two Things that were “unknown” from my previous attempts
tail -f /var/log/openhab2/openhab.log
to watch the log for the restart (= sudo systemctl restart openhab2.service)
to go to completion because on my RPi it takes many minutes.
thanks. I am just now trying to get one of my alarms back on. Weird thing about it though, the log shows that the device is sending information even though there is no thing at all. I did have them before and after an upgrade I had some issue where I had to restore a backup. this then removed the thing itself but not the entries somewhere in a hidden dungeon within openhab that I cannot find. That or, the controller still communicates and the binding shows it in the logs. Crazier is that the secure door lock transferred fine with the update and restore of the backup file. That thing was the hardest inclusion ever and I am not looking forward to the half day in the future of adding it back.
It is definitely on the controller though. I even added the backup xml of the thing and it will not show in openhab, only in the logs and if I use the windows zwave tool, it is in the controller and sending data when I ask for it.
My experience with this alarm is not the greatest either. The documentation is lacking, and the z-wave command support is not much. I do keep my eyes out for other alternatives in the marketplace (z-wave or other), but so far the choice seems limited. I believe these alarms have a typical lifespan of ~7 years, and I am now half way through. Hopefully, by the time I need to replace them, there will be better alternatives. The good thing is that with OpenHAB, I am not really tie to a particular ecosystem, so that will open up more options.
In the meantime, the article I wrote seems to do the trick for me most of the time. Hope it helps you.