Myself and two others are working on a research project using silabs EM3588 ZigBee SoCs as a custom coordinator. To reduce development time and build a prototype, we purchased several Smartthings Sensors (presence, open/close, water, and motion.)
Our coordinator implements a device database. As devices connect to the coordinator, the coordinator queries them for their endpoints and clusters and then stores the information on the chip. This feature has only worked with our coordinator one time. Every subsequent attempt to add these same sensors to the coordinator (after all being reset), the Smartthings Sensors report 0 endpoints to the coordinator.
I have found only one thread about this problem, and the OP was assisted by a SmartThings engineer who helped him solve his problem. His problem was that the endpoints on the sensors were asleep. Does resetting the devices not wake the endpoints for network joining? If we know what clusters the devices should have, should we just continue by hard coding that into our coordinator?
If I had to guess the device is sleeping and your ZDO request for it to report its endpoints is not being received. The parent of that device has to queue packets for it so when it wakes up to check for data it can respond. In your case I bet your hub is the parent and I wonder if the time out value for its children is to aggressive and dropping the sensor. Another thing that may be happening is only one packet is being queued by the parent. If your sending more than one packet before the device checks in and reads it, only the last packet will be accessible.
A possible way around the timing issue is to write your firmware to instantly respond to the device’s ZDO device announce (cluster 0x0013). So when the child device is powered on or first joins a ZigBee network it will send a ZDO device announce (cluster 0x0013) and stay awake for a second or so. Have your firmware listen for this packet and respond with a request for end points by sending a ZDO Active_EP_req (cluster 0x0005) and then follow up with ZDO Simple_Desc_req (cluster 0x0004) to each end point. That will get you around a possible time out condition.
If this does the trick you may want to increase your coordinator’s Cyclic Sleep Period I would bump it way up as I know (based on observation) the SmartThings coordinator has a very high setting. Once that is set correctly you should have better success in talking with a sensor.
Another trick is to activate the sensor and query it quickly. So if this is a contact sensor move the magnet away from the sensor and at the same time send it a packet. At that point the sensor’s ZigBee radio is awake and you wont have to worry about the queue being overrun with multiple packets.
I have a SmartThings ZigBee contact sensor sitting back on the bench is that one of the sensors you are using? If so I will set mine up and play along.