Develco Siren SIRZB-110, ssIasZone alarm is not cleared #18096
Labels
problem
Something isn't working
Comments
|
Can you provide the herdsman debug log when the device send a zone status change notification? I expect that zigbee2mqtt already sends the default response. See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable the herdsman debug logging. Note that this is only logged to STDOUT and not to log files. |
|
Thanks for your help @Koenkk, it is much appreciated. I believe this is the log you requested : |
|
Based on the logs, it seems a default response is send: |
This above looks like the default response, yet the siren kept sending same status, as if the default response is not the one the siren expects. Nota: I could confirm that the same siren toggles the ac status on a proprietary gateway. |
|
@Koenkk I played with the various fields and managed to have the siren toggle by forcing the "options.direction" to Zcl.Direction.CLIENT_TO_SERVER ( = 0)
endpoint.ts :
Now, I am not sure if we should enforce that opposite direction for that SIRZB-110 model only or for that ssIasZone cluster. I am not sure either how to do it. |
Koenkk
added a commit
to Koenkk/zigbee-herdsman
that referenced
this issue
Jun 25, 2023
Koenkk
added a commit
to Koenkk/zigbee-herdsman
that referenced
this issue
Jun 25, 2023
|
Great investigation! I pushed a fix in Koenkk/zigbee-herdsman#726, let me know if it works. Changes will be available in the dev branch in a few hours from now. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html) |
Koenkk
added a commit
to Koenkk/zigbee-herdsman
that referenced
this issue
Jun 25, 2023
|
Fix looks and works fine, at least for the siren SIRZB-110 I will test other sensors I have tomorrow. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened?
Hi,
Information from the Ias Zone updates only once. After this update, the Ias Zone message is repeated and the fields do not toggle back again.
example: ac_status gets true when device is unplugged from power, and then multiple messages like this are sent even if the device is plugged back in
MQTT publish: topic 'zigbee2mqtt/0x0015bc004100XXXX', payload '{"ac_status":true,"battery":100,"battery_low":false,"elapsed":5012,"enrolled":true,"ias_alarm":false,"ias_cie_address":"0x00124b00257XXXX","linkquality":182,"max_duration":900,"restore_reports":true,"supervision_reports":true,"tamper":false,"test":false,"update":{"installed_version":131074,"latest_version":131073,"state":"available"},"voltage":3900,"zone_id":23}'The tamper bit has the same behaviour. Tamper will turn to true and then never toggle back to false.
This seems to be an issue with the default response :extract from the siren's technical manual https://www.develcoproducts.com/media/1999/sirzb-110-technical-manual-smart-siren.pdf
Note: How to clear a alarm in the “Zone status” The device requests ZCL Default Response on the Zone Status Change notification, if any new Alarm bit has been set. Until the IAS CIE has acknowledged the received alarm by sending the mandated Default Response, the Alarm bits are not cleared – even if there is no longer an alarm situation. When the Default Response is received, a new Zone Status Change notification is sent with the Alarm bits cleared, if the alarm situation has disappeared since sending the Zone Status message with alarm set.What did you expect to happen?
ac_status should toggle when plugged or unplugged
tamper should toggle to false when device is open or closed
How to reproduce it (minimal and precise)
(1) pair a SIREN SIRZB-110
(2) unplug it, check ac_status from log (true)
-> multiple identical messages while a single message is expected
(3) plug it back in to power, check ac_status from log (got true, expected false)
(4) open it, check tamper from log (true)
-> multiple identical messages while a single message is expected
(5) close it , check tamper from log (got true, expected false)
Zigbee2MQTT version
1.31.8
Adapter firmware version
20221226
Adapter
CC2652
Debug log
Info 2023-06-23 09:26:42MQTT publish: topic 'zigbee2mqtt/0x0015bc004100XXXX', payload '{"ac_status":true,"battery":100,"battery_low":false,"elapsed":180914,"enrolled":true,"ias_alarm":false,"ias_cie_address":"0x00124b002573XXXX","linkquality":167,"max_duration":900,"restore_reports":true,"supervision_reports":true,"tamper":false,"test":false,"update":{"installed_version":131074,"latest_version":131073,"state":"available"},"voltage":3900,"zone_id":23}' Info 2023-06-23 09:26:47MQTT publish: topic 'zigbee2mqtt/0x0015bc004100XXXX', payload '{"ac_status":true,"battery":100,"battery_low":false,"elapsed":4946,"enrolled":true,"ias_alarm":false,"ias_cie_address":"0x00124b002573XXXX","linkquality":171,"max_duration":900,"restore_reports":true,"supervision_reports":true,"tamper":false,"test":false,"update":{"installed_version":131074,"latest_version":131073,"state":"available"},"voltage":3900,"zone_id":23}' Info 2023-06-23 09:26:52MQTT publish: topic 'zigbee2mqtt/0x0015bc004100XXXX', payload '{"ac_status":true,"battery":100,"battery_low":false,"elapsed":5007,"enrolled":true,"ias_alarm":false,"ias_cie_address":"0x00124b002573XXXX","linkquality":171,"max_duration":900,"restore_reports":true,"supervision_reports":true,"tamper":false,"test":false,"update":{"installed_version":131074,"latest_version":131073,"state":"available"},"voltage":3900,"zone_id":23}' Info 2023-06-23 09:26:57MQTT publish: topic 'zigbee2mqtt/0x0015bc004100XXXX', payload '{"ac_status":true,"battery":100,"battery_low":false,"elapsed":4998,"enrolled":true,"ias_alarm":false,"ias_cie_address":"0x00124b002573XXXX","linkquality":171,"max_duration":900,"restore_reports":true,"supervision_reports":true,"tamper":false,"test":false,"update":{"installed_version":131074,"latest_version":131073,"state":"available"},"voltage":3900,"zone_id":23}'The text was updated successfully, but these errors were encountered: