Develco SMSZB-120 - Cannot clear alarm bit when the smoke detector has fired off

[MoonguardGITHUB]

Describe the question or issue you are having

Screenshots

Environment

• Host system: (PC)
• Running method: (Windows)
• Firmware version: (264a0700)
• deCONZ version: (2.05.81)
• Device: ConBee II)
• Do you use an USB extension cable: (yes) -- only relevant for ConBee I/II

deCONZ Logs

Additional context

When the smoke detector fires off an actual alarm, I cannot find a way to reset the alarm bit except removing the battery. Executing "Initiate Normal Operation Mode" gives "UNSUP_CLUSTER_COMMAND". In normal operation the Zone Status value is 0x0030, when a fire is reported it changes to 0x0031. Found this on the technical documentation:

Bit0: Alarm
Note: How to clear a alarm in the “Zone status”
The sensor 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.

[SwoopX]

Hm, I had an alarm like 1 month ago but I cannot recall that the bis was not cleared. I assume you had an alarm recently as well? What did you do to cease the alarm?

[MoonguardGITHUB]

I clicked the button on the smoke alarm to stop the siren. I tried short press and long press but the alarm bit remained. I tested this several times and each time the bit alarm remained. Only thing that worked was removing the battery and inserting it again. I found this thread while searching for this problem: https://forums.homeseer.com/forum/lighting-primary-technology-plug-ins/lighting-primary-technology-discussion/jowihue-w-vuyk/1377825-smoke-detectors-not-reporting-alarms

Last post also mentions the alarm bit not clearing. I'm not sure if it's the same issue.

[SwoopX]

Hm, hope that I don't forget this again. Looks like we should send a default response to the heat and smoke alarm then, when you set the alert value to none via REST API to make sure the bit is cleared if set...

[MoonguardGITHUB]

Great. If there is anything I can do to help testing just let me know.

[SwoopX]

Alright, I guess this could be something workable now here

However, what I do not know is if I chose the right command to respond (assumption is zone change notification) and if that needs to be profile wide or cluster specific (assumption here is profile wide would work).

It feels a bit like a dirty hack but on the other side, I currently do not see a more elegant way to realize that without fiddling too much around. The default response will be send every time when the alert parameter of the light resource is set to none. To actually test this, you'd need to compile the REST API plugin under Linux, preferably on a Respberry Pi...

@ebaauw maybe you wanna chime in for a test?

[ebaauw]

The default response will be send every time when the alert parameter of the light resource is set to none.

Not sure if that will work. I think the default response should be issued as a response to the Zone State Notification, i.e with matching sequence number. The Default Response itself is profile wide, the Zone State Notification is cluster specific; I’m not sure how to indicate that in the response.

I would think that the API plugin already sends a default response, unless Disable Default Response has been set. Did you rule out routing issues causing the response not to reach the detector?

[MoonguardGITHUB]

Hello.

I did a new test this morning. I had the smoke detector next to the conbee II to make sure the signal was good. Fire warning came as soon as the siren started. I issued an alert:none command to the smoke detector, but the sensor still had the fire alarm bit.

Unfortunately I don't have access to Linux or a Pi atm. I also looked at the Windows build of the Deconz and it didn't look very easy to build from scratch, maybe that's why there is no guide for that. I have access to Visual studio, but not sure which files to attach to build...

[SwoopX]

I issued an alert:none command to the smoke detector, but the sensor still had the fire alarm bit.

Sure, because nothing is supposed to happen in that direction without my changes.

This has the potential to go really fugly... @ebaauw good point with the sequence number. If that would really matter, we'd need to catch and retain it for clearance.

The Default Response itself is profile wide, the Zone State Notification is cluster specific; I’m not sure how to indicate that in the response.

I'd expect to set the corresponding bit here to be sufficient. However, not sure if that's required as I wrote.

I would think that the API plugin already sends a default response, unless Disable Default Response has been set.

No, it doesn't in this case. Default response only kicks in for attribute reporting command, but here we have Zone State Notification being cluster specific on top. Even if that would be extended, I'd expect the following: Alarm goes off and Zone State Notification with alert bit set is send, requesting a default response. This would automatically and directly fire back, clearing the bit while the alarm should still remain. So bottom line, maybe 1 sec alert condition. In the end, we want to have manual control over it.

[ebaauw]

No, it doesn't in this case.

Apparently not, confirmed by sniffing. I don't know how to trigger an actual alarm, but when the SMSZB-120 sends a supervision (periodic) Zone Status Change Notification, the Disable Default Response bit has been cleared. deCONZ answers with an ACK, but no default response.

I'd expect the following: Alarm goes off and Zone State Notification with alert bit set is send, requesting a default response. This would automatically and directly fire back, clearing the bit while the alarm should still remain. So bottom line, maybe 1 sec alert condition. In the end, we want to have manual control over it.

What do you base this expectation on? Afaik, a Default Response should come right after the command that triggers it. If I read the manual correctly, the detector will only clear the alarm bit and send a restore Zone Status Change Notification, when the alarm condition no longer occurs.

[SwoopX]

Hm, what would clear the actual alarm situation then? A button press?

[ebaauw]

I understand that only shuts up the siren. When I press the button, the siren sounds and the lights flash, but no Zone Status Change Notification. It would seem to be “detached” from the Zigbee stack.

I suppose the next supervision report is supposed to be answered with a default response, so the bit would be cleared some time after the alarm condition has been resolved.

[SwoopX]

So I suppose that would mean: you get the alarm condition, requesting a default response - default response is send - next zone status report clears the bit (worst case after 15 mins)...?

[MoonguardGITHUB]

Hello. I tested the 2.05.84 version and sending alert: none did not clear the alarm bit with the fix @SwoopX . However I did notice that the fire state went away without me doing anything previously. So I tried leaving the fire state on since 14.10 and checked the state each day. Today 24.10 the fire state was false. Maybe the fire alarm reset itself after x days when No default response is sent?