The state of ZigBee with attribute reporting

Great stuff @rpress. I would also like to call to your attention and others who may be reading this tread that SmartThings intercepts some ZigBee attribute reports before they get handed to your parse method. For example I have a device that has two thermistors and reports temperature for each probe on two unique endpoints to the SmartThings hub. Well when I add the temperature capability to my device type the reports show up in my parse method with the source end points stripped out. I have no way of knowing what probe the report is for. Here is a thread where I discuss this ZigBee Temperature reporting question for Cluster 0x402. I never got an answer to my question as the SmartThings engineer who was trying to help me got hung up on the bind order of my endpoints. I find it very interesting that you have found several code samples with the binding orders reversed. There have been others who have seen this same thing with other capabilities.

Here is another case of this “source endpoint masking” for the Switch capability: Zigbee Receive Report Attribute from multi-endpoint

I don’t mean to hijack your thread I just want someone to address this issue and I’m just calling it out here as it is related to attribute reporting.

3 Likes