Binding is not appropriate smoke interconnection, except it supports group function, besides that, binding still require router as its parent.
Does the Heiman have the required binding cluster, and if not are there plans to implement it in future firmwares?
we will have it on the motion sensor and door sensor, currently, I think it may not proper to have it on smoke alarm, if you can share us the use cases, that would be wonderful for us.
If binding requires a router for anything other than setting the link up than the function is utterly useless. I use Z-wave associations to link buttons to lights. This works even if HA is down (albeit with a small delay because the controller does not respond). It allows all kinds of links, but the most simple form is on/off, which should work perfectly for the siren.
Many countries are increasingly pushing to make direct links between smoke alarms mandatory. So a smoke alarm that does not allow for it may find itself increasingly obsolete. Requiring HA to function for it defeats the purpose, because a fire caused by short circuit will probably have cut power to HA.
So yes, direct binding is definitely relevant for smoke alarms and any smoke alarm should be wise to include the functionality some way or another.
I don’t own it, but apparently the Aqara Zigbee detector supports wireless interconnection and also supports being commanded to mute. So this has been done before and is not impossible. Although of course Aqara uses Zigbee not thread, and it’s unclear to me whether the interconnect also requires a hub after being set up. Smoke Detector Specs - Aqara
I wonder if Aqara might use two different radios, one for Zigbee and one for the wireless interconnect? I don’t know, just a thought.
Concerning being hardwired, ideally it supports both. Many older homes including mine don’t have the wiring for hardwired alarms. So there’s no way I’m spending $1000 or more per alarm to get an electrician to make it hardwired. Of course if you do already have it hardwired, then you’d want a hardwired alarm to take advantage of that.
That said, imo the sealed 10-year battery makes a ton of sense too as it enforces people replacing their alarms per the fire department recommendations.
My preferred setup of a smoke alarm would be a standard smoke alarm with some RF interconnection and probably proprietary.
Then the fire alarms will have a connection to a Matter end device that can receive an one-way signal for siren activated and low battery and another one-way for mute, which is parallel with a physical button.
This setup makes the smoke alarm independent setup from Matter.
Matter is only used for detecting and controlling the normal external functions of a smoke alarm, ie. siren sound, low battery led and beep and mute button.
yeah, you are totally correct. when you bind button to the light, the light is acting as its parent, so that’s simple.
we have the subG solution that can be interconnected without parent or even coordinator, that protocol was digined by us, we can not do it in zigbee or matter because of its networking feature, except we change the mac layer of zigbee network, but that will bring the high risk to the system.
thanks, anyway, we can do it with zigbee, but we need to fully test it, our engineer is working on that, the first step we can simply expose the siren function on smoke alarm, so users can create linkage via automation or something. and then, we can try to optimize it in the future, users can update thier smoke via ota.
yeah, hardwired interconnection should be more stable, it’s hard to be installed, we should leave the option for user.
seems like we can use our matter bridge to map those subG device to matter, when the matter network breaks, those detectors still can work as expected.
I like the design where it sits over a lamp outlet and draws power from that, but still allow the lamp outlet to be used normally too.
I can twist the smoke alarm to disconnect it from the base and then slide it further up the lamp cord, if I need to change the backup battery.
When the smoke alarm is disconnecteded from the base, the base is still electrically safe, so no exposed high voltage/ high ampere parts exposed.
I’m sure Heiman already knows this, but eventually I would like to see Heiman work with the CSA and help all of these extra smoke and CO alarm signals to be a standardized part of Matter. I see Heiman is already a member of CSA so that’s awesome! Member Search - CSA-IOT
The only feature I can see an argument against is failsafe interconnect, as maybe Matter would have to define a special safety communication to enable that. Eg similar to how there are safety IP protocols that achieve the highest safety ratings SIL3 / PLe. For example PROFISAFE and also Safety over EtherCAT (FSoE).
The mounting holes aligned with the screw holes in the lamp outlet, so that was easy.
I can not see how drilling is different between the smoke alarms though.
The smoke alarms needs to b mounted somehow.
The difference is that the base is connected to the lamp outlet and the lamp is connected to the base.
Biggest issue was mainly to remember to slide the lamp wire through the smoke alarm before mounting the wire, but that is more an issue with my brain than the product.