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<CR>
SH<CR>
SL<CR>
NI<CR> (Variable length)
PARENT_NETWORK ADDRESS (2 Bytes)<CR>
DEVICE_TYPE<CR> (1 Byte: 0=Coord, 1=Router, 2=End Device)
STATUS<CR> (1 Byte: Reserved)
PROFILE_ID<CR> (2 Bytes)
CRE
MANUFACTURER_ID<CR> (2 Bytes)
<CR>
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

Original issue reported on code.google.com by lmbpsoa...@gmail.com on 10 Jun 2015 at 10:43

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'}

Original comment by lmbpsoa...@gmail.com on 10 Jun 2015 at 10:53

cthuun / python-xbee

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