I’m currently working on a new smart smoke alarm design and would love to get some feedback from the community.
The architecture is a hybrid approach:
RF interconnect (sub-GHz) is used for local alarm interconnection
Matter is used for smart home reporting and visibility
We intentionally didn’t use Matter for the interconnect layer. This product is an incremental upgrade of an existing RF-interlinked platform, and we want the safety interconnect to remain simple and independent from the IP network.
Another reason is UX: the RF interconnect mainly turns other alarms into additional sounders, but we don’t want the smart home UI to suddenly show multiple identical smoke alerts, which could make it harder to identify which room actually detected smoke first.
Remote test behavior
For remote tests triggered via Matter, our current idea is:
Remote test should not trigger RF interconnect
Only the target device should sound the test alarm
This keeps testing from triggering whole-home alarms.
Hi Isabel,
You may wish to canvass other more appropriate forums more focused on product design, and the Matter con$ortium for design guidelines for full compliance.
From experience, anything relying on RF transmission for mission critical things like fire detection and warnings is prone to reliability issues, and your product liability exposure should be very carefully considered should you omit hard wired options. Consult your lawyers first before embarking on a design brainstorming session, or prototyping down the wrong rabbit hole.
RF interconnection is quite common and often necessary to get interconnection when post-installing smoke alarms.
Regarding your Matter features, then some of the features I would like would be
battery state
siren test, make different siren sounds, so it can be used as a general siren too
interconnection test
smoke alert indicator (for the one that detects smoke)
silence command for smoke alarm
silence command for low battery warning, if it is audible, maybe even custom times, so you can set it to be silent through the night and take care of it the next day. If it can not be silenced the entire night, then the user will just be annoyed and remove the battery, so no difference in protection, but an annoyance on extra
if the device have leds, then options to control those leds, at least for finding a specific device
Thank you for the suggestion! Regarding the certification and compliance aspects of the new product, I will share your feedback with our management team. They will involve more specialized colleagues to review these considerations carefully.
Thanks for the suggestions. This is very useful feedback.
At the moment, our device already supports several of the capabilities you mentioned:
Battery state reporting
Siren test, which can be triggered either remotely via Matter or locally via the physical test button
Smoke alarm indication, where the device LED flashes red rapidly when smoke is detected
Smoke alarm silence, which can be triggered via the physical button on the device
Low-battery warning indication, including ecosystem notifications and a slow red LED flash on the device
Our device does implement the Matter Identify function. For example, in the Apple ecosystem there is an “Identify” button in the device settings, and when it is triggered the device LED will flash green to help locate the device. I’m not sure if this is the type of LED control you were referring to.
For the siren behavior, that’s an interesting suggestion. We’re curious about the use case you have in mind for having a different alarm sound on the interconnected devices. In our current design, the smoke alarm only uses a single alarm sound pattern, so all interconnected units would emit the same alarm sound. It would be helpful to understand what scenario you’re thinking of for differentiating the sound.
I would also appreciate some clarification regarding the “interconnection test” you mentioned.
Are you referring to testing the RF interconnect behavior between alarms (i.e., verifying that other alarms respond when one device triggers), or something else?
Thanks again for sharing your ideas — it’s very helpful while we’re refining the design.
If it can be done physically, then why not also remotely with Matter?
That was one, but also other states for the leds. Obviously some are "reserved for things like locate, alarm, low battery and so on, but there might be combinations that are unused for the moment.
These can be used controlled, so if you can sound the alarm as a sirene, then you can use it as a security device too and a red led might indicate fire and you need to leave the house, while a green led could mean a security breach and you should instead check doors and windows.
In a smart home there are many extra sensors that could be triggering an alarm and not having the ability to reuse the smoke alarm as a sirene could be used for security breaches, water leaks, fall detectors and so on with each its own sound and maybe also a led indication to categorize the event.
I think all smart home owners have experienced devices that have dropped their connections to other devices and therefore an interconnection test is a safety measurement here and also to ease the worry of such cases.
We intentionally limited the smoke alarm silence function to the physical button on the device, since smoke alarms are life-safety devices and we want the user to verify the situation locally before silencing the alarm.
We understand the intention behind your suggestion regarding remote silencing. We’ve shared this feedback internally, and the project team will discuss carefully whether adding this capability would make sense for the product.
Just to clarify your idea — are you suggesting that events from other sensors (for example, a water leak detector) could trigger different sound patterns on the smoke alarm to represent different types of alerts?
Regarding the interconnection test, we’d like to better understand the exact scenario you have in mind.
Are you referring to a function where pressing the test button on one alarm would trigger a test on all interconnected alarms, so the whole system can be verified at once?
Or are you more concerned about detecting when a device drops offline, and having the ecosystem (for example Home Assistant) generate a notification when that happens?
In our current design, devices can already be triggered remotely for a test, and if a device loses connection the ecosystem will also generate an offline notification. We’d be very interested to hear which of these scenarios you are primarily referring to.
A remote button does not really garantee that and most use a would do it regardless of how they can silence the alarm. Many users of smart homes would probably be annoyed by this stance of knowing-better.
Yes.
Many users need the site anyway, so a smoke alarm with the ability to use it as a general siren would be a huge benefit and make the smoke alarm more cost-effective.
Manual tests are fine, but users of smart homes want to run automations, and having a sensor of the amount of interconnected devices would be a great sensor to keep an eye on the smoke alarm network.
Your offline notification might be enough already if it can be integrated into the smart home ecosystem.