niolabs/python-xbee

Python tools for working with XBee radios

XBee

XBee provides an implementation of the XBee serial communication API. It allows one to easily access advanced features of one or more XBee devices from an application written in Python. An example use case might look like this:

#! /usr/bin/python

# Import and init an XBee device
from xbee import XBee, ZigBee
import serial

ser = serial.Serial('/dev/ttyUSB0', 9600)

# Use an XBee 802.15.4 device
xbee = XBee(ser)
# To use with an XBee ZigBee device, replace with:
# xbee = ZigBee(ser)

# Set remote DIO pin 2 to low (mode 4)
xbee.remote_at(
    dest_addr=b'\x56\x78',
    command='D2',
    parameter=b'\x04')

xbee.remote_at(
    dest_addr=b'\x56\x78',
    command='WR')

Installation

pip install xbee

Install from Source

Extract the source code to your computer, then run the following command in the root of the source tree:

python setup.py install

This will automatically install the package for you.

Install with Tornado Support

pip install xbee[tornado]

Documentation

See the python-xbee project on Read the Docs.

To build the documentation yourself, ensure that Sphinx is installed. Then cd into the docs folder, and run ‘make html’. The documentation can then be opened in any modern web browser at docs/build/html/index.html.

For more information about building or modifying this project's documentation, see the documentation for the Sphinx project.

Dependencies

PySerial pip >= 6.0 setuptools >= 8.0

Additional Dependencies

If wanting to use the Tornado IOLoop: Tornado

To run automated tests: pytest

To build the documentation: Sphinx

XBee Firmware

Please ensure that your XBee device is programmed with the latest firmware provided by Digi. Using an old firmware revision is not supported and may result in unspecified behavior.

Contributors

• Paul Malmsten [email protected]
• Greg Rapp [email protected]
• Brian [email protected]
• Chris Brackert [email protected]
• Amit Synderman
• Marco Sangalli
• James Saunders [email protected]
• David Walker [email protected]

python-xbee's Issues

Mangled response frames using digmesh

Using an S8 868LP module

When running local at command SH/SL and DH/DL remotely I get back mangled first byte of the L side in each case

{'status': '\x00', 'frame_id': '5', 'parameter': '\x00\x13\xa2\x00', 'command': 'SH', 'id': 'at_response'}
{'status': '\x00', 'frame_id': '6', 'parameter': 'A]\x16\x91', 'command': 'SL', 'id': 'at_response'}

{'status': '\x00', 'reserved': '\xff\xfe', 'frame_id': '8', 'command': 'DH', 'source_addr': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'parameter': '\x00\x13\xa2\x00', 'id': 'remote_at_response'}
{'status': '\x00', 'reserved': '\xff\xfe', 'frame_id': '9', 'command': 'DL', 'source_addr': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'parameter': 'A]\x16\x91', 'id': 'remote_at_response'}

Also the output of DN run locally gives corrupted Status info "@" ?

{'status': '@', 'frame_id': 'A', 'parameter': '\xff\xfe\x00\x13\xa2\x00A\x87\xb5\xd4', 'command': 'DN', 'id': 'at_response'}

Update README to reference new code location

Change code references from Google Code to GitHub.

Also update example code to use bytes for python 3. ex: b'\x56\x78'

Any example to transfer a string data?

I couldn't find a complete example about transferring and reading a string data.
I installed the package but I can not use it properly.
I also checked this question, but this one is also not working.

Can you provide sender and receiver code? Your docs are really hard to read.

No response after sending a command

Hi,

This is probably a generic question and not specific to this library, but I'd appreciate any help.

I'm using the library to send a 'remote_at' from a coordinator to a sleeping end point and it works well. However, I don't get any confirmation when the command is acked by the end point. Using xctu for the same command I do see that they get a confirmation once the command was received by the end point. Am I missing some other command requesting a response or something?

My code is currently simple:

ser = serial.Serial('/dev/ttyUSB0', 9600)

xbee = ZigBee(ser)
xbee.remote_at(
dest_addr_long=b'',
options=b'\x02',
command=b'D4',
parameter=b'\x04')

print(xbee.wait_read_frame()['status']) // this is where I get stuck

ser.close()

Thanks.

Digimesh Library default values should be bytes

For Python3 the digimesh module fails if given the defaults because they are currently strings and not bytes.

python-xbee and pyserial does not give the same answer for XBee S1

Hi everybody,
for the following frame type 0x83 (RX (Receive) Packet 16-bit Address IO), the following fields returned by python-bee are not correct :: 16-bit source address and RSSI.
The other fields are correct.
Does anyone know how to fix this ?
Thank you

Below are my python scripts ::
##################################################
import serial
from xbee import XBee

serial_port = serial.Serial('/dev/tty.usbserial-A104IBHK', 9600)
xbee = XBee(serial_port)

while True:
try:
print xbee.wait_read_frame()
except KeyboardInterrupt:
break

serial_port.close()
##################################################
import serial

serial_port = serial.Serial('/dev/tty.usbserial-A104IBHK', 9600)

while 1:
a = serial_port.read()
print hex(int(a.encode('hex'), 16))
##################################################

pip installation is not working

I got this output while installing xbee package to python 3.4.2 on RPi 3.
Seems like your README.rst is broken.

sudo pip3 install xbee                                                                                   
Collecting xbee
  Using cached XBee-2.2.4.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-w7vfifrz/xbee/setup.py", line 15, in <module>
        long_description=open('README.rst').read(),
      File "/usr/lib/python3.4/encodings/ascii.py", line 26, in decode
        return codecs.ascii_decode(input, self.errors)[0]
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 1462: ordinal not in range(128)
    
    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-w7vfifrz/xbee/

I installed package with following steps:

~ $ pip3 download xbee
~ $ tar xzf XBee-2.2.4.tar.gz
~ $ cd XBee-2.2.4
~/XBee-2.2.4 $ echo '' > README.rst  # Which clears your doc file.
~/XBee-2.2.4 $ python3 setup.py install

It is a workaround, obviously. Could you fix your doc file.
Or if there is another way, can you write it in the docs?

Clean up xbee base unit tests

1. We shouldn't need to be calling into private methods like _write: https://github.com/nioinnovation/python-xbee/blob/master/xbee/tests/test_base.py#L28
2. Are these _write tests even necessary? ieee tests use send which calls into write so it seems like _write is just being tested unnecessarily here.

ZigBee / Digimesh 16 vs 64 bit destination address default values?

Hi,

I'm using Series 1 XBees with Digimesh 2.4 firmware (VR=8073) and successfully using them via the ZigBee object (thanks for the recent documentation update! ;) )

There is one niggle I'm trying to work out though: the ZigBee object requires both a dest_addr_long (64 bit) and a dest_addr (16 bit) as there are no defaults provided. https://github.com/nioinnovation/python-xbee/blob/master/xbee/zigbee.py#L54

For my Digimesh xbees, the 16bit dest_addr seems to be ignored completely (which is in accordance with the digimesh Transmit Frame docs)

Cross referencing the ZigBee and Digimesh docs, it looks like the Digimesh protocol has marked the old 16bit address field as RESERVED Set to 0xFFFE

The ZigBee spec has "Set to the 16-bit address of the destination device, if known. Set
to 0xFFFE if the address is unknown, or if sending a broadcast."

Would there be any issues with setting the default for the 16 bit addr to 0xFFFE? That would save Digmesh users having to explicitly set it to an arbitrary value. Not sure if it has any negative implications for ZigBee users though?
I notice the ZigBee remote_at command has defaults set for both addresses: https://github.com/nioinnovation/python-xbee/blob/master/xbee/zigbee.py#L45

Alternatively, having a tx_long_addr available for ZigBee/Digimesh, like at https://github.com/nioinnovation/python-xbee/blob/master/xbee/ieee.py#L52 would help avoid having to set the 16bit addr.

I'm happy to raise a PR, but wanted to check whether a default 16bit addr of 0xFFFE makes sense. I imagine ZIgBee users might get frustrated having to enter both addresses too, should there be a default 64bit address also?

Thanks!

Xbee satisfies the requirement on install

I am trying to install python-xbee and it is throwing the error of "could not find a version that satisfies the requirement xbee...". When I check the pip list, XBee 2.3.2 appears in that list, however the module is not found when imported in python. I'm not sure what else to do to fix the problem as other similar issues were not totally resolved. As of right now there seems to be no other means to read an API XBee frame.

Doesn't seem to set the network address like is indicated in the manual

The frame that gets generated when I use:

xbee.tx_long_addr(id='\x10',` frame_id='\x11', dest_addr=xbeeAddress[0:], data=xbeePacket[0:])

doesn't seem to set the network address like is indicated in the manual
https://www.digi.com/resources/documentation/Digidocs/90000991/Default.htm#reference/r_frame_0x10.htm%3FTocPath%3DOperate%2520in%2520API%2520mode%7CAPI%2520frames%7C_____5

And I'm not getting at the destination radio like I expect

Update README to reference new code location

Change code references from Google Code to GitHub.

Also update example code to use bytes for python 3. ex: b'\x56\x78'

wait_read_frame() bad caharacter

I tried to send a node discovery command and read it but it seems always there is a specific portion that consistently misses. My program is as follows:
ser = serial.Serial(XBEEPORT, XBEEBAUD_RATE)
zb = ZigBee(ser)
zb.send('tx_explicit',
dest_addr_long = \x00\x00\x00\x00\x00\x00\xff\xff,
dest_addr = \xff\xfe,
src_endpoint = '\x00',
dest_endpoint = '\x00',
cluster = '\x00\x31',
profile = '\x00\x00',
data = '\xf0'+'\x00'
)
time.sleep(5)
data1 = zb.wait_read_frame()
print data1

Every time and always some hex portions are missed, in one hex portion there is a "o" printed after the hex like /x4Go/, and one hex portion is always printed like /r/ and always one hex portion is completely missed.
Here is the output:
{'profile': '\x00\x00', 'source_addr': '\x00\x00', 'dest_endpoint': '\x00', 'rf_data': '\xf0\x00\x01\x00\x01\x01\x00\x00\x00\x00\x00\x00\x00\xb8o\x05\xfe\xff\xb9\r\xe2\x8e\x1f5\x02\x0f\xf1', 'source_endpoint': '\x00', 'options': '\x01', 'source_addr_long': '\x00\x13\xa2\x00@\xad\xbc\xb8', 'cluster': '\x801', 'id': 'rx_explicit'}

So these bytes \xb8o\x05\xfe\xff\xb9\r\xe2 are supposed to show id of the node. but you can see that one segment was lost shown as \r\ and another segment was lost between first and second segment, you can see the second segment is wrong \xb8o\

Also, the same frame in XCTU works fine. The device I am using is S2, and in XCTU and also in python I can send other commands like on off to the device.

ZigBee TX frame composition

Hi.

I am trying to develop some code in order to send TX frame. I am new to Python, but I have worked before with XBees in C++ without bigger problems. I am using XBee DigiMesh modules and I declared them as ZigBee objects in the code. Could you please explain me, what am I doing wrong? Unfortunately I get SyntaxError in xbee.send().

from xbee import ZigBee
ser = serial.Serial("7dev7ttyACM0", 9600)
xbee = ZigBee(ser)

 xbee.send('tx',{ 'id'=1, 'frame_id'=1, 'dest_addr_long' = b'\x00\x00\x00\x00\x00\x00\xFF\xFF', 'dest_addr'=b'\xFF\xFE', 'options'=b'\xFF\xFE', 'data'=string })

I am working on Raspberry Pi B

thread problem

I am using python-xbee for a little complex case which thread will be used. I am able to request data from API mode coordinator to AT mode router in normal cases, but once I put the code in a thread (actually using "threading") it will never able to read any frame.

I know this should be something related to thread safety things. Then how to solve this problem?

Thanks~

API-mode tx frame

When I send a frame from python "tx frame" to another digimesh connected using XCTU to check the received packets, from 10 packets sent only arrives 1. Please help me with that if I am forgetting to sent any API command or something.
NOTE: I tested both digimesh using XCTU and both can receive and send packets correctly, so it must be the API in python the problem, but I have no idea what.

this is my tx frame
xbee.send("tx", frame_id="G", dest_addr=destination, data=message)

destination: the destination address
data: the message to be sent (ASCII)

Detect client sleep

Hi guys, i'm experimenting with xbees implementing the zigbee protocol.
Currently i'm running asynchronous client code (with tornado) but i'm encountering the issue that commands are dropped when the client devices are in sleep mode.
How would i work around this given my Cyclic Sleep Period of 5 seconds?
I was thinking about implementing a command collector which also pings the client every 5 seconds before flushing its buffer to the device. The problem I see with this approach is that I cannot buffer command frames in between the library and the serial line because frame transmission is entirely abstracted by the library.

Callback not called

Python newbie question: I try to wrap the xBee connection into a class. But the callback gets never called if it is a class method. If it is not in a class it works fine. What can I do?

class Receiver:
def enter(self):
self.serial_port = serial.Serial('/dev/ttyUSB0', 115200)
self.xbee = ZigBee(self.serial_port, escaped=True, callback=self.handlePackets)
Logger.info('Receiver: enter')
return self
def exit(self ,type, value, traceback):
Logger.info('Receiver: exit')
self.serial_port.close()
def handlePackets(data):
Logger.info('Receiver: packet incoming')

Possible issue in long adress source

Hi

I am just giving a try to your library.
So far I have tested communication between my 2 XbeePro devices, it works well.
I am sending data from a device which adress is: 00 13 A2 00 40 E9 A9 4A

With your library, I am just printing the received frame and I got:
'source_addr_long': '\x00\x13\xa2\x00@\xe9\xa9J'

It seems that the library (or pyserial underneath) is formatting some values into caracters
"@" = 0x40
"J" = 0x4A

would be nice to correct it.

installing python-xbee is throwing an error with Python 2.7

Doing a fresh install:

pip install xbee:

Downloading/unpacking xbee
Downloading XBee-2.3.2.tar.gz
Running setup.py (path:/home/vagrant/src/Collector/.rt-Linux-x86_64/build/xbee/setup.py) egg_info for package xbee
  error in XBee setup command: 'extras_require' must be a dictionary whose values are strings or lists of strings containing valid project/version requirement specifiers.
  Complete output from command python setup.py egg_info:
  error in XBee setup command: 'extras_require' must be a dictionary whose values are strings or lists of strings containing valid project/version requirement specifiers.

A recent commit adjusted the setup.extras_requires: 4503031#diff-2eeaed663bd0d25b7e608891384b7298, which I believe introduced this issue.

Installing version 2.3.1 of this module doesn't exhibit this issue:
pip install xbee==2.3.1

Support for Route Record Indicator packets

When using the Python Xbee library in callback mode the callback thread crashes if it receives an API Route Record Indicator (type a1) packet.
Error: Unrecognized response packet with id byte \xa1

This then renders the python program dead as it is unable to process any further received packets.

1. Add supports to the Zigbee API dictionary for Route Record Indicator type packets.
2. Look st whether it is really necessary to break (therefore crash CB thread) if the library receives a packet type it does not know - should it rather just warn?

Jim

Waiting forever to receive a package

In the _wait_for_frame method of the base class, I realize something that might hurt the overall performance of the package. As the package is waiting for the packet to receive, it stays in the loop (listening the serial port) until remaining bytes becomes 0. The link below highlights to mentioned hunk of the code.
https://github.com/nioinnovation/python-xbee/blob/master/xbee/base.py#L124L159

However, there is a problem I have realized with this logic while using the code. Say, after the transmitter starts sending the packages, it resets itself or stops sending the remaining bytes. If this happens, the code gets stuck in the loop at L144.

I am not sure if I am interpreting the code in the wrong way or this is the intended behavior. For my experience, the RF modules which are close the communication range lost signal and the receiver gets stuck in the mentioned loop. Maybe there should be default timeout to complete packet reconstruction after which the class can raise an exception.

If the issue is found reasonable, I can create a pull request by the end of the day.

base.py packet += data 'can't concat bytes to str'

Possible issue with sending AT commands with Python3 in _build_command().

The following code:
self._xbee.send('at', command='MY')

Running on python3 causes error:

  File "../pyalertme/base.py", line 119, in read_addresses
    self._xbee.send('at', command='MY')
  File "/usr/local/lib/python3.5/site-packages/xbee/base.py", line 394, in send
    self._write(self._build_command(cmd, **kwargs))
  File "/usr/local/lib/python3.5/site-packages/xbee/base.py", line 212, in _build_command
    packet += data
TypeError: can't concat bytes to str

Think caused by:

packet = b''
...
...
# Add the data to the packet, if it has been specified.
# Otherwise, the parameter was of variable length, and not given.
if data:
    packet += data

A cheeky workaround is to do:
self._xbee.send('at', command=str.encode('MY'))

did not work with XBEE PRO S3B... is there some update?

My programm works very well with s2b but with pro s3b didn't. The modules are working with the xbee software very well 2milles of range.

Thanks in advance.

XBee Thread

Hi,
Digi will release soon a module with Thread support:
http://www.digi.com/resources/standards-and-technologies/thread-networking-protocol

I also found digi datasheet where they are talking about "thread ready":
https://www.gamma.pl/sklep/img/cms/digi/ds_xbee_zigbee_thread.pdf

There's already an open source implementation of thread here on github:
https://github.com/openthread/openthread

I hope you're considering to support this :)

xbee.wait_read_frame() timeout issue

Hello,
it seems that xbee.wait_read_frame() is not timing out when a timeout is specified
Here's what i have tried:

data = xbee.wait_read_frame(1)

Traceback (most recent call last):
File "<pyshell#32>", line 1, in
data = xbee2.wait_read_frame(1)
TypeError: wait_read_frame() takes exactly 1 argument (2 given)

ser = serial.Serial('COM5', 9600, timeout=1)
xbee=DigiMesh(ser)
data = xbee.wait_read_frame() ##stuck here until a packet is recieved

any help would be appreciated !

bytes rearranged in rf_data for rx_explicit

First of all, thank you for a great library, it is very easy to use!

I am trying to communicate with ZigBee devices via XBee XStick2 ZB. Communication works perfectly, but the data I receive in rf_data field makes no sense (according to ZDO). After additional investigation I figured out that the bytes might be there, but they seem to be rearranged - and not in little endian / big endian kind of way (as far as I can tell).

The easiest example to see what is going on is when I send a request with cluster 0x0005. I get response with cluster 0x8005 as expected:

RESPONSE: {'profile': '\x00\x00', 'source_addr': '\xD2\xDD', 'dest_endpoint': '\x00', 'rf_data': '\xDD\x80\xD2\x05\x00', 'source_endpoint': '\x00', 'options': '\x41', 'source_addr_long': '\x00\x50\x43\xC9\xA3\x36\x8B\x61', 'cluster': '\x80\x05', 'id': 'rx_explicit'}

All other fields look OK, but rf_data has this value:

\xDD\x80\xD2\x05\x00

ZDO documentation says that the fields should be:

---

Active Endpoints Response
Cluster ID: 0x8005
Description: Indicates the list of active endpoints supported on the device.

Field Name	Size (bytes)	Description
Status	1
Network Address	2	Indicates the 16-bit address of the responding device
Active Endpoint Count	1	Number of endpoints in the following endpoint list
Active Endpoint List	Variable	List of endpoints supported on the destination device. One byte per
endpoint.

---

Network Address in this case should be the same as in field source_addr, that is: \xD2\xDD. Note that I have tried this command with different devices and I always get the bytes from source_addr in the same places of rf_data (0 and 2). For instance:

source_addr	rf_data
'\x00\x00'	'\x00\x81\x00\x7E'
'\xD2\xDD'	'\xDD\x80\xD2\x05\x00'
'\x6E\xF7'	'\xF7\x80\x6E\x05\x00'
'\x9C\x81'	'\x81\x80\x9C\x05\x00'
...	...

So, source_addr is there but on wrong address, and I am missing value \x01 (Active Endpoint Count). My guess is that there is either a problem with my USB stick or with parsing rf_data field (more likely?), but I was unable to find the reason (would need to know rx_explicit format to see what is going on).

I have also checked the code from http://www.desert-home.com/2014/10/ok-back-to-zigbee-protocol-and-xbees.html but unfortunately I don't have a ZigBee switch at hand. It seems that author (and commenters) had some problems with inexplicable bytes in rf_data too, though not as much as myself.

I would appreciate some pointers...

>>> xbee.__version__
'2.2.5'

(installed via pip install xbee)

EDIT: Upon further examination I discovered that the problem is not in parsing, but in the raw response as it is passed to XBeeBase._split_response(). For instance:

RESPONSE RAW DATA: '\x91\x00\x50\x43\xC9\xA3\x36\x8B\x61\x65\xAC\x00\x00\x80\x05\x00\x00\x41\xAC\x80\x65\x05\x00'
RESPONSE: {'profile': '\x00\x00', 'source_addr': '\x65\xAC', 'dest_endpoint': '\x00', 'rf_data': '\xAC\x80\x65\x05\x00', 'source_endpoint': '\x00', 'options': '\x41', 'source_addr_long': '\x00\x50\x43\xC9\xA3\x36\x8B\x61', 'cluster': '\x80\x05', 'id': 'rx_explicit'}

Last 5 bytes of raw response data already exhibit the issue with mangled bytes. Is this a problem with firmware? If so, which FW should I upgrade to? Latest? Thanks!

EDIT2: I have checked firmware version via XCTU and it is 21A7, which is latest "ZigBee Coordinator API" firmware. I have upgraded anyway, but there is no change. Also, XCTU doesn't find any ZigBee devices (though xbee library does, albeit with problems as outlined above).

IS Response not parsing correctly?

Hi

Running the current version against a S8 868LP Module

This code :

# Import and init an XBee device
from xbee.thread import XBee
import serial

ser = serial.Serial('/dev/ttyAMA0', 9600)

# Use an XBee 802.15.4 device
xbee = XBee(ser,escaped = True)

# Blink LED
xbee.remote_at(   frame_id='1',
                  dest_addr_long='\x00\x13\xA2\x00\x41\x87\xB5\xD4',
                  options='\x02',
                  command='P8',
                  parameter='\x05')

xbee.remote_at(   frame_id='2',
                  dest_addr_long='\x00\x13\xA2\x00\x41\x87\xB5\xD4',
                  options='\x02',
                  command='P8',
                  parameter='\x04')

xbee.remote_at(   frame_id='3',
                  dest_addr_long='\x00\x13\xA2\x00\x41\x87\xB5\xD4',
                  options='\x02',
                  command='P8',
                  parameter='\x05')

# Analogues AD0-AD3
xbee.remote_at(   frame_id='4',
                  dest_addr_long='\x00\x13\xA2\x00\x41\x87\xB5\xD4',
                  command='D0')

xbee.remote_at(   frame_id='5',
                  dest_addr_long='\x00\x13\xA2\x00\x41\x87\xB5\xD4',
                  command='D1')

xbee.remote_at(   frame_id='6',
                  dest_addr_long='\x00\x13\xA2\x00\x41\x87\xB5\xD4',
                  command='D2')

xbee.remote_at(   frame_id='7',
                  dest_addr_long='\x00\x13\xA2\x00\x41\x87\xB5\xD4',
                  command='D3')

# Dig In D4,D6,D7 & D11
xbee.remote_at(   frame_id='8',
                  dest_addr_long='\x00\x13\xA2\x00\x41\x87\xB5\xD4',
                  command='D4')

xbee.remote_at(   frame_id='9',
                  dest_addr_long='\x00\x13\xA2\x00\x41\x87\xB5\xD4',
                  command='D6')

xbee.remote_at(   frame_id='A',
                  dest_addr_long='\x00\x13\xA2\x00\x41\x87\xB5\xD4',
                  command='D7')

xbee.remote_at(   frame_id='B',
                  dest_addr_long='\x00\x13\xA2\x00\x41\x87\xB5\xD4',
                  command='P1')



xbee.remote_at(   frame_id='F',
                  dest_addr_long='\x00\x13\xA2\x00\x41\x87\xB5\xD4',
                  command='IS')

# Show XBee responses?
while True:
    try:
        response = xbee.wait_read_frame()
        print response
    except KeyboardInterrupt:
        break

ser.close()

Produces this output

{'status': '\x00', 'source_addr': '\xff\xfe', 'source_addr_long': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'frame_id': '1', 'command': 'P8', 'id': 'remote_at_response'}
{'status': '\x00', 'source_addr': '\xff\xfe', 'source_addr_long': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'frame_id': '2', 'command': 'P8', 'id': 'remote_at_response'}
{'status': '\x00', 'source_addr': '\xff\xfe', 'source_addr_long': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'frame_id': '3', 'command': 'P8', 'id': 'remote_at_response'}
{'status': '\x00', 'source_addr': '\xff\xfe', 'source_addr_long': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'frame_id': '4', 'command': 'D0', 'parameter': '\x02', 'id': 'remote_at_response'}
{'status': '\x00', 'source_addr': '\xff\xfe', 'source_addr_long': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'frame_id': '5', 'command': 'D1', 'parameter': '\x02', 'id': 'remote_at_response'}
{'status': '\x00', 'source_addr': '\xff\xfe', 'source_addr_long': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'frame_id': '6', 'command': 'D2', 'parameter': '\x02', 'id': 'remote_at_response'}
{'status': '\x00', 'source_addr': '\xff\xfe', 'source_addr_long': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'frame_id': '7', 'command': 'D3', 'parameter': '\x02', 'id': 'remote_at_response'}
{'status': '\x00', 'source_addr': '\xff\xfe', 'source_addr_long': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'frame_id': '8', 'command': 'D4', 'parameter': '\x03', 'id': 'remote_at_response'}
{'status': '\x00', 'source_addr': '\xff\xfe', 'source_addr_long': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'frame_id': '9', 'command': 'D6', 'parameter': '\x03', 'id': 'remote_at_response'}
{'status': '\x00', 'source_addr': '\xff\xfe', 'source_addr_long': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'frame_id': 'A', 'command': 'D7', 'parameter': '\x03', 'id': 'remote_at_response'}
{'status': '\x00', 'source_addr': '\xff\xfe', 'source_addr_long': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'frame_id': 'B', 'command': 'P1', 'parameter': '\x03', 'id': 'remote_at_response'}
{'status': '\x00', 'source_addr': '\xff\xfe', 'source_addr_long': '\x00\x13\xa2\x00A\x87\xb5\xd4', 'frame_id': 'F', 'command': 'IS', 'parameter': [{'adc-6': 10241, 'adc-2': 32769, 'dio-6': False, 'dio-7': False, 'dio-4': False}], 'id': 'remote_at_response'}

The parsed response from IS makes no sense to me, there should be 4x Dig ins (4,6,7 &11) and 4x Analogs, (AD0-3),

{'adc-6': 10241, 'adc-2': 32769, 'dio-6': False, 'dio-7': False, 'dio-4': False}

What's gone wrong here with the lib decoding (or am I just being very fat fingered with my code?)

Thanks

Andrew.

Minor refactoring due to what it seems a fail in the Digi Xbee documentation

What steps will reproduce the problem?

1. Trying to issue an 'ND' command (API mode) and later parsing it (the problem is in the parsing).
   For example:
   xbee.send("at", frame='A', command='ND')
   print xbee.wait_read_frame()

What is the expected output? What do you see instead?

You were expected to receive the following information associated with the ND command refered in the datasheet:

QUOTE:

Node Discover. Discovers and reports all RF modules found. The following information is reported for each module discovered.
MY
SH
SL
NI (Variable length)
PARENT_NETWORK ADDRESS (2 Bytes)
DEVICE_TYPE (1 Byte: 0=Coord, 1=Router, 2=End Device)
STATUS (1 Byte: Reserved)
PROFILE_ID (2 Bytes)
CRE
MANUFACTURER_ID (2 Bytes)

If ND is sent through the API, each response is returned as a separate
AT_CMD_Response packet. The data consists of the above listed bytes without the carriage return delimiters. The NI string will end in a "0x00" null character. The radius of the ND command is set by the BH command.

END QUOTE:

Instead it seems like the module sends you additional data (4 bytes) that are not refered in the datasheet. To me these 4 bytes seem to be additional info refering to the command 'DD' (Device identifier type). This makes the method "_parse_ND_at_response(self, packet_info)" send an Error message.

What version of the product are you using? On what operating system?
I m using the Xbee Zigbee Pro S2B, later i will test this with Xbee Zigbee S2B

Please provide any additional information below.

You can solve this adding the following line (in method _parse_ND_at_response(self, packet_info)):

"result['device_type_identifier'] = packet_info['parameter'][null_terminator_index+9:null_terminator_index+13]"

after the line:

"result['manufacturer'] = packet_info['parameter'][null_terminator_index+7:null_terminator_index+9]"

and modifying the test before return of the method to:

if null_terminator_index+13 != len(packet_info['parameter']):
                   raise ValueError("Improper ND response length: expected {0}, read {1} bytes".format(len(packet_info['parameter']), null_terminator_index+9))

The correct way to solve probably would be to take this last test out, and believe in the checksum. This way if Digi decides to add more information to the DATA packet you won t have problems and will only parse it if necessary

---

UPDATE

Additional information of the packets just to help understand:

1 DEVICE -------------------------

Frame data: 88014e440000000013a20040b0e9e34d41494e00fffe0000c105101e00030000
Frame raw_data: 7e002088014e440000000013a20040b0e9e34d41494e00fffe0000c105101e000300005a
node_identifier 4d41494e
parent_address fffe
device_type 00
status 00
profile_id c105
manufacturer 101e
device_type_identifier 00030000
{'status': '\x00', 'frame_id': '\x01', 'parameter': {'status': '\x00', 'source_addr': '\x00\x00', 'parent_address': '\xff\xfe', 'profile_id': '\xc1\x05', 'device_type_identifier': '\x00\x03\x00\x00', 'source_addr_long': '\x00\x13\xa2\x00@\xb0\xe9\xe3', 'device_type': '\x00', 'node_identifier': 'MAIN', 'manufacturer': '\x10\x1e'}, 'command': 'ND', 'id': 'at_response'}

2 DEVICE -------------------------

Frame data: 88014e44004b0e0013a20040c1bb0b20454e44320000000200c105101e00030000
Frame raw_data: 7e002188014e44004b0e0013a20040c1bb0b20454e44320000000200c105101e00030000ed
node_identifier 20454e4432
parent_address 0000
device_type 02
status 00
profile_id c105
manufacturer 101e
device_type_identifier 00030000
{'status': '\x00', 'frame_id': '\x01', 'parameter': {'status': '\x00', 'source_addr': 'K\x0e', 'parent_address': '\x00\x00', 'profile_id': '\xc1\x05', 'device_type_identifier': '\x00\x03\x00\x00', 'source_addr_long': '\x00\x13\xa2\x00@\xc1\xbb\x0b', 'device_type': '\x02', 'node_identifier': ' END2', 'manufacturer': '\x10\x1e'}, 'command': 'ND', 'id': 'at_response'}

Sending API frames

I'm not sure if this constitutes an issue, but I am trying to send a frame with no success. I followed the documentation for sending (xbee.send("at", frame="A", command=MY)) and cannot get anything on my second XBee. The documentation does not explain what the first argument is "at" or the command parameter, so I am not sure what these do for sending frames. Any explainations?

No second answer after one successful conversation with encryption

Hi,
Sorry, I'm in a hurry so a brief description.
When I have encryption enabled (EE) in XCTU:
I can only have one successful data exchange. That means the receiver, which is a router, receives and replies sucessfully. When I try the same operation again, without restarting the receiver, the receiver don't get any frames at all afterwards. When the receiver is a coordinator everything's fine.
When EE is 0 everything works fine. It's maybe a digi bug, but I just wanted to let you know.
I'm using XB24D
My Best

Speed seems slow

I am using several XBees (S2 ZigBee). One of them was set to API 1 mode as Coordinator, all the others were set to AT mode as Routers.
I use the coordinator send out tx command to routers request for data, once routers receive the command, they will decide which data to send back. Then the coordinator receives data. I am only sending out data request to one router currently but it seems very slow. The data packages are very small, less than 30 bytes. Is there a way to make this process faster? Currently the whole process takes almost 1 sec for one loop. I wish to have it about 0.02s, i.e., 50Hz.

Thanks~