Zigbee Receive Report Attribute from multi-endpoint

Hi community,
I am new to Smartthings and now I’m trying to write Device Type Handler for my Zigbee Switch Devices. Here is my switches http://www.lumi.com.vn/Elite-Version-pd-4. In each physical switch plate, they have from 1-4 buttons to control on/off device. They have multi endpoint, each one associate with one button. I have write my Device Type Handler for them and Smartthings now can regconize and control them.
My problem is when those swiches send Report Attribute to Smartthings, as I debug on IDE, the description received in parse function is just ‘on/off: 0’ or ‘on/off: 1’. There is no additional information like the source end point, so I can not decide where this Report come from and update status of right button. So anyone know how to overcome this problem?

I have seen a similar problem with the ZigBee Temperature reporting. I have a device that reports its temperature on two unique end points but only one makes it through. See this Post ZigBee Temperature reporting question for Cluster 0x402. I never got a solution as the tread was hijacked by a SmartThings engineer that was off on a tangent about my bind command. I finally just had to drop it. I think SmartThings is “preparsing” some ZigBee reports and stripping out the end points.

I was able to work around my multiple temperature probes problem by querying each probes end point. Here are my two read attribute commands I send to cluster 0x0402 for end points 0x39 and 0x40:

cmd << "st rattr 0x${device.deviceNetworkId} 0x39 0x0402 0x0000"    // Read probe 1 Temperature 
cmd << "delay 150"       

cmd << "st rattr 0x${device.deviceNetworkId} 0x40 0x0402 0x0000"    // Read probe 2 Temperature        


I know for a light switch your going to want the device to send you a report when someone pushes the button. Waiting for a poll cycle to come around and detect that button has been pushed is not a good solution! This work around probably wont work for you but you can at-least see the state of each of your 4 buttons since you can send the read attribute to each end point.

To me this is a big problem and it has to be fixed by SmartThings since they parse it before we get it as a catchall message. Maybe now that someone else is seeing a similar problem we can get a fresh pair of eyes to take a look.

1 Like

Thank John.
I also did work around similar to you. The different is I don’t send poll attribute at all. Instead I just always send read attribute response message to hub everytime I change the switches state (Yes, this is from the device-side. It’s my product and I can change how it work) . This way, the state of my device always up to date. And that work perfectly for me.
But I don’t think that is the offical way to solve this problem, just a trick. I need the offical support for this type of problem from Smartthings. Hope they will notice this thread and make some changes. So it will be easier for us developers to make our devices compatiable with Smartthings Hub in the future.

Excellent! Yep that would do it. Too bad you have to make your product “non standard” so it will work with SmartThings.

I don’t think anyone has officially reported this as a bug to SmartThings. Maybe @Tyler can assign this to someone qualified to work on it. I will be happy to work with a developer or engineer if they want to reproduce the problem. This is a big deal to me as it is a problem with their core API.

FYI: here is one of my recent hardware projects http://CoopBoss.com.