xbee.wait_read_frame() has no time protection

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Distant ZigBee (or, open a virtual (non-conected) serial port
2. Open a ZigBee object and run wait_read_frame()
3. The program will not respond anymore

What is the expected output? What do you see instead?
The output could be a integer, or anything else.

What version of the product are you using? On what operating system?
Gentoo Linux. python-xbee 2.0.0

Please provide any additional information below.
I did an implementation, but I would like you take a look on it.

Original issue reported on code.google.com by tickbr...@gmail.com on 10 Mar 2012 at 2:09

Attachments:

• base.py

[GoogleCodeExporter]

Thank you very much for posting this, and my apologies for the delay in 
responding.

At the moment, I usually advise people to use the timeout parameter when 
opening a serial port. Reads that timeout internally within python-xbee should 
be handled appropriately (though I haven't tested this much).

I will try to take a look at your implementation this weekend though and see if 
we can integrate your ideas.

Thanks!

Original comment by pmalms...@gmail.com on 30 Mar 2012 at 7:06

[GoogleCodeExporter]

I was having the exact same problem, I was afraid I would never solve it. I 
tried your implementation in order to fix it (couldn't wait around for an 
official integration) and it seems to work pretty well. I modified it slightly 
so that it returns an empty dictionary instead of a 1 when no packet has been 
found, I think that's cleaner but maybe it's just preference. I'm going to make 
a clone with this change for use in my project right now, I hope you don't mind.

Thank you, finding this post has helped me a lot.

Original comment by fireforg...@gmail.com on 10 Apr 2012 at 11:22

[GoogleCodeExporter]

Hello,

I have no problem with it. I just would like you send to me your correction
to return an empty dictionary, it's much more elegant!

Thanks!

-- 
/*

Original comment by tickbr...@gmail.com on 11 Apr 2012 at 11:07

[GoogleCodeExporter]

Actually wouldn't the expected behavior be to raise an exception or return None?

Original comment by tmnich...@gmail.com on 18 Jul 2012 at 11:27

[GoogleCodeExporter]

I think for consistency it should match the Serial library and raise a 
TimeoutException. It makes sense since that's already a pattern I've come 
across.

Original comment by kashif...@gmail.com on 15 May 2013 at 3:48

[GoogleCodeExporter]

Is the zbee.wait_read_frame() as been updated yet with a timeout? This is a 
major problem for me right now and i am looking at a way around that?

Original comment by martin.e...@gmail.com on 23 Sep 2013 at 3:20

[GoogleCodeExporter]

See https://github.com/tomstrummer/python-xbee it has this fix as well as 
support for the S3B.  Quite a few changes, see: 
https://github.com/tomstrummer/python-xbee/commits/master 

Original comment by tmnich...@gmail.com on 23 Sep 2013 at 12:18

[GoogleCodeExporter]

Does anyone fix this? tomstrummer's version is not working either, it seems 
like its hanging at byte = self.serial.read()

Original comment by yakle1...@gmail.com on 6 Mar 2014 at 2:40

[GoogleCodeExporter]

re: #8, you need to setup the underlying serial connection so that the `read()` 
call won't block.  Otherwise, yes, self.serial.read() will still hang.  Here's 
an example of what we're doing:

self.xbee = xbee.DigiMesh( ser= { 'port': tty, 'baudrate' : BAUD, 'timeout' : TIMEOUT }, escaped = False, callback = self.callback )

That 'timeout' param is what will prevent serial.read() from blocking.  It just 
loops if it doesn't get any bytes before the serial timeout but it allows the 
thread to exit cleanly when `halt` is called.

Original comment by tmnich...@gmail.com on 14 Mar 2014 at 2:09

[GoogleCodeExporter]

How about running wait_read_frame() in different thread?

Original comment by markusfo...@gmail.com on 10 Sep 2014 at 8:30

[GoogleCodeExporter]

Re #10 no need. If the serial port is properly configured with a timeout, 
wait_read_frame() should never hang for longer than that amount of time. Did 
the changes from my fork ever get merged into the upstream?

Original comment by tmnich...@gmail.com on 13 Sep 2014 at 4:30