Association - Strange messages on protocol API 0x95

Hello,

I am developing a program to identify that a zigbee device was activated by a button press. As these devices must be sleeping most of the time, I decided to use the Association buttom for this, as it is able to wake up the device and identify itself. So, when someone presses a button, a 0x95 API transmission is issued on the network. I also need to identify the NI (node identification) string of the radio.

I am using a CPX4 as my coordinator and 7 end devices. I am using these lines to listen to incoming messages:

sd = socket.socket(socket.AF_ZIGBEE, socket.SOCK_DGRAM, socket.ZBS_PROT_TRANSPORT)
sd.bind(("", 0xe8, 0, 0))
sd.settimeout(None)
packet, source = sd.recvfrom(72)

Although this is working quite fine, I am surprised as the incoming messages DO NOT follow the described protocol for API 0x95. The messages do not even start with 0x7E!!! The messages from each radio are consistent (all have 28 bytes - manual prescribes a minimum of 35) and follow a pattern, but each one starts diferently.

Here are 2 examples.

API ID  = 0x95
NI      = 20005
Src Add = [00:13:a2:00:40:62:2e:c9]!
packet  = 02ad0013a20040622ec932303030350000000201c105101e00030000
len(packet): 28

API ID  = 0x95
NI      = 20006
Src Add = [00:13:a2:00:40:62:2e:d0]!
Packet  = 04740013a20040622ed032303030360000000201c105101e00030000
len(packet): 28

As can be observed, originating radio address and NI are part of the messages, as well as other expected information. But there is something missing, no chksum, and some zeros in the end…

Any explanations? What may I be doing wrong?

Thanks for any assistance,

Regards,

Isaac

You might want to try to read this post first
http://forums.digi.com/support/forum/viewthread_thread,953_offset,20#20656

and later download the CLI Reference Documentation <- they have updated it to include XBee family commands recently. (About time!)

Basically that post will explain the usage of “tracing” from the ConnectPort’s Command Line Interface. There you’ll find why the “7E” and “Checksum” bytes were missing. It’s going to help you tremendously for all your future work too.

socket.socket(socket.AF_ZIGBEE, …) is NOT giving you API frames. It was an attempt to isolate you from the need to use them. The ‘packet’ you are seeing is just the payload in the same way that socket() doesn’t return the TCP, UDP or IP headers to you - or require you to create them as input.

Looking at what you see, I assume the first byte of the ‘packet’ is the offset 15 ‘Source 16-bit Address’ described in the ZB manual.

You are correct!

The output for the serial port follows the API frame format exactly as described in the product manual. As I am using the socket command for the first time I presumed it will give a similar output.

Now I see that the manual implicitly say something about this in the sentence:

“The data portion of this frame is similar to a network discovery response frame (see ND command).”

But the description of ND command is not clear:

“it contains the device’s address, node identifier string (NI command), and other relevant data.”

So, I will take a better look at the ND command response structure as it is supposed to be the same response I am getting out of the socket command as well as the links you posted.

Thank you DenzChoe and thank you lynnl.

Also be aware that the NO setting modifies the ND response. For example NO=0x01 adds a 32-bit DD value to the ND response.

And checking the responses I am getting (first post) I can see that “NO” is set to 0x01 as the last four hex digits are the DD value.