Home/Support/Support Forum/ZigBee HA End Device frequently joining & dropping from the coordinator

ZigBee HA End Device frequently joining & dropping from the coordinator

0 votes
Hello;

We have a 3-Series Door Sensor (https://www.centralite.com/products/door-sensor) which supports ZigBee Home Automation 1.2 and we want to get notified (ZigBee attribute reporting) when the sensors on/off status has changed.

We are using Digi XBee Pro S2C module as a ZigBee coordinator, we have configured it according to the Digi's knowledge base. We successfully communicate a ZigBee HA 1.2 siren from another vendor with the coordinator.

We initiate a scan process on the controller and remove the cover of the door sensor. We can see a blinking blue led and than it turns to green. However the sensor constantly disconnects and rejoin the zigbee network, and we can see that its network address (16 bit) changes every time it rejoins. This process repeats every 15 seconds.

There is also a screen recording that shows the issue.

https://www.dropbox.com/s/hmk9zajx712kbkm/ScreenCast_ZigBee_Discovery_Door_Sensor2.mp4.mp4?dl=0

Is this a normal case, or is there anything we should do in order to successfully join the zigbee network and start a communication?

--UPDATE:
The door sensor sent following messages (I extracted them via XCTU Terminal)

Door sensors UID is 00 0D 6F 00 04 05 82 48

I noticed that, 16 bit address changes on each message.

Explicit RX Indicator (API 1)

7E 00 1E 91 00 0D 6F 00 04 05 82 48 03 D6 00 00 00 13 00 00 02 C7 D6 03 48 82 05 04 00 6F 0D 00 80 C2

Start delimiter: 7E
Length: 00 1E (30)
Frame type: 91 (Explicit RX Indicator)
64-bit source address: 00 0D 6F 00 04 05 82 48
16-bit source address: 03 D6
Source endpoint: 00
Destination endpoint: 00
Cluster ID: 00 13
Profile ID: 00 00
Receive options: 02
RF data: C7 D6 03 48 82 05 04 00 6F 0D 00 80
Checksum: C2


Explicit RX Indicator (API 1)

7E 00 1E 91 00 0D 6F 00 04 05 82 48 1F 35 00 00 00 13 00 00 02 C8 35 1F 48 82 05 04 00 6F 0D 00 80 CB

Start delimiter: 7E
Length: 00 1E (30)
Frame type: 91 (Explicit RX Indicator)
64-bit source address: 00 0D 6F 00 04 05 82 48
16-bit source address: 1F 35
Source endpoint: 00
Destination endpoint: 00
Cluster ID: 00 13
Profile ID: 00 00
Receive options: 02
RF data: C8 35 1F 48 82 05 04 00 6F 0D 00 80
Checksum: CB


Explicit RX Indicator (API 1)

7E 00 1E 91 00 0D 6F 00 04 05 82 48 32 A3 00 00 00 13 00 00 02 C9 A3 32 48 82 05 04 00 6F 0D 00 80 C8

Start delimiter: 7E
Length: 00 1E (30)
Frame type: 91 (Explicit RX Indicator)
64-bit source address: 00 0D 6F 00 04 05 82 48
16-bit source address: 32 A3
Source endpoint: 00
Destination endpoint: 00
Cluster ID: 00 13
Profile ID: 00 00
Receive options: 02
RF data: C9 A3 32 48 82 05 04 00 6F 0D 00 80
Checksum: C8


Explicit RX Indicator (API 1)

7E 00 1E 91 00 0D 6F 00 04 05 82 48 3A 90 00 00 00 13 00 00 02 CA 90 3A 48 82 05 04 00 6F 0D 00 80 DD

Start delimiter: 7E
Length: 00 1E (30)
Frame type: 91 (Explicit RX Indicator)
64-bit source address: 00 0D 6F 00 04 05 82 48
16-bit source address: 3A 90
Source endpoint: 00
Destination endpoint: 00
Cluster ID: 00 13
Profile ID: 00 00
Receive options: 02
RF data: CA 90 3A 48 82 05 04 00 6F 0D 00 80
Checksum: DD

Explicit RX Indicator (API 1)

7E 00 1E 91 00 0D 6F 00 04 05 82 48 5C 30 00 00 00 13 00 00 02 CC 30 5C 48 82 05 04 00 6F 0D 00 80 57

Start delimiter: 7E
Length: 00 1E (30)
Frame type: 91 (Explicit RX Indicator)
64-bit source address: 00 0D 6F 00 04 05 82 48
16-bit source address: 5C 30
Source endpoint: 00
Destination endpoint: 00
Cluster ID: 00 13
Profile ID: 00 00
Receive options: 02
RF data: CC 30 5C 48 82 05 04 00 6F 0D 00 80
Checksum: 57
asked Apr 12, 2017 in IEEE 802.15.4 by fatih New to the Community (0 points)
edited Apr 14, 2017 by fatih

Please log in or register to answer this question.

2 Answers

0 votes
Sounds like you are missing the added steps that the specific sensor requires to remain paired to the network. What I would suggest is that you get an inexpensive Zigbee sniffer that you can connect to your PC so you can see what is going on. Also look at the XBee modules API frames to see what is being sent out. Compare the request with what the manufacture of the sensors documentation says needs to occur. It may be as simple as you sending back a properly formatted frame telling it that it has connected.
answered Apr 13, 2017 by mvut Veteran of the Digi Community (14,666 points)
Thank you for your answer. I have updated the question with the packets information that was sent by the door sensor.
You still need to look at the product manual for the sensor and the HA profile to see what the correct response would be.
This is the manual of the product https://www.centralite.com/downloads/DataSheet-3SeriesDoorSensor.pdf I haven't seen anything related to the ZigBee discovery process.
That is not a product manual. That is a quick start guide for installing it. It does not tell you anything about the HA profile, cluster ID,s or active end points it works with.  It also doesn't tell you anything about the Pull-to-pair joining process it uses.
Have u got to working it?
0 votes
I'm only getting started working with Zigbee, but it's possible what you are seeing is coordinator or router dropping endpoint from client table list because endpoint didn't talk to in some time.

Copy paste from https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
End Device poll timeouts
To better support mobile end devices (end devices that can move around in a network), parent router and
coordinator devices have a poll timeout for each end device child. If an end device does not send a poll request to
its parent within the poll timeout, the parent will remove the end device from its child table. This allows the child
table on a router or coordinator to better accommodate mobile end devices in the network.
answered Jun 19, 2017 by dk New to the Community (1 point)
...