Lack of supported zigbee smoke detectors

If you are absolutely dead set against Z-Wave for whatever reason, then please disregard this recommendation. Besides, someone else down the road stumbling into this thread may find it useful.

This Smoke/CO2 detector works perfectly in Hubitat-land

My smoke detectors are wirelessly interconnected (first alert) and I use the Ecolink FireFighter to hook them up to my system. The sole purpose of this listener is to turn on all my lights if an alarm is detected.

A note about the Ecolink FireFighter: the zigbee version does not work with hubitat. I ended up giving mine away with my ST hub and ordered the zwave version.


Thanks for the link to the BRK relay. I have a house full of BRKs.
There wouldn't be a way to distinguish between smoke and CO, would there?
Supposedly the Ecolink unit can distinguish between the two, but I can see the relay being more reliable.

I have nothing against Z-Wave... I'm just not using it, but I have a pretty decent zigbee mesh going on now so I would like to keep my network homogenous.

1 Like

Thanks for a lively discussion.

Just to make some things clear:

  1. I live in Iceland where we don't (to my knowledge) have any mandate on having interconnected smoke detectors in residential homes.

  2. I prefer Zigbee since that's the way I went with my current network. The smoke detectors would be my only Z-Wave devices which would probably require me to get some repeater devices for that protocol as well as the zigbee ones I already have. This is not something that interests me much.

  3. I would not dream of relying on the Zigbee functionality as the only means of notification. I'm assuming that all smoke detectors (smart or not, zigbee or zwave) would have a built in siren that would go off if smoke is detected. The situation is pretty simple, I have to have smoke detectors, I'm either buying regular ones (which are not interconnected) or I'm buying smart ones. As the smart ones include exactly the same functions as the non-smart ones and only add the communication ability on top, I want to go that route.

  4. Given the above, I don't really see the point of buying cheap, non-interconnected smoke detectors and then add a device that listens to them when/if I can buy a single unit with both functions built in.

  5. The reason for wanting Zigbee would be to try to turn on lights / send notifications to phone etc. If that were to fail, I'd be no worse off than having the dumb smoke detectors anyway... but if it didn't fail I might benefit from it. So it's a no-lose type of thing... but I do realise that I cannot rely on Hubitat/Zigbee for safety devices.

Hope this explains my situation a bit better.

Er, I looked into all of this during a slight remodel a year or two ago. Long story short, couldn't justify the cost of any smart smokes.

Instead however (and I think this is a hell of a lot better for a number of reasons), I did get a sparky to install some standard physically interconnected AC smokes (fire angel, from memory). One goes off, they all go off. Bonus points for these guys is that you can happily purchase a mount (just need one, because obviously they're all connected) for a couple of quid which includes a dry contact relay.

Which... wooo...! Connects to one of my most favourite devices in the world, a nodemcu flashed with konnected firmware. I must have about 20 of these dotted around the house, they're awesome. Used to use the same setup connected to a fibaro ubs on smartthings before i learned to hate, well, both smarttthings and fibaro =p

With the relay, you can happily connect to non-smart devices with ease (smokes go off, siren goes batshit!), and with the addition of the nodemcu, that makes all sorts of cool smart stuff possible too (mine texts me if the smokes get set off/tested).

Replacement smokes are less than 20 quid when they invariably need to be replaced (5 years, maybe, off the top of my head?). Can't go wrong.


I'll chime in. My house came with interconnected ionization smokes. I added (stupidly?) photoelectric and co detectors, also hardwired, so my ceiling has got all these warts on it.

I've found that pe sensors are subject to more false alarms-I blame spiders. I actually did an autopsy on an alarm, and there was the web by the sensor.

My point is, tracking down a false alarm is tough. You're craning your neck, looking at the ceiling for a tiny light that blinks more than usual. Maybe the talking ones are better, I don't know.

With the smart detectors, you'd know which one went off and could even have some logic alerting you somehow during the event.

If it's a retrofit, no brainer.

There is no way to determine whether the smoke alarm went off due to CO or Smoke when connecting a relay on the interconnect wire. My detectors detect both CO and Smoke and my relay has never failed to notify HE when a detector alarms. I don't believe I have ever had a detector alarm due to CO, to date it has always been cooking in the kitchen, so it is obvious it was smoke. If my alarm ever goes off without any smoke apparent, I would have to find the detector that caused the alarm condition and check its LED status for Smoke or CO.

The Relay I posted above is made by BRK but it would work on any interconnect wire between smoke alarms. You could use the one made by Kiddie if you prefer:

Yes, I would consider the relay more reliable. It is not an IOT device (just a simple relay) and if it ever failed the interconnect between hard wired smoke/co detectors would still work fine. I would just lose the signal connection to the contact sensor.

If the other side of a relay is an MCU, Arduino as an example, it is possible to tell whether a smoke or CO is detected on the interconnect line. When smoke is detected, the line will be pull up to 9V and stay there as long as a smoke is detected.

CO detection may be non standard use of the interconnect line. Basically, the interconnect line is used to send a switching signal. The line will switch between high and low unlike when it detect a fire/smoke a constant high pull. This signal may be intended to be able to send code for different type of faults. The signal is relatively short so that the old continuous pull up the line for the smoke detection does not get mistaken as this newer signal.

Today, the only signal is a CO signal from my personal observation. Therefore the signal is not important. If you sample the interconnect fast enough from the signal transition to high and the last transition to low, the sampling data will tell you whether it is a smoke detected or co detected. When the sampled data is all high, it must be a smoke detected. If the signal has any low value during this sampling period, you know that it is a non smoke detected. Today, this may be assumed a CO detected.

BTW, While studying the signal, I believe that there are CO specific relay. I forget about where I found it. If one have both the smoke and co relay and use 2 different GPIO pin, one can differentiate the CO and Smoke events. This is another alternative.

I make a Zigbee Environment sensor that connect to the interconnect smoke detector a while back. I agree with op that Zigbee smoke detector is kind of rare.


1 Like

Thanks, I stand corrected. My Christmas project is an Arduino board to read my water meter. This will be next to the location where I currently tie into the Smoke/CO interconnect. If you end up remembering where you saw the CO relay, please let me know, easy enough to tie both relays into different pins on the Arduino board.

I just google it. As an example, The Kiddie relay for smoke is below. Based on the theory, the relay should detect smoke for any vendors.

For CO, kiddie has the following.

This relay may only work with kiddie only. It is a signal. The signal eventually interpreted into a code. This code can be different from one vendor to another. I am no sure how the signal is standardized. I would assume that this only work with Kiddie CO detector.

Since you will be working with arduino or MCU, I think it is probably more economical to just wire the interconnect wire to the arduino GPIO. I did mine with optocoupler. The 9V signal is too high for my 3.3v MCU. I also want to make sure I have enough isolation between the interconnect line and the arduino.

I hope it help.

Finally somebody who answers the question! :wink:

Hoooow did I miss that driver!? I'm using markus-li's driver for a bunch of Aqara devices. So this changes everything. That's what I'll buy.

But just before I do that... does everything look like it's working okay for you? Just to be sure, the aqara smoke detector works just like a normal (dumb) smoke detector right? I mean, it has a built in siren and works even though it isn't connected via zigbee right? Are you getting proper battery status reported in Hubitat with the markus-li driver?

1 Like

Hands down, Nest Protect are the best in my opinion. Not only for the features, but they just never give false alarms. Maybe thread (which they do have a version of) finally being utilized will eventually being them into the fold.

Meanwhile, since I’m already an iOS user with HomeBridge and HomeKit automations setup, I just use a Homebridge plugin that works nicely to trigger a virtual switch in HE when there’s a Smoke or CO emergency in the Nest Protects.

Not to be a contrarian, but when I used Nest Protect (v2) about 5 years ago I had multiple units that would give false alarms. And Nest couldn't give a ■■■■ less. Essentially told me "oh well, buy new ones". Luckily I bought a new house a year later, so left those turds there when I moved. lol

Worst $700 I ever spent. But I have seen way more positive experiences than my negative experience... So I assume I was just unlucky.

All the posts in this thread are an answer to the question you posted above.

If you use Xiaomi, you can also use this driver.

Mine are all the battery powered type. Maybe that’s different? :man_shrugging:t3:

But, I did by a Mains powered version for my parents and it hasn’t given any false alarms in the year it’s been installed.

I only had 1 battery powered one, and it never false alarmed. :slight_smile:

Like I said, I know way more people that had good experiences than bad with them. Which makes sense, as people wouldn't be buying them for the price if they didn't work for most!

Unfortunately for me it was an expensive, painful experience though. For whatever bad luck/reason I had. lol

1 Like

Thanks. I did mention that one in my original post but I believe it's not being maintained anymore. At least it's been 17 months since the last changes were committed to it:

I believe the markus-li drivers (which Carl pointed out) are more actively maintained so I think I'll go for those.

I use this zwave 2-in-1, mainly because it integrates into my Ring monitored alarm. The only negative is that they don't sync with each other, meaning if one goes off they all would not sound.

I'm sitting here this morning figuring out if I replace the hard wired one that went out at 4am with another one of these kiddie ones, even though it isn't hardwired.