ZigBee sendto recvfrom same end device

Python
1

I combined the ZigBee socket examples in the Digi Python Programming Guide, as shown below, in and attempt to ‘sendto’ and ‘recvfrom’ the same (DESTINATION) endpoint device.

import sys
from socket import *

DESTINATION=(‘00:13:a2:00:40:31:a6:99!’,0xe8, 0xc105, 0x11)

sd = socket(AF_ZIGBEE, SOCK_DGRAM, ZBS_PROT_TRANSPORT)

sd.bind((‘’, 0xe8, 0, 0))

sd.sendto(‘Hello World >’, 0, DESTINATION)

Wait for a frame retruned from the endpoint

Block until timeout or a single frame is received

try:
sd.settimeout(10.0)
payload, src_addr = sd.recvfrom(72)
print payload, src_addr
# Send the payload back to the source
sd.sendto(payload, 0, src_addr)
except Exception:
print ‘socket timed out before receiving a frame’
sys.exit()

Two issue arise and I am asking for help in solving them:

1 If I have more then one end device how can I force the socket to wait for a frame from a specific end device (i.e. DESTINATION)? That is, I have an LT sensor and an RS232 (the DESTINATION) module both at 0xe8 endpoint. If the LT sensor is active it responds to the ‘recvfrom’ . I want to ‘recvfrom’ the RS232 module only.

2 With the LT sensor inactive I can ‘rscvfrom’ the RS232 modeule however the ‘frame’ is only 1 char long even though I am sending a longer message. For testing proosed I have the RS232 moduel connected to HyperTerminal

Any help will be greatly apprciated.

2

I am playing with the same concept for Modbus serial encap. The Xbee SE/DE (src/dst end-point) is a bit misleading if you try to treat them as TCP/UDP ports. The remote XBee will NOT naturally adjust to match changing end-points, instead they must be manually tweaked at each end to work.

Generally the ‘destination’ in the remote XBee always must be 0xE8 - but that is NOT what you bind to. Pick another value like 0xE9.

So for your RS-232, bind on 0xE9 instead of 0xE8, use src end-point = 0xE9 and dst=0xE8 in send-to. Then in the XBee 232 device, set DE to 0xE9 (XCTU might not show, but newer gateway firmware web ui shows DE). This causes the XBee 232 to return responses from src=0xE8 dst=0xE9, which is where your bind is waiting. Bingo - only adapters with DE=0xE9 will cause data on your bind of 0xE9. But note that in both cases the src/SE was kind of a “FYI” - the remote XBee ignores the src=0xE9 you sent, and your code probably ignores the src=0xE8 in the response. You manually setting DE=0xE9 in the XBee 232 and binding on 0xE9 in Python is what makes this work!

Changing the SE/src end-point in the XBee 232 to 0xE9 does NOT allow you to sendto() dst=0xE9. You can, but no serial data will exit the serial port - leave that 0xE8.

If this doesn’t work - I didn’t explain it well as I have it working for Modbus, nicely moving it out of the way so iDigi/Dia can bind on 0xE8 :slight_smile:

3

Lynnl;

Thanks for your input. it works! I must ask how did you discover this?

4

How??? Would you believe dragon bones and chicken entrails? No?

Well, I have worked at a lower Digi “API-frame” level for some time which gives me a better feeling for XBee limitations, plus I had a few people in-the-know which I could bounce ideas off of.

By the way, I have been informed that XCTU DOES allow setting the DE/SE values. For any relevant firmware (such as ZigBee Router AT 0x2264), look under Addressing. You’ll see a closed/collapsed sub-option named “ZigBee Addressing”. Click on it to open and you’ll see the DE/SE/CI options.

I also created a Digi Python Wiki page over-vewing this as it is critical to allow iDigi/Dia to co-exist with stand-alone Python scripts when the two use non-shared Xbee devices on a shared XBee network:
http://www.digi.com/wiki/developer/index.php/Understanding_XBee_EndPoints