No response after sending a command

[a7ypically]

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.

[jamesleesaunders]

Hi @a7ypically

I am not an expert but I will try to help. Have you considered trying to use it in Asynchronous Mode (see https://python-xbee.readthedocs.io/en/latest/). I am not sure but it could be that the wait_read_frame() is too late and the reply message has already been sent?

Maybe try this...

#! /usr/bin/python
import serial
from xbee import ZigBee
import pprint

# Open serial port and create xbee object
ser = serial.Serial('/dev/ttyUSB0', 9600)

# Called each time a packet is received - print packet
def receiveMessage(data):
    pp = pprint.PrettyPrinter(indent=4)
    pp.pprint(data)

# Called if there is an error - display error message
def xbeeError(error):
    print "XBee Error:", error

# Create ZigBee library API object, and spawn a listener thread
zb = ZigBee(ser, callback=receiveMessage, error_callback=xbeeError)

# Send packet
xbee.remote_at(dest_addr_long=b'', options=b'\x02', command=b'D4', parameter=b'\x04')

zb.halt()
ser.close()

You could also try the Synchonous Mode? with a loop around 'print xbee.wait_read_frame()'?

Hope this helps?

Jim

[a7ypically]

Hi Jim,

Thanks for the suggestion, however I still don't get any response with the async approach.

a

[jamesleesaunders]

Oh, thats a shame. Did you gat any error messages? You say you can see a response packet on X-CTU? Could you perhaps copy and paste this packet data to this thread. I could then possibly modify one of the unittests to see if the packet is parsed/accepted by python-xbee correctly.

[jamesleesaunders]

Did you get this yo work? Do you believe this is a python-xbee code bug, or do you think this issue can be closed?

[mpieper]

Hey I'll just take a shot at this real quick.

1. In order to get a response you HAVE to have a frame id when you send it out, otherwise the xbee assumes you're not keeping tabs on it. E.g. frame_id=0x01 on your message declaration. Note that the default value for frame_id (if you don't define it) is 0x00 -> No response.
2. You've got to make sure your handlers have the right id's. There's some inconsistencies with the library / the stuff that I'm using (Xbee pro 900hp uses different tags etc.). You'll have to check the ieee.py api_commands table under the XBee class definition to make sure that your frames are listed in there with the appropriately defined regions (this area could use some work imho and it's pretty low hanging fruit if you ask me). If you look at the frames-generator from xctu there's about 30 frame-types that are missing support from the library.

I found that the dispatch method is much more straightforward for the async stuff. Check out that example and give it a go (if you haven't already given up... 3 months is a long time). Good luck.

edit: And of course I shall now place my foot in my mouth. The ZigBee class has the identifiers matching up with the device I'm using.

[jamesleesaunders]

Appreciate this is a little late now, but have you tried escaped=True?

ser = serial.Serial('/dev/ttyUSB0', 9600) xbee = ZigBee(ser, escaped=True)

I found this to be the solution to lots of 'there is no response' type issues.

[mlasevich]

To clarify for those who will come across this later, escaped = True is used when your XBee is in "escaped" API mode (AT AP2) vs non-escaped API mode (AT AP1). If you have a mismatch between API level on XBee and API level in the library, things may not go well in sometimes subtle and annoying ways. So, while you should likely add escaped = True, you should also make sure your XBee is in API mode 2 ( I just run xbee.send('at', command='AP', parameter='\x02') as first thing when opening a connection, just to make sure and not worry about it.)