Thank you very much for taking the time to write such detailed feedback. This is exactly the kind of discussion we hoped to have with experienced Home Assistant users.
We also believe Matter + Thread is an important direction for the smart home. The ability to mix products from different manufacturers and ecosystems, while keeping things local and avoiding unnecessary vendor lock-in, is one of the main reasons we are investing more in Matter products.
Regarding the 4-in-1 Door & Window Sensor, we agree that a temperature sensor mounted directly on an exterior window frame should not be considered a replacement for a properly positioned room temperature sensor.
At the same time, contact sensors are not necessarily used only on exterior doors and windows. People also use them on interior doors, cabinets, storage areas, equipment covers, garages, refrigerators, and many other places. Adding temperature and humidity gives users some additional possibilities without requiring another separate device.
Your condensation example is actually a very good one. Even if the temperature reading is affected by the window location, combining it with humidity and other room data can still provide useful information for dew-point or condensation-related automations. We see T&H more as supplementary information rather than the primary purpose of the device.
For the smoke and CO alarms, we completely agree with your most important point: reliability comes first .
These are safety products, so certification, predictable behavior, independent alarm operation, and reliable communication are much more important than simply adding more smart-home features.
Remote silence, self-test, alarm status, battery information, temperature, CO concentration, and siren-related functions are all functions that we want to expose as openly as possible instead of hiding everything behind our own app.
Your diagnostic suggestions are also very valuable:
- Last self-test timestamp
- Self-test result
- Device health status
- Fault history
For safety products, we agree that visibility into the device state is especially important.
Regarding the first-triggered alarm function, you make a good point. In Home Assistant, Areas, notifications, and event history already provide a lot of information. Storing the first-triggered device as persistent diagnostic information after an interconnected alarm event may be more useful than simply exposing another temporary state. We will think more about how this can best complement Home Assistant rather than duplicate information that is already available.
For CO concentration reporting, there is always a balance between reporting frequency, radio activity, and battery life. Configurable reporting behavior is definitely something worth considering, especially for advanced users who may prefer different trade-offs.
On the power side, we also agree that a safety alarm should never become dependent on household mains power alone. Battery-powered alarms have the important advantage of continuing to operate during a power failure. If we develop wired versions, backup power and independent alarm operation will remain important design considerations.
OTA is another area we care a lot about. We want users to have a practical way to maintain firmware over the lifetime of the product, and being able to deliver firmware updates through standard ecosystems such as Home Assistant is exactly the kind of experience we would like to provide.
We also strongly agree with your point that Matter should not become:
“basic functionality through Matter, advanced functionality only through the manufacturer’s own app.”
There will always be some limitations depending on what a Matter device type or platform currently supports, but where it is technically possible, we want useful functionality and diagnostics to be available through standard platforms such as Home Assistant, with local operation rather than unnecessary cloud dependencies.
Regarding the Matter Bridge, your assessment is very close to ours.
Supporting Zigbee or Sub-GHz products from many manufacturers is much more complicated than simply translating one protocol into another. Proprietary clusters, manufacturer-specific commands, unusual parameters, and different device behaviors can all create compatibility challenges.
For advanced Home Assistant users, the value may indeed be smaller because HA already does an excellent job of bringing multiple ecosystems together. We see a potentially larger use case for people who have existing Zigbee or Sub-GHz devices but want to bring them into Apple Home, Google Home, or other Matter ecosystems without replacing everything.
