IAS Converter zone status - should attribute reporting be disabled?

[sesuncedu]

I don't think the IAS Zone converter should enable reporting on ZoneStatus attribute in ZigBeeConverterIas. The cluster generates the status changed command, and the converter handles it.

If the device supports reporting on the zone status attribute (its not marked reporting required), the update may be processed twice.

There's some other issues with how IAS Zone Status is handled - lots of channels handling there own bits, with each channel redundantly setting and resetting timeouts redundantly, as if the data had come in multiple messages. I believe this behavior is safe in all but the most perverse cases ( at worst, any timeout that fires will necessarily occur a linger time after the received message than would have happened had the timeout been set at the appropriate time.) it is still a bit messy.

[cdjackson]

You may be right for whatever device you are using (please provide this information) however if I think back a couple of years I believe the reason this was implemented is some devices send reports, some send the commands, and some do both. Since I don’t think there was a reliable way in all cases to confirm this for all devices, we implement both and I would not like to change this as it will likely break someone’s system. If the double reports is a major problem we could look at adding a flag to ignore one of them (ie only use the first received method).

…

Sent from my iPhone

On 13 Sep 2019, at 05:16, Simon Spero ***@***.***> wrote: I don't think the IAS Zone converter should enable reporting on ZoneStatus attribute in ZigBeeConverterIas. The cluster generates the status changed command, and the converter handles it. If the device supports reporting on the zone status attribute (its not marked reporting required), the update may be processed twice. There's some other issues with how IAS Zone Status is handled - lots of channels handling there own bits, with each channel redundantly setting and resetting timeouts redundantly, as if the data had come in multiple messages. I believe this behavior is safe in all but the most perverse cases ( at worst, any timeout that fires will necessarily occur a linger time after the received message than would have happened had the timeout been set at the appropriate time.) it is still a bit messy. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[sesuncedu]

This is the Samjin motion / (smartthings 2018).

ZCL table 8-10 (generated commands for IAS Zone server cluster) specifies that Zone Status Change Notification is Mandatory, so attempting to enable reporting on the attribute would seem to be a fix for some non-compliant devices.

If the endpoint supports discover command generated then that would work.

[sesuncedu]

[I am about to go poke the IAS Zone code to add a layer of separation between the channels and the attribute / cluster, since at the moment each converter for the zone status is acting completely independently (duplicated initialization traffic, and more importantly, sending multiple default responses to a single incoming message). This issue makes the problem twice as bad...]

I now have some speculative thoughts about why the IAS specific notification might not have worked in some past cases. If the IAS Zone enrollment doesn't complete, then the ias notification won't be sent.

Conversely , if we have successfully enrolled the device and made ourself the CIE, we will get IAS notifications for even the most broken certified device, because that's actually covered by the test.

Attribute reporting might be enabled if zone enrollment is not known to have succeeded, or if the cie_addr isn't us, and can't be set to us.

If it's activated, attribute reporting can be disabled upon successful receipt of a ias notification. This at least limits the number of duplicate notifications. It might even be possible to not pass along the second notification if it arrives in a short window and has the same value.

[sesuncedu]

Note: this issue is easiest to address after the change to have each zone status changes are handled a single time.

[cdjackson]

Thanks for looking at this. Can I also ask if we can try and close out some of the PRs that you've opened in the ZSS code so I can look at doing an update for 2.5 in the next couple of days. I fear we are opening lots of issues, but not closing them and we are getting more and more code conflicts.