Zwave Smoke Alarm - Issues and Recommendations

I had a set of the original FirstAlert Zwave Smoke/Carbon combo aka ZCOMBO at my first home and purchased another set of the latest release about 3 years ago for my new home.

I had the issue with the first gen where it will never report a low battery, even though the device is beeping to let me know the battery is low.

I was hoping they fixed this issue in the latest version that I bought 3 years ago, but that doesn’t seem to be the case.

It will let me know when the fire alarm is going off but will never let me know when the low battery indicator is going off, even though all the batteries show at 80% or more.

Has anyone had a similar experience?

Any recommendations?

I may switch to a new product, but First Alert seems to be the only Zwave Smoke Alarm.

I thought about Wi-Fi ones, but I have nearly 100 devices on the network already, and close to the capacity for my firewall licensing, so I don’t want to add 6-8 new IP’s on the network if I can help it.

I don’t run ZigBee, but I would be willing to try as long as it doesn’t interfere with Zwave.

The big problem I have is my house is an open platform with tile everywhere, so when one of the devices starts beeping, it can take a while to figure out which one it is.

Any thoughts or recommendations?

The device doesn’t send regular battery notifications, only when it reaches < 75% battery level. I’ve never left batteries in long enough to confirm if that happens because I don’t want to hear the beeps, which start at < 77% battery level.

Performing a test, or powering it on and off, are the only ways to update the battery level.

So besides replacing the devices, you could run the tests on all and see which report < 80 (to be safe). The LED also blinks on the ones with low battery.

Thanks for replying.
How often do you replace the batteries?
I didn’t notice a blinking light, but I’ll double check that when I get home.

I don’t really track battery changes for these, it’s so rare. The one time I did record a change, the batteries had lasted 785 days.

Huh? What licensing? The limitation to the number of WiFi clients is usually the router running out of memory for the routing table. I have 115 on my network.

Zigbee and Z-wave are on different frequency bands. Zigbee and WiFi are both on the 2.4GHz band, but real interference between them is unlikely

You should be able to trigger an automation on the alarm state. because the protocols expect interference and adjust for it. Zigbee in particular uses frequency-hopping.

Which model? All I can find on the First Alert website are Z-Wave.

Thank you both for you replies.
Something new I learned when I was looking the Master Smoke Alarm (the one that started all of this) was at 80% battery life. As mentioned before no low batteries notifications were present.
Upon further inspection I was looking at the device entities, and under the diagnostic entities it showed: System Hardware Failure as “Problem”. The rest are listed as “Ok”.

This had happened after I left for work, and I received messages saying it’s beeping and dogs not have a good time with it.
It was interesting that after pinging the node, and issuing a “refresh values” request that it some how stopped the beeping and resolved the issue.

So, now would be my next question if anyone else has ran into that issue. Should I be concerned about that or, maybe it’s just the way it’s trying to tell me the battery is low?

I run a enterprise grade licensed firewall, not just the basic ones out of box. If I want to run more devices, I want need to up my licensing. So, it not specifically about the WiFi, it’s about the additional IPs. Sure I could probably tuck some things behind a separate subnet or VLAN, but in addition to that I also have a dozen cameras running over WiFi right now, so until I hardwire them, I try to limit WiFi traffic and devices. The system itself can handle 350 WiFi devices.

Thank you for sharing. I wonder if it is just as easy to setup and manage a Z-Wave.

These are the units I have:

But, maybe I should clear that up. I was saying First Alter is the only one that I am aware of that is selling a Z-Wave Fire Alarm. I haven’t looked into Zigbee ones just yet, I’ve looked at the Wi-Fi ones. I did look at the Zooz product that hardwires into a Dumb-Smoke Alarms, but it’s won’t help with the battery detection either, only the smoke detection.

Thanks for sharing. Based on the text messages (only record I have lol) it looks like I change all of them in December of last 2022, so with a little over 800 days, I guess it make sense that it’s time to change it. The rest of them are still around 80-83%, the one that was going off is in the Master which the Alarm sounds quite frequently due to the steam from the shower, so it makes sense why this one would be lower.

This very helpful information, I think I’m going to swap them out when they hit 80%.

Doesn’t seem related to low battery. According to the Z-Wave docs (you can search for BRK_ZCOMBO_Z-Wave_Specification_11.0.pdf) that notification is sent for “Malfunction Detected”, “When the Smoke sensor malfunction is detected”. Unfortunately there’s no more information given than that. Pressing the silence button is supposed to clear it.

I was saying First Alter is the only one that I am aware of that is selling a Z-Wave Fire Alarm.

I believe this is true in the US. I have not seen any other Z-Wave smoke detectors.

That’s exactly what I do, I use a card on the dashboard to make the battery entities for these devices visible at <= 80%.

I just pulled that up.


Sounds like it needs to be replaced. I doubt it’s under warranty.
Thinking about it now, when I replaced the battery, I wasn’t able to get it to self test, I had to close and open the battery door a few times before it finally started doing the self-test.

I did order them through Costco, I wonder if they will let me still return them. LOL

If you’re in replacement mode, and if your smoke alarms are hardwired, you might take a look at the Zooz ZEN55. It connects to an existing non-smart smoke alarm (if it has the necessary interconnect wiring) and sends out status and alerts via z-wave.

https://www.getzooz.com/zooz-zen55-dc-signal-sensor/

My big question is, can I silence the alarm from Home Assistant? Ours doubles as a dinner bell. My wife can’t fry anything without the smoke alarm going off. (And she is a terrific cook).

It’s a slippery slope if you change from monitoring any kind of life-safety alarm to controlling one. Having control capability leads to requirements for redundancy, certification, and a host of other issues that traditional alarm systems have had a century to work out and codify. You could have issues with insurance coverage in case of an actual fire, as just one example.

Note the warning on the Zooz product mentioned above: “NOTE: The device is NOT a life-safety security product. Check your local regulations before installing.”

Yea. That was the one I was looking at. The downfall to it is, it can’t tell you which device is low battery, or which device is triggering the smoke alarm. Those are two features I really want.

I couldn’t find it myself, but as I mentioned I pinged it, and refreshed it’s values, and stopped beeping.

Yea. It’s an inherent risk, but I’d rather know what’s going off then not.
If the house is going to burn, then it is going to burn, the beeping will not put the fire out.
Obviously, if there is some sort of inspection, then you may want to revert back to the dumb-smoke alarms temporarily.

I have four of these; they all report battery level; hence confusion on what you are seeing.

I do run an automation once a day to update:

- id: "fa_workshop poll zwave battery"
  alias: fa_workshop poll zwave battery
  description: "Automation to periodically refresh zwave battery values"
  trigger:
    - platform: time
      at: "23:00:00"
  action:
    - delay:
        minutes: "{{ range(0, 60)|random|int }}"
    - service: zwave_js.refresh_value
      data:
        entity_id: sensor.fa_workshop_battery_level

I can see from the battery last updated that I am getting an update every 24 hours even though the level is not changing as often anymore.

Guess I should have double-checked my data. Looks like I was mixing up some behavior between first and second gen devices and misspoke.

The first generation of these detectors doesn’t support Wake Up CC so it’s impossible to query the battery level. However they do seem to report battery levels once-per-week, according to my logs.

The second generation does support Wake Up CC with a fixed wake up interval of 70 minutes. So you are free to manually update levels with the refresh_value action at least every 70 mins. These also appear to report unsolicited values, mine just hardly or never change for it to be very noticable.

Here’s a year’s worth of reports for my 4 alarms:

Two of the devices report 100% over the year, these have lithium AA batteries which you aren’t supposed to use since it does affect the reporting (levels are based on battery voltage) (I’m not too worried since I test monthly, but I should switch back). The other two have regular alkaline batteries and normal reports decreasing reports. Going back more than 1 year in the history I only change the batteries after more than a year.

FYI, Z-Wave JS automatically queries battery levels every 7 days if they are stale. So consider whether you want daily updates, which will drain the battery faster, or are OK with weekly updates.

Both of these devices support heartbeats so if you need liveliness checks you could use those instead of relying on battery (if that were a reason).

For liveliness I use the node_status going to awake from sleeping. Heartbeat is not something I’m familiar with. I’d listen to a CC? Do you have an example?

1 Like

Gen2 sends a standard heartbeat notification:

23:59:03.796 DRIVER « [Node 012] [REQ] [BridgeApplicationCommand]
                      │ RSSI: -60 dBm
                      └─[Security2CCMessageEncapsulation]
                        │ sequence number: 82
                        │ security class:  S2_Authenticated
                        └─[SupervisionCCGet]
                          │ session id:      21
                          │ request updates: false
                          └─[NotificationCCReport]
                              notification type:   System
                              notification status: 255
                              notification event:  Heartbeat
2025-02-27 23:59:03.799 INFO STORE: [Node 012] CC Notification notification {
  type: 9,
  event: 5,
  label: 'System',
  eventLabel: 'Heartbeat',
  parameters: undefined
}
23:59:03.801 CNTRLR   [Node 012] [Notification]
                        type:  System
                        event: Heartbeat

You can trigger on the zwave_js_notification event using the CC Notification fields, if you want to specifically check for heartbeat. These occur ~1 hour, similar to wake up. Events can be annoying though if you want them as an entity (require trigger-based entities), for that reason I think there are plans to add event entities when possible.

In the general case I’d use the “last_seen” sensor, since that would avoid missed wake up notifications, assuming there is other activity.

For this particular device that wakes up every 70 minutes, using node status is fine. I set most of my devices to minimum 1-week wake ups when I can, so “last_seen” entity or heartbeats are better sources for me.

Gen1 sends also sends an hourly heartbeat via Alarm type value 13. I think this is translated to a System Heartbeat notification due to Z-Wave JS’ alarm mapping, but I didn’t confirm.

@PeteRage
It is reporting the battery %.
However, my issue was that it was beeping, but only at 80%.
Also, thanks for sharing your automation script.
FreshCoast informed us the low battery indicator doesn’t come on until 77%.
So, it was odd that it was beeping before it was at 77%
I later discovered it was actually beeping to tell me something was malfunctioning with It, which I wasn’t even aware that was option until then.

@freshcoast
At least with the version 2, it looks like you can change the 70 second wake up interval through Z-waveJS

Here is my historical levels:

The dialog box allows you to change it, but it’s not configurable. Min and max are both 4200:

    {
      "id": "11-132-0-wakeUpInterval",
      "nodeId": 11,
      "toUpdate": false,
      "commandClass": 132,
      "commandClassName": "Wake Up",
      "endpoint": 0,
      "property": "wakeUpInterval",
      "propertyName": "wakeUpInterval",
      "type": "number",
      "readable": false,
      "writeable": true,
      "label": "wakeUpInterval (property)",
      "default": 4200,
      "stateless": false,
      "commandClassVersion": 2,
      "min": 4200,
      "max": 4200,
      "step": 0,
      "list": false,
      "value": 4200,
      "lastUpdate": 1740876856107,
      "newValue": 4200
    },

Pretty sure I tried to change it and it just gets ignored.

I am not sure I understand, but can you explain why you are replacing batteries when there is 77% still left? I am evaluating this product as well and trying to see if there are any gotcha and bugs I should be aware of

I don’t like devices beeping continuously.