This is Leo from Shenzhen Heiman Technology Co., Ltd. we started a new team to focus on the experiences for DIY users, we’ve got a lot of feedback of adding more functions to our smoke alarm, like the mute alarm, remote test and interconnection, etc, and now, here we are …
we are going to start with our zigbee smoke alarm which model named HS1SA, if you guys love it, we will do these updates to more models of our smoke and CO sensors. including our matter smoke and co alarms, but now, we can only do that with Home assistant.
So here is the engineering sample that we have added to Zigbee2mqtt, if we can get your suggestion and proposal, that would be a great honor to us, we would appreciate your advice, we are all ears.
Great approach! It would be really useful if the smoke detector could also function as an alarm siren, so the alarm sound could be activated and deactivated via Zigbee. This would make it more versatile for home security and automation scenarios.
I have to admit that I don’t really understand the core of the question.
Many OH users (like me) are driving their zigbee devices through zigbee2mqtt. So we will benefit from the changes anyway, right?
Others are using the zigbee binding. For them it depends how precisely the firmware follows the zigbee standard. Aqara and xiaome for example are usually problematic.
Generally as @mpmario pointed out the feature to use the smoke detector as a siren would be great.
I had some smoke sensors from Heiman but they were very lazy in regularly reporting the status (8-10h) so I removed them.
Some of my current sensors expose the temperature too. That’s quite nice for controlling the heating to avoid additional dedicated sensors.
Thank you for commenting, yeah, we got a lot feedback regarding this, but the downside is it will consume more battery energy, we will try to make still work more than two years.
Thank you Larsen very much for sharing your thoughts, that’s helpful for us.
Many OH users (like me) are driving their zigbee devices through zigbee2mqtt. So we will benefit from the changes anyway, right?
Yeah, if we have supported it with Zigbee2mqtt, you should have the benefit from it, but we are trying to use standard command as much as possible, if it indeed doesn’t have a standards, we have to use customer cluster to achieve that.
I had some smoke sensors from Heiman but they were very lazy in regularly reporting the status (8-10h) so I removed them.
could you please explain which reporting has a long interval? to be honest, we customized a log firmware, if it report slowlly, the user may wants it has a longer battery life, however, some of them are configurable, if you still know about it, it can take look.
we didn’t find where we can support our customers before, we apologize, we should find somewhere we can support those who use our products as much as we can.
Some of my current sensors expose the temperature too. That’s quite nice for controlling the heating to avoid additional dedicated sensors.
thanks for sharing, did you mean it on smoke alarm? we have a similar product,too, but it still in internal testing, we will launch it next year.
For me (and probably others too) a battery powered zigbee device should send a signal at least every 3-4 hours so that you know it’s alive and connected. My old Heiman sensors often weren’t seen for 8-11 hours.
yes. If your smoke sensors contain a temperature sensor anyway it would be great to expose this value to the user.
For me (and probably others too) a battery powered zigbee device should send a signal at least every 3-4 hours so that you know it’s alive and connected. My old Heiman sensors often weren’t seen for 8-11 hours
the default reporting interval was 2 hours, do you still remember it’s model? did you add it to OP though Z2M?
