Smoke Detector - Recommended devices

I‘m currently looking for a smoke detector with the following characteristics:

  • Can be hooked up to openHAB
  • No need to be run via a cloud service (e.g. smart life)
  • Group alarm (meaning: if one gets triggered, all get triggered), ideally via the detectors talking straight to each other (rather than: via a cloud service or via openHAB rules → having to rely on „something else“ to be working)
  • Not too expensive

What I found out so far:

  • Blakadder describes here how to bring Tasmota to some devices. However, being fully responsible for the software and configuration of a device that should detect and trigger an alarm 100% reliably does not feel that comforting.
  • The Nest A13, the Xindum SM11W and the X-Sense XS01-WT do offer group alarms, but require the Nest or the Smart Life Cloud Service.

Any recommendations?

I have a solution that works but it might be a bit convoluted.

I have 4 x Kidde KF10 mains/battery backed smoke alarms plus a CO detector. They all talk to each other so if one detects, they all sound. You can get an SMK23RU base unit that has a relay that closes when any alarm sounds. In my case, I took the relay out and put it in a separate box but it’s neat in the detector base.

In my case, the relay is connected to the fire input on my intruder alarm panel, which is in turn monitored by Alarm Decoder into OpenHAB. You could use the same setup with whatever means of detecting the relay into OpenHAB that works for you.

The setup conforms to a couple of principles of home automation that I have learnt:
Buy kit from companies that specialise in it, not from tech companies. (Eg smart heating controls from Drayton or Honeywell, not Amazon. Smoke alarms from Kidde not Google.
Set it up so that OpenHAB monitors it but it can perform its basic function even if OpenHAB isn’t running.

1 Like

The Nest Protect is generally considered to be one of the best devices on the market. I agree that you have to be careful about companies (not just tech companies) going into unfamiliar markets, but that doesn’t preclude them from being good. It is also not a given that a specialist company will produce the best products.

Saying that, I wouldn’t touch any Tuya-based smoke detectors (anything that works with the Smart Life app), because those are mostly white-labelled products. The problem isn’t that they’re sold by tech companies–it’s that they’re sold by companies who aren’t researching, designing, testing, and standing behind their own products. What matters is that someone cares about making the best smoke detector.

I completely agree with this, which is why I’m not concerned that my Nest Protect doesn’t talk to openHAB. If the alarm goes off at night, I can turn on the lights myself (assuming the power isn’t out). If it goes off while I’m out of the house, there’s nothing that openHAB can do to help me get home faster or call the fire department.

The Nest Protect requires the cloud service for setup and to send notifications via the app. However, it doesn’t depend on access to the Internet/cloud for basic functionality–that would make it extremely unreliable. This is the same for every connected smoke/|CO detector. If you have multiple Nest Protects, they’ll work locally to sound the alarm and only use the cloud to notify you via the app.

If you’re anti-cloud in general, then I guess that rules it out. But I personally wouldn’t want to rely on openHAB to notify me of a fire when I’m not at home.

There’s an extended discussion about the Nest Protect here, including how its group alarms work using Weave (not WiFi or a wire).

It’s expensive, but for the price you’re getting much more than “detects smoke, sounds alarm, wakes neighbours”. Even if I never have a fire (fingers crossed), I’ll still feel like it was a worthwhile purchase.

2 Likes

You know these threads ?

1 Like

Thanks @barneyd, @rpwong & @Wolfgang_S. I am a bit embarrassed I did not find those great threads myself (I did do a search before creating mine though).

I was hoping for the one dominant solution, but this appears not to be the case. Will investigate.

Quick update: I followed @Oliver2’s recommendation in the thread…

… and settled for the HmIP-SWSD.

My main rationales:

  • Available in my region (Germany)
  • Not cheap, but also not too expensive (€ 59), unlike Nest
  • No need to be run via a cloud service (e.g. smart life)
  • Group alarm
  • No need to tinker around (like with some of Blakadder’s solutions). Not that I wouldn’t have enjoyed it, but doing so on a security-relevant device would’ve felt odd. Plus, from what I unerstood, those solutions would’ve relied on openHAB to perform a Group Alarm.
  • Low maintenance (10 year battery): I saw some devices that operate with WiFi and thus have a higher energy consumption
  • Can be hooked up to openHAB (I do operate a CCU2 already, so no need for an extra gateway)
  • Extra goodie: Can be used as an alarm siren.
1 Like

I had exactly the same arguments. Good choice.

Is anyone aware of a good documentation on the available channels of the HmIP-SWSD smoke detector? I remember a rather large but convoluted and mostly useless .pdf from eQ-3, so I am curious on whether there’s a good list somewhere of what the channels are, whether they are read/write and what the characteristics are per channel.

here you go:

Time Of Operation Status
0#TIME_OF_OPERATION_STATUS (String)

Duty Cycle
0#DUTY_CYCLE (Switch)
Time limit

Delete Device Mode
0#DELETE_DEVICE_MODE (String)
Deletemode

Install Test
0#INSTALL_TEST (Switch)
Installationtest

Config Pending
0#CONFIG_PENDING (Switch)
Indicates a pending config update

Time Of Operation
0#TIME_OF_OPERATION (Number)
Time of operation

Rssi Device
0#RSSI_DEVICE (Number)
Signal strength

Delete Device
0#DELETE_DEVICE (Switch)
Delete device

Rssi
0#RSSI (Number)
Unified signal strength

Signalstärke
0#SIGNAL_STRENGTH (Number)
Signal strength as with values 0 (worst), 1, 2, 3 or 4 (best)

Firmware
0#FIRMWARE (String)
Version of the firmware

Niedriger Batteriestatus
0#LOW_BAT (Switch)
Low battery warning with possible values on (low battery) and off (battery ok)

Unreach
0#UNREACH (Switch)
Device communication status

Update Pending
0#UPDATE_PENDING (Switch)
Indicates a pending update

Rssi Peer
0#RSSI_PEER (Number)
Signalstrength Peer

Smoke Detector Alarm Status
1#SMOKE_DETECTOR_ALARM_STATUS (String)

Error Degraded Chamber
1#ERROR_DEGRADED_CHAMBER (Switch)

Error Code
1#ERROR_CODE (Number)
Error code

Smoke Detector Test Result
1#SMOKE_DETECTOR_TEST_RESULT (String)

Smoke Detector Command
1#SMOKE_DETECTOR_COMMAND (String)
1 Like

Be extra cautious about wireless smoke detectors. Here’s why.

You should classify your devices in separate groups, depending on their criticality. For example, if a motion detector for stray cats on my new lawn doesn’t always trigger the water sprinklers, I can tolerate that. Turning lights on and off in the house, I’d have no tolerance for a button not working when I press it, even if it happens just once per year. And life-critical detectors for smoke, fire or poisonous gases, those not only must work every single time, but be completely immune to perturbances or interferences that may prevent them from working.

HomeMatic IP radio protocol enforces the “duty cycle” limit for each device. This is the legal regulation that any device transmitting in the free band of 868MHz is allowed a broadcast time of maximum 1% per hour. So if you have for example a motion detector in a high traffic area, it will keep transmitting “movement detected” until it has added up 36 seconds of transmission time in the past 3600 seconds, then will stop transmitting for the rest of the hour.

If that motion sensor is among the low critical devices, where the lack of functionality is not going to cause a significant issue, that’s fine. But would you risk your life because your choice for home automation’s protocols stop working on purpose? If your other HMIP components are causing your CCU to frequently hit 100% of that duty cycle, the CCU will receive the alarm from one of the smoke sensors but will not be able to transmit the trigger message to other sensors, evacuation lights, or a siren.

Ideally, the smoke sensors would be part of a completely independent, wired alarm system. If you must go wireless, pick a technology that does not overlap with anything else in your surroundings and does not depend on any device outside of the enclosed system. I’ve seen people use WiFi smoke detectors - what if your power goes out (perhaps related to the fire) and your WiFi network is down? What if you live in a high density condominium where there are 60 WiFi networks from all neighbors and the WiFi collisions are so frequent that most of your devices are repeatedly knocked off the network and continuously either reconnecting or retransmitting packets?

I used the wireless system from Ei Electronics, an Irish company specializing in this kind of equipment. Specifically, I have installed 11 smoke detectors model Ei605CRF-3XDR and one output interface Ei428-D. They work with regular 9V batteries. The wireless module (optional, if you don’t want to use the wired interconnection) also uses the same 9V battery for power, unlike most other radio smoke detectors whose radio module have a soldered-on battery lasting 3-5 years then you have to throw out the radio module as well and buy a new one. So when the smoke detectors need to be replaced in 10 years, I no longer have to spend extra on the radio modules. All devices create a radio “mesh” communicating one with the others directly. There is no need for any central system or cloud-based service, or existing WiFi network or anything like that. There was an extra status and control panel I could install as well, but I chose not to. The only limitation is that the consumer-grade configuration allows maximum 12 (or 13?) devices in the mesh, including sensors and interfaces and control panels etc.; if you want more, you need to get in touch with them for instructions.

The interface acts as a simple switch with both normally open and normally closed positions. From there you can hook it up to OpenHAB through any means you like - perhaps one of the GPIO pins on a Raspberry Pi. Mine is connected to a KNX interface, so that the smoke sensors automatically trigger the fire alarm over KNX, raising all blinds and turning on all lights in the stairwell; OpenHAB is only indirectly notified through the KNX interface, and is not involved in controlling anything.

Costs: each smoke detector including the separate radio module was €38,81, and the interface was €84,95, all including VAT and free shipping. Ordered from elv.de in January 2019. The smoke detectors without radio module are €18,95 each, for when I need to replace them in 6 years. Right now I can no longer find this model (with R at the end, including the battery-free radio module), and the separate radio modules with built-in battery are like €40 each.

1 Like

Thanks! Very valid thoughts, and generally the problem of every security-critical device being connected via a shared medium (like 868 MHz).

I’m not sure on the Nest smoke detectors (–> whether they require WiFi to perform a group alarm), but the HmIP-SWSD’s don’t appear to require the CCU / AP to be doing a group alarm (i.e. in case of a power outage of the CCU: I just did a quick test shutting down my CCU and testing the group alarm, which still worked perfectly well), so they appear to be “talking” to one another directly without the CCU.

Which leaves the “duty cycle limit reached”-problem as the main risk.

I’m not saying that this scenario can never happen, but at least over the past couple of weeks I’ve been seeing duty cycles of constantly < 25%.


So yes, this scenario could happen. Though, if this “worst case”-scenario would happen, the individual smoke detector would still go off, just the group alarm won’t work.

The Nest Protect uses Weave for interconnectivity. Google discusses it in detail here, probably because it’s reasonable for people to assume that they require an active network connection.

could that be used to read out status from Nest Protect Smoke Sensors ?

Not that I’m aware of. Google hasn’t made anything available in the Nest API, and I’m inclined to think that’s deliberate to prevent people from messing around with them.

Thanks! This is a good start, though I believe some crucial infos are missing to work with the HmIP-SWSD and openHAB?

I have to admit I do not yet fully understand eQ-3’s documentation style. While the document HomeMatic-Script DokumentationTeil 4: Datenpunkte does only offer very limited information (appears to be clearly outdated), the Homematic IP Devices Technical Documentation offers quite a lot (but still not all relevant) information?

Just two examples on why the documents appear incomplete:


Why do all smoke detectors show 192 as the result? What’s the UoM? Why isn’t it counting up? No infos available…


How do those two variables relate to one another (they appear to be connected?) How come the parameter is an integer, while the values are strings? Which number relates to which string?

Or am I missing a point here or too stupid to interpret the documentation?

I assume because it is a battery driven device and only connects once a day (I think) to the CCU.

They don“t. The first one is a status and the second one is a command

what do you mean with that? Do you see already the things and channels in openhab?

Thanks a lot for your response.

I managed to get things running pretty well by now and wrote down what I did, in case someone wants to do the same: Integrating the Homematic smoke detector (HmIP-SWSD) into openHAB - Tutorial & Channel documentation

There are a couple of remaining aspects which I do not yet fully understand about the channels of the smoke detector (see bottom of my post, especially around “COMMUNICATION_TEST_REPEATED” and “RESERVED_ALARM_OFF”). So if anyone has an idea, let me know. I’ll then update my post accordingly.

I going slightly off-topic here but I think you raise an important point. Just because openHAB can do something doesn’t mean it should. For something like smoke detectors, I definitely wouldn’t want to roll my own either.

I’m going to be doing a custom exhaust for our bathrooms and while managing that via rules in OH is one way to to do it, I would rather just predefine the thresholds and hardcode those into the esp8266s used to switch the fan on and off and then relay this information back to OH. This allows me to do something fancier with the information, but the fans themselves will (should?) just work.

Valid points, and also the reason why I still keep a separate / dedicated CCU2 unit to control heating and rollershutter.

Just last week I did a change to my openHAB and my entire openHAB container kept crashing daily. Having my crucial systems (especially heating) running separately (during winter) helped me keeping a low pulse and taking the time it needed to get things running properly again.

Coming back to the smoke detectors: I believe reading out their status via openHAB seems fine. Assuming the worst case kicks in (openHAB doesn’t behave properly in case they go off, talking to themselves via the CCU), I’ll just lose a functionality (App-notification) which I wouldn’t have had in the first place without openHAB.