Smoke Sensor Heiman HS1SA Zigbee Control/Configuration settings

[yousuf]

I bought Smart Mini Smoke Sensor Heiman HS1SA for testing with Home Assistant before apply the same for all rooms.

http://www.heimantech.com/product/index.php?type=detail&id=3

This product has smoke detector and Siren together.
I have integrate it with ZHA and it is connected fine

There is a control entity which I assume when enabled it will turn ON the siren. but it is not working i am not sure why.

also there are few configuration parameters’ which can be set through ZHA but they are not making any difference when I change them. they seems to working between ZHA and the device

I have tried to make a test smoke, the siren start the sound. also I get notification “Detected” on the entity. but I tried to mute the sound through the configuration option and it is not working.

anyone have idea why the configuration options and control entities not working between ZHA and the device.

[Hedda]

If a device does not follow Zigbee specs then need a “quirk” in ZHA Device Handlers (a.k.a. zha-quirks):

https://www.home-assistant.io/integrations/zha#zha-exception-and-deviation-handling

If there is not already an existing request for it then submit a new “Device support request” for it here:

https://github.com/zigpy/zha-device-handlers/issues

Be sure to fill provide all the information requested as well as additional info or links about the device.

https://github.com/zigpy/zha-device-handlers

[yousuf]

Thanks for reply
Does ZHA support sending “set commands” to the device using zigbee protocol?

How about zigbee2mqtt ?

[Hedda]

@yousuf

Does ZHA support sending “set commands” to the device using zigbee protocol?

By default the ZHA integration currently really just exposes device configuration attributes, however the developers are usually open to constructive suggestions and requests, see example discussion here:

https://github.com/zigpy/zigpy/discussions/934

Framework for generic exposure of device configuration attributes ·...

For using advanced Zigbee command you can utilize “ZHA Toolkit” (Zigbee Home Assistant Toolkit):

https://github.com/mdeweerd/zha-toolkit

ZHA Toolkit by @le_top provide both low-evel and high-level Zigbee commands through ZHA via zigpy:

https://community.home-assistant.io/t/zha-toolkit-toolkit-providing-low-and-high-level-zigbee-commands-through-zha-zigpy/373346

"zha-toolkit" - Toolkit providing low and high level Zigbee commands through ZHA/zigpy

zha_toolkit is a “Toolkit” to help do some “low level” Zigbee stuff that’s usefull to “fix” things, but also for daily use (for example: read a value from a Zigbee object and store it to a state). A presumed popular feature is that it provides “online” backups of the Coordinator hardware (which has been validated for the ZNP radios (TI based key) but awaiting confirmation for bellows). It’s more technical than most integrations. You can check the bindings a device has and remove all of these …

Again, still need ZHA to have ZHA Device Handler for the device in ZHA Device Handlers (zha-quirks):

https://github.com/zigpy/zha-device-handlers

GitHub - zigpy/zha-device-handlers: ZHA device handlers bridge the...

[Hedda]

@Hedda

ZHA Toolkit by @le_top provide both low-evel and high-level Zigbee commands through ZHA via zigpy:

"zha-toolkit" - Toolkit providing low and high level Zigbee commands through ZHA/zigpy

FYI, he posted this relative information in another thread:

https://community.home-assistant.io/t/help-understanding-zha-quirks/411253/15

@le_top

I haven’t read all the above in detail, but here are my two cents.

I would split up Zigbee compatibility in two main groups: “zigbee management” (“low level”) and Zigbee clusters (+profiles, etc).

Low Level

• Devices that pass certification are not necessarily compliant because the certification is limited to certain types of tests;
• The Zigbee stacks from the manufacturers are not tested a lot for interoperability. Some stacks seem to be more permissive than others or cope better with deviations. (To compare with bluetooth: theu have “UnPlugFests” aimed at testing interoperability.
• Low Level interoperability tends to improve - IMHO because zigbee is actually used.
• Low Level interoperability is determined essentially by the stack from the IC manufacturer, and in part by how good it is configured by the developer.

Zigbee Clusters

• Interoperability may be limited because the manufacturer wishes a closed system, but in my experience it is more that they are more than happy when it works with their system and do not want to spend more on making sure it works elsewhere.
  Another reason is that developers do not understand the zigbee specification, are resistant to changing an existing implementation (admitting they are wrong, spend more time than planned, …). I remember though discussions with pairs.
  • One was about a timestamp. The zigbee specification “clearly” says the reference (epoch) is 1/1/2000 but the implementation uses the more classic 1/1/1970. So all dates are by about 30 year wrong. It is still so in the end product for the following reasons forwarded by the subcontractor: this feature was not requested by the customer and they do not agree with my interpretation of the specification.
  • Too many developers tend to implement features in custom clusters or attributes even though the equivalent feature exists in the standard Zigbee Cluster Library specification.
  • Testing is mainly done against the internal coordinator or a single selected coordinator (cost reasons related to time) and improved only when there is a market need (a customer using another coordinator wants to integrate your end device).
  • The market is driven by (B2B agreements of) selling systems, not by B2C sales of end devices.
  • Some companies will deviate from the specification improving the user experience with their coordinator by fixing certain values in the end devices. In one instance I found that an end device can only report to endpoint 1. And I still believe this is more a choice of the developer than a choice of the company.

[oneiropagides (Nik)]

Hi Yousuf, did you find any solution to this?
I have exactly the same. The warning device does nothing really, just ornamental.

[le_top]

You apparently found the automatically closed github topic for the HS1AS-E https://github.com/zigpy/zha-device-handlers/issues/518 .

I can see that in principle the smoke detection is functionally present, but at the same time it is not reported to be functional.

This may be because (re)configuration is not successful for the device which is often because the device is sleepy. I do not know if pushing the button makes the detector wake up and communicate, but if it does, it is usefull to repeatedly push it during the (re)configuration process.

The configuration process is important to tell the device that it should report states to the coordinator (home assistant) which is what the bindings are for.

There are other ways to setup and check the bindings (zha-toolkit/bind_ieee, (zha-toolkit/binds_get)[https://github.com/zigpy/zha-device-handlers/issues/518#issuecomment-872616884] but that is more involved. You could at least check the bindings are there using binds_get.

Further, the alert state is often temporary: the device will report smoke detection and just after that notify the the alert is cleared. So you may just see the state change for a short time which means that the logbook may be more readable than the history (graph).

[oneiropagides (Nik)]

Thanks you @le_top. Do you know what the state of the “ias_WD” should be?
Am I supposed to turn this ON or OFF? It doesn’t do anything when I turn it on but does it mean that the alarm will not sound or not be transmitted to home assistant if there is a fire? There doesn’t seem to be any any info on this. Thank you!

[le_top]

IMHO the control is only there so that you can clear the alarm.

Ideally the detector would position the alarm and leave it active until cleared. There is the “clear” button and I guess that switching it off does the same.

When you trigger the alarm, does it notify HA now?

[oneiropagides (Nik)]

I have not managed to trigger an actual alarm yet.
When I press the big test button on the right of the device, the device does sound the alarm but home assistant does not show this in any way. The smoke sensor itself in the device in home assistant remains in “clear”, never changes state. But I am not sure if it’s supposed to change stage. I guess, I would have to test this with real smoke?

[le_top]

Normally the test button triggers the alarm, but it then also disappears in my experience.

I would check the bindings as indicated.

[oneiropagides (Nik)]

Yes! It works now.
I had to delete the device and pair it again. Now the test button does trigger the smoke sensor in home assistant and it works fine! Notifications work too! Thanks for the help!

[eskillx (Eskil Holum)]

Hi, just wanted to second this, it suddenly started working after deleting and repairing it several times!

[Varac]

@oneiropagides @eskillx That’s good to know, since I’m considering buying one as well.
Could you please summarize how you got it working ? Any changes to home-assistant / zha needed ?

[PepijnNiekel]

@oneiropagides @eskillx Same question as Varac from me. Did you have to do any other changes? I deleted and repaired my devices a couple of times but no difference. Still no notifications.

[tbarbette (Tom Barbette)]

I also bought this device but the button does nothing. Actually the interview process does not seem to finish, I have to repair the device but it gets to “Unavailable” after 6 hours. Any idea?

[At3]

The interview not completing is something I had in the past. What I did was reset the device. Start the interview and press the reset button with a paperclip every 2 seconds. After a minute or so the interview completed successfully. Note this was on z2m but recon it could work the same on zha.

[ferfr01 (fernando franco)]

@yousuf

evice.

where you able to make it work?? please tell me how!