no it shouldn’t matter i used python ,c , and nodejs .
Hi @rclark31978; I too have this issue with 3-series centralite door sensor (ZigBee HA 1.2). I’m responding to the 0x0013 with 0x0005 but every 12 seconds the sensor leaves the network and rejoins with another 0x0013 message. Did you solve the issue? Is there a special message for the device that makes it stay joined?
Hi fatih, I am having the same problem, each time I receive the 0x0013 message I send the 0x0005 command, but I don’t receive the 0x8005 anwser and after 12 seconds the sensor leaves the network and rejoins. Did you find a solution?
Did you ever make it to the point where you were able to recieve data from the sensor?
I’m in an exact similar situation at the moment.
I got a bit further but could never make it work right so I pushed it aside. Haven’t worked on it since then.
Okay - which libraries or languages have you used?
Currently using the node.js library that is linked further up in the thread. The code executes, but never reaches my /dev/tty* port. So troubleshooting at the moment.
I was using Python with a zigbee library
I was searching for an issue I was running into and stumbled across this post. Figured I would add my experience. And then see if anyone has any suggestions.
I have been using the XBee S2C and the python XBee library. I have been attempting to pair a contact sensor from Iris by Lowes. From what I understand, it is made by CentraLite which is the same manufacturer of the SmartThings multipurpose sensor. And it is a ZigBee HA 1.2 compatible device.
Similar to the messages above, I power it up and receive the device announce message (0x0013). I respond with the active endpoint request… wait for the response and then send simple descriptor requests. I also receive a match descriptor request for the 0x500 cluster (Security IAS (Intruder Alarm Systems) Zone) and respond to that as well.
According to the ZCL spec (chapter 8)… devices in the security clusters have some additional enrollment steps. So following the spec… I go through the process of enrolling the device. This involves the following:
- Sending XBee 64bit long address via a write attribute command to set IAS CIE address (this is the address the security device will communicate with (and only this device until you reset the device using the reset button (because security)))
- Sending Zone Enroll Response message to the device (at which point the device should change its internal state to enrolled and send a response).
Then boom. it works. Move the magnet close, pull it away, whatever you want to do… it will send out a state message each time its state changes. The message will indicate if it is opened or closed. Yay!
Now the problem… similar to some of the messages above, it keeps sending device announce messages every ~7/8 seconds… even though it is enrolled and functioning properly. I probably wouldn’t care much… but since this is a battery powered device… I think this extra unnecessary message sending will kill the battery.
Was anyone able to successfully get the device announce messages to stop sending? Or have suggestions for other things to try?
-Tommy
Did you reply with a Default Response? That would probably stop it.
Alternatively when you send the zone enroll Response, set the default response bit in the frame control in the zcl frame.
Do you send Default Response messages to respond to Device Announce messages? The Device Announce message is part of the Zigbee Device Profile and is not part of the Zigbee Cluster Library (which is where the default response message is found).
That being said, it is possible I need to be responding to certain messages that notify me of successful enrollment or state changes from the IAS zone cluster. If I am not responding and should be, it is possible it attempts to reset the connection? I’ll give it a try.
You are quite correct, sorry I misread the detail of your question. I didn’t realise you stopped querying the end device straight after the Descriptor Response and Enrolment. Maybe it’s worth sending at least one Basic cluster attribute query so it knows you are interested in it’s configuration. It seems it is looking for something to take it out of binding. Just a guess. I’m not familiar with the device.
Delayed response. Busy past week.
Anyway… no luck with your latest suggestion. I successfully sent attribute queries for both the Basic cluster and the IAS Zone cluster.
I queried the Power Source attribute (0x0007) from the Basic cluster (0x0000) and it appropriately responded that it was Battery powered (0x03). And I queried the Zone Status attribute (0x0002) in the IAS Zone cluster (0x0500). It correctly responded with the state of the device (either open or closed based on where I had the magnet).
Unfortunately, it continues to send the Device Announce message (0x0013) every 12 seconds.
Any other ideas?
I also noticed there is a second Active Endpoint node which I have been ignoring because I don’t know anything about the profile. I have always been communicating with the ZigBee HA profile… since that seems to be doing what I expect. Here is the Simple Descriptor data for that extra endpoint:
Simple Descriptor:
\x02 - endpoint
\xdf\xc2 - profile 0xc2df
\x0c\x00 - device id
\x00 - device version/reserved
\x05 - number input clusters
\x00\x00 - Cluster 0000
\x01\x00 - Cluster 0001
\x03\x00 - Cluster 0003
\x05\x0b - Cluster 0b05
\x0f\xfc - Cluster fc0f
\x01 - number output clusters
\x03\x00
Actually looks a lot like the information shown for the example discovery of the SmartThings SmartSense Multisensor shown here:
http://docs.smartthings.com/en/latest/device-type-developers-guide/zigbee-primer.html
Maybe I need to respond to that endpoint in some manner as well. But I have no idea what that profile is.
Interesting. I’ve never seen that profile either.
It’s an odd issue. You would think that response to the main endpoint would be enough.
Keep us up to date with anything you do. Good learning for all.
Did u find a solution? I have the same problems, to connect my door sensor to my XBee. Every minute I get an “Explicit RX Indicator” error. Hope someone can help us with this problem 
Just updated the XBee Pro S2C firmware version and now everything works!
Hi,
I could write Xbee 64bit long address to IAS CIE using write attribute command. The frame I created is added below.
Explicit Addressing Command Frame (API 2)
7E 00 22 7D 31 01 28 6D 97 00 01 04 2B 7D 5D FF FE E8 01 05 00 01 04 00 20 00 01 02 10 00 F0 6B 7A 29 41 00 A2 7D 33 00 FD
Start delimiter: 7E
Length: 00 22 (34)
Frame type: 11 (Explicit Addressing Command Frame)
Frame ID: 01 (1)
64-bit dest. address: 28 6D 97 00 01 04 2B 7D
16-bit dest. address: FF FE
Source endpoint: E8
Dest. endpoint: 01
Cluster ID: 05 00
Profile ID: 01 04
Broadcast radius: 00 (0)
Transmit options: 20
RF data: 00 01 02 10 00 F0 6B 7A 29 41 00 A2 13 00
Checksum: FD
It’s Response data is
Explicit RX Indicator (API 2)
7E 00 16 91 28 6D 97 00 01 04 2B 7D 5D A3 87 01 E8 05 00 01 04 21 18 01 04 00 3A
Start delimiter: 7E
Length: 00 16 (22)
Frame type: 91 (Explicit RX Indicator)
64-bit source address: 28 6D 97 00 01 04 2B 7D
16-bit source address: A3 87
Source endpoint: 01
Destination endpoint: E8
Cluster ID: 05 00
Profile ID: 01 04
Receive options: 21
RF data: 18 01 04 00
Checksum: 3A
Now Zigbee button communicates with the Zigbee coordinator,
Data from zigbee button while press is added below,
Explicit RX Indicator (API 2)
7E 00 19 91 28 6D 97 00 01 04 2B 7D 5D A3 87 01 E8 05 00 01 04 01 09 08 01 00 80 41 12 92
Start delimiter: 7E
Length: 00 19 (25)
Frame type: 91 (Explicit RX Indicator)
64-bit source address: 28 6D 97 00 01 04 2B 7D
16-bit source address: A3 87
Source endpoint: 01
Destination endpoint: E8
Cluster ID: 05 00
Profile ID: 01 04
Receive options: 01
RF data: 09 08 01 00 80 41 12
Checksum: 92
why I am getting this frame?
What is the format of Zone Enroll Response?