Python Migration Guide for NDS 2.8 to 2.9
From Digi Developer
Python Migration Guide for NDS 2.8 to 2.9
Existing Python applications are potentially affected by an XBee Socket API change summarized below.
The API change specifically affects the recvfrom() call, and existing application python code should be audited for len() checks on the socket returned from recvfrom(). Testing python applications under NDS 2.9 is also recommended to verify backward compatibility. The Dia (Device Integration Application) framework does check the length returned by recvfrom(). As a result, applications using Dia 1.1.16 and prior must upgrade to 1.1.17 (or later). No additional configuration changes should be necessary.
To understand if you are running firmware 2.8 or 2.9, see What is Your Product Firmware Level?
XBee Socket Change Summary
Effective in the NDS 2.9, the AF_XBEE sockets have had their addressing structure extended to include an options field and a transmission_id field. When using Python this means the addressing tuple has changed from 4 elements to 6 elements in length. Backward compatibility has been preserved so long as the length of the address tuple is not checked by user source code. The new fields in the addressing tuple are considered optional and a 4-element tuple may still be used in all socket operations.
The options field is used differently depending on whether a packet is being transmitted or received. The meanings of the options are defined in constants which begin with XBS_OPT_*.
The transmission_id field is used to track information about a specific datagram transmission sent with a socket object instance's sendto() method. The transmission_id is only used when the XBS_SO_EP_TX_STATUS socket option is enabled at the XBS_SOL_ENDPOINT level. If this option is enabled, the socket will provide transmission status frames with the transmission_id field set to the value given by the user in a prior sendto() call.
Transmission information arrives in three formats: X-API type 0x89 (XBee Transmit Status Frame), X-API type 0x8b (ZigBee XBee Transmit Status Frame), and internal error codes. The cluster_id field specifies the type of information: 0x89, 0x8b, and 0x0 respectively. Any non-zero internal error code should be considered a transmission failure. The X-API frames may be decoded according to the XBee API reference documentation.
