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.
well that is the whole point. They have completed the interview. All green now. If i restart the network i will need to wake them up again, otherwise they will stay forever in “protocol info” state. I don’t want to climb with a ladder everytime to each device to do the wakeup procedure. Maybe i have the old versions then. It says firmware 0.5
Sounds like there’s something wrong with your zwavejs2mqtt configuration. Are you sure you have a volume mapped to the store directory?
Please confirm this.
Confirmed. i have a volume mapped to a store directory and there are files there being modified as we speak. This issue only occurs with these devices not any of the other 33 in my network, of all kinds and manufacturers. I was hoping this was an OZW limitation, it remains in zwaveJS, maybe it is the device’s limitation
Mind posting your docker run command, or compose file? I’ve had the original ZCOMBO for years and have never encountered an issue like this. The interview state is held in the cache files. If the cache file is lost, then interviews are required again. It sounds exactly like your cache file is being lost.
All the other devices on the network wakeup within a day or two and will show interview complete.
What did you mean by this? It’s not normal for any battery device to have to re-interview.
If everything is configured correctly and you see this problem, then I would submit an issue, because it’s not normal for information about battery devices to just be forgotten.
ok, see the following screenshot, so you see what i am referring to, look at the interview column. After restarting the smoke detectors remain in that “protocol info” state forever. All the other battery powered devices, wakeup eventually and turn from red to green “complete”
Here is my compose file:
version: "3.7"
services:
zwavejs2mqtt:
container_name: zwavejs2mqtt
image: zwavejs/zwavejs2mqtt:latest
restart: always
tty: true
stop_signal: SIGINT
environment:
- TZ=America/Los_Angeles
networks:
- zwave
devices:
- '/dev/serial/by-id/usb-0658_0200-if00:/dev/zwave'
volumes:
- ./store:/usr/src/app/store
ports:
- "8091:8091" # port for web interface
- "3000:3000" # port for Z-Wave JS websocket server
networks:
zwave:
volumes:
zwave-config:
name: zwave-config
The compose file looks fine. You’re not using the zwave network nor the zwave-config volume, the store is mapped to the local ./store directory instead, but that doesn’t affect anything.
After restarting the smoke detectors remain in that “protocol info” state forever. All the other battery powered devices, wakeup eventually and turn from red to green “complete”
This is completely explained by a lost or corrupt cache file, but I’m not sure how that’s happening yet. When this happens, all nodes are reset back to the ProtocolInfo interview status. Mains-powered devices will be re-interviewed immediately during startup. The battery devices will re-interview the next time they wake up, which is exactly what you describe. Devices that never wake up on their own, like the original ZCOMBO, will be stuck there until you manually wake them up.
The only way for an existing device’s interview status to go from Complete to ProtocolInfo is either a) the cache file is lost/corrupt, or b) you’ve done a re-interview on the device. Unless you’ve been doing re-interviews, then it would have to be the cache file. The devices aren’t doing anything to get in this state.
If you have a driver log file that shows the last restart, feel free to post that and maybe it will show something. If not, I would enable the debug logs for the next restart, and post them when you can. There are instructions here on how to enable debug driver logs and download them. Be aware that saving the configuration after changing logging might restart z2m, so only do it when you’re prepared to.