core: First Alert ZCOMBO-G Z-Wave missing smoke/CO2 entity - Zwave JS

I’m experiencing the same issue as @wheindl and @jazakzewski, mainly the node is added but never awakens or shows any activity. I can repeatedly add/remove the node but nothing else. It never detects the type of device.

Update: What worked for me (as others have suggested) is after the node has been added, go back and re-interview the node while simultaneously performing the pairing steps (pull out battery tray and remove batteries, then re-insert and slide battery tray back in while depressing the test button until you hear the beep).

I have determined that the loss of the entities is likely a result of the change in the typing of the notification CC values. The Zwave-JS websocket server API as well as the Notification CC V1 handling within zwave-js has been changed. Previously the alarm notifications were typed as “any” and now they are typed as “number” with explicit bounds.

To get the ZSMOKE and ZCOMBO working again delete all the alarmtype and alarmlevel entities in the device page, then go into the zwavejs2mqtt control panel, and reinterview the node. Then quickly awake the alarm by pulling the battery tray out for a few seconds hold the test button down insert the battery tray and release the test button when a slight chirp is heard. It might take multiple tries. When the alarm is reinterviewed new entities will appear and they should work.

The JSON differences for the node before and after the reinterview are attached if it is any help to developers.

broken.txt working.txt

You should also see a disabled entity named something like sensor.smoke_and_carbon_monoxide_alarm_smoke_alarm_alarm_status. This is the “raw” notification status. It will switch between “idle”, “Smoke detected” and “Smoke alarm test”. It’s a translation of the the alarm values.

The binary_sensor.smoke_and_carbon_monoxide_alarm_smoke_alarm_smoke_alarm_test entity is generated from the same “raw” notification status used above. It’s on/off when the raw status is “Smoke alarm test” / not “Smoke alarm test”.

Yes, I think you should see a binary_sensor.smoke_and_carbon_monoxide_alarm_smoke_detected (or similar) created when real smoke alarm notification is sent by the device. This sensor would be generated the same way as the Smoke alarm test binary sensor. I would hope it is created without a restart, but I’m not sure. Instead of a total HA restart, you can also restart the integration only.

Peanut Gallery: I am pretty sure you have ZCOMBOs and not ZCOMBO-Gs. The former is older, and uses the old style “Alarm” CC.

First Alert has done a really bad job on making the docs discoverable, and they seem to mix the two up. (The docs that claims to describe the zwave behavior of the ZCOMBO actually describes the ZCOMBO-G)

I recently moved to zwavejs on my HA setup, and was able to get alarmType and alarmValue updating as expected during a test, and I now have a basic automation that monitors them. However, I have a PR open w/ zwavejs to add alarm to notification mappings for these, so they would follow the normal zwave stuff.

I’m probably a bit rambly, since it is quite late here.