Hi everyone. This is my first post to the community. I’m looking for a bit of help with my First Alert ZCombo smoke detectors. A few months ago, I had them working nicely with HA. I included them with my Gen 5 Z-stick and HA created all of the expected sensors for the alarms. A few weeks ago I had to start everything from scratch and after excluding and re-including with my Z-Stick, I can’t get past the “Initializing” phase. None of the sensors are being created. I’ve done this repeatedly, each time excluding and then including but I can’t get things working. Pressing the test button doesn’t seem to wake up the device and update the information in HA. I’m running Hassbian 1.31 with HA 59.2 on a Pi 3. Any ideas would be appreciated. Thanks.
I am having the exact same issue as the original poster. Only difference is I am a new user and this is the first time I attempted to add these to my system. Also I am running as a docker in unraid versus raspberry pi. Any suggestions on how to proceed would be greatly appreciated!
Dan
i would like to know why mine is stuck with “Initializing (CacheLoad)” in the Overview tab too. pls help us
OK, I think I figured it out. This week I switched from Hassbian to Hassio and, as a result, had to re-include all of my Zwave devices. Some battery powered devices apparently stay awake for a brief time after being included. This gives Home Assistant time to go through all of the various Zwave query stages. If the device doesn’t complete it’s conversation with HA during inclusion, you can usually force the device into wakeup mode and it will complete the query process. For example, my Zooz water detectors worked this way. The sensors didn’t get created when I included the devices but after manually waking the devices everything showed up as expected.
Other devices, like the First Alert Zcombo go back to sleep almost immediately after inclusion so the query process doesn’t have time to complete. Even with a manual wake up my First Alert devices didn’t stay awake long enough for the query to finish. I had to go through the wakeup process three times on each device in order to get the sensor entities created in HA. Without manually waking the device, the sensors will probably show up after a number of automatic wake up cycles but the Zcombo seems to wait a long time between wake-ups.
To wake the device, open the battery tray and push it back in while holding the test button. Wait for the chirp and let off the button. Watch the device in HA and you should see the status changing. Repeat until the query finishes and the Zwave status says “Sleeping”. After that, you should have two new entities for each First Alert device called “alarm type” and “alarm level”.
Hope this helps.
3 Likes
I know this thread is a little old, but I have 3 of the combos and am trying to get them paired again after reinstalling HA. I got one to at least be recognized, but it’s not fully initialized. The other 2 never want to show up. I’m using the HUSBZB-1 dongle.
Does anyone have a fool-proof method to get these working or information about why my setup (rpi 3 with HUSBZB-1 and the latest HA) won’t work?
Thanks,
Matt
These things are extraordinarily bizarre; I had to code around some bogons in their firmware to get HomeDaemon-MCP (my code) to work with them.
They are battery powered, and NOT “frequent listeners” (like a lock); they actually do go to sleep like a PIR. The bad news is they don’t support the sleep class, so you don’t get wakeups (which would give the controller a window to send commands to them) and worse, you can’t tell it to wake on some interval (as you can with a PIR, water sensor, etc.)
If that’s not bizarre enough they’ll send a “Health” exception with a code of 255 for “ok” about once an hour. That is, IF your original config goes fast enough (you have 10 seconds!) to get the association set. Otherwise, you don’t get that (or the alarms!) either.
I don’t know how much control you have over the code in this system but these things are “interesting birds”; if I find a way around this I’ll drop back in here and post another note. I don’t think I’ve ever come across a Z-wave device that has this particular oddball set of things going on with it.
Any updates on getting these to work correctly?
i’ve recently installed two of the ZCombo Smoke and Carbon Monoxide Detector without issue. i’m on HASS 0.74.0. i did make sure i paired them when i inserted the batteries for the first time.
This was answered in Dec. 2017:
–
gentlec
OK, I think I figured it out. This week I switched from Hassbian to Hassio and, as a result, had to re-include all of my Zwave devices. Some battery powered devices apparently stay awake for a brief time after being included. This gives Home Assistant time to go through all of the various Zwave query stages . If the device doesn’t complete it’s conversation with HA during inclusion, you can usually force the device into wakeup mode and it will complete the query process. For example, my Zooz water detectors worked this way. The sensors didn’t get created when I included the devices but after manually waking the devices everything showed up as expected.
Other devices, like the First Alert Zcombo go back to sleep almost immediately after inclusion so the query process doesn’t have time to complete. Even with a manual wake up my First Alert devices didn’t stay awake long enough for the query to finish. I had to go through the wakeup process three times on each device in order to get the sensor entities created in HA. Without manually waking the device, the sensors will probably show up after a number of automatic wake up cycles but the Zcombo seems to wait a long time between wake-ups.
To wake the device, open the battery tray and push it back in while holding the test button. Wait for the chirp and let off the button. Watch the device in HA and you should see the status changing. Repeat until the query finishes and the Zwave status says “Sleeping”. After that, you should have two new entities for each First Alert device called “alarm type” and “alarm level”.
Hope this helps.
4 Likes
I did the open/close battery suggestion from above. I have four devices and they paired well, i can see alarm_type and alarm_level. Which you need to code in order to detect fire or CO2.
My devices show in th3 Z-wave panel as “Initializing (CacheLoad)” they do not show as “sleeping” or “ready” but i tested them with smoke and the test button and they do work as expected and provide that data to the Zwave control and i can see the alarm_type and alarm_level changing as expected.
1 Like
I went through this again last night. The open/close battery suggestion worked for me as usual but I found that I also had to restart HA to make the alarm_type and alarm_level entities show up. When I posted this originally, I was running Hassio but now I’m running inside Docker. Not sure if that matters but a combination of the open/close and the restart got everything working.
Can you list what alarm types for co and fire? and do both set the alarm level to 255?
do you use this for notifications or anything?
nvrmnd. found the right post finally.
“For the alarm types, 1 is fire alarm, 2 is CO, 12 is the test button, and 13 is stand by, the value seems to normally be 255, if you press the test button the type will change to 12, after the test is over the value will change to 0. After some time, the type changes back to 13 and the value changes to 255. Note: I haven’t confirmed 1 is fire and 2 is CO, I just read that on another forum, I have my alarm go off if the type ever isn’t 13 just to be safe.”
1 Like
I found that repeating the process of opening the battery compartment->holding the button->closing the battery eventually provided almost full connectivity (Node was finally defined w/ manufacturer and reported as asleep - past initialization). Almost in the sense that, despite testing with actual smoke, I’m not seeing any status change in the HA dashboard. I’m using Hassbian v1.5.0.
Quick question, hoping to not derail the progress of these posts.
Is it possiable to push the siren via zwave to the zcombo when my alarm panel is set to armed or away and a trigger happens?
Thanks in adavance
These smoke alarms will connect using the above method but once you restart, they don’t work anymore. They show up in Hassio (rpi4) but when triggered they do not communicate their status. If you have these can you test them and confirm?
I know this thread is getting old, but figured I’d add some observations here as the advice here helped me after upgrading from zwave to zwave-js.
First the “wake” procedure…(pull out the batteries, push and hold the button while inserting the batteries, wait for the chirp), absolutely +1 that…
Something additional to note if you’re in the situation I was where the node was showing in the list but didn’t have any sensors attached…i’d suggest going to the configuration – devices – click on the node – then click on the re-interview device button…have that all queue up and be ready to hit the “start re-interview” on the popup as soon as you hear that chirp and release the device button.
Additionally, after the device has been re-inventoried, I had to go in and manually enable the 2 disabled sensors (alarmLevel and alarmType) after which the 2nd diagnostic sensor (node status) showed as well.
i have 4 of them. Migrated from ozw to zwave-js (which is great) i run the z-wavejs2MQTT on a separate docker container, not directly in HA, so i avoid restarting the zwave network everytime i need to restart HA.
The issue with these devices is that if the network restarts, you are fried. The devices won’t work anymore and you have to do the wake-up for each everytime a network restart occurs, which is a pain, as these devices are in the celiling…etc. Any ideas? Such a critical device and can’t wake on its own to connect after a network restart?
Sounds like there’s something wrong with your zwavejs2mqtt configuration. Are you sure you have a volume mapped to the store directory?
I also have four of these, one old and three of the newer model. Restarting the Z-wave network has no impact on them at all. All they do is send notifications either on alerts or as regular heartbeats. They don’t wake up on a network restart (no device would), they would wake up on the configured wake up interval.
the behavior was the same when i had to restart OZW. All the other devices on the network wakeup within a day or two and will show interview complete. The smoke detectors stay forever in “protocol info” red bubble. How long so these smoke detectors take to wake?
The old versions never wake up. You should use the procedure explained in the post you replied to so that they complete the interview. If they are in “protocol info”, just do the battery procedure, no need to perform the re-interview. It may take more than one time.