RFXCOM binding dropping straight out of the read loop (on Windows) - i.e. not blocking

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enable the RFXCOM binding
2.
3.

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

Expect to see messages being received and decoded. However upon starting the 
openHAB runtime the RFXCOM binding drops out of the while() look in 
RFXComSerialConnector as soon as there is no data to process - instead of 
performing a blocking read. When there is no data on the port, the read() 
returns zero and the loop exits.

I have just pushed a fix to my clone which resolves the issue in my test 
environment (Windows). By setting enableReceiveThreshold(1) the port correctly 
blocks on a read until data is available.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by ben.jone...@gmail.com on 20 Jun 2013 at 6:09

[GoogleCodeExporter]

Pali and I have tested this fix on Windows and OS X and can see no side effects 
(see discussion here 
https://groups.google.com/forum/?fromgroups=#!topic/openhab/GSXHV-GxK1w).

Let me know if you need anything further from me/us in order to merge this into 
the main trunk.

Original comment by ben.jone...@gmail.com on 20 Jun 2013 at 8:33

[GoogleCodeExporter]

the fix noted in #349?

Original comment by teichsta on 21 Jun 2013 at 5:31

[GoogleCodeExporter]

No that is another issue Pali has fixed himself. Mine is related to the
initialisation if the serial port and setting enableReceiveThreshold(1) and
disableReceiveTimeout to ensure the binding works in Windows.

On Friday, June 21, 2013, wrote:

Original comment by ben.jone...@gmail.com on 21 Jun 2013 at 5:46

[GoogleCodeExporter]

Ben has also added new packet support for rfxcom binding on same commits. I 
don't know is that code part fully ready, so I added just this fix on my clone 
for easier merge.

Change set: 
http://code.google.com/r/paulianttila-ihc-binding/source/detail?r=a029d51255713a
f0ec5799e2f3efcbff822fd829

Original comment by pauli.an...@gmail.com on 21 Jun 2013 at 6:29

[GoogleCodeExporter]

Yeah sorry about that - I didn't realise Pali had included the fix from this 
issue as well - that is indeed the same fix. The only difference to my clone is 
that I changed the debug logging on line 163 from DEBUG to TRACE since with 
this change each byte is received/processed one by one - so you end up with a 
lot of debugging lines. Also included is support for the ENERGY packet sent 
from Owl CM160 (which I have been using for testing). 

Note: my clone has 2 change sets for this stuff;

https://code.google.com/r/benjones12-latitude/source/detail?r=64c73837a5b6e8c23c
d923357dd78fdfd33ef73e

https://code.google.com/r/benjones12-latitude/source/detail?r=7d8a14a365e7821aca
2d97a92254fd65049b7c13

Original comment by ben.jone...@gmail.com on 21 Jun 2013 at 7:16

[GoogleCodeExporter]

Original comment by kai.openhab on 7 Aug 2013 at 7:20

• Changed state: ReadyForReview

[GoogleCodeExporter]

Kai/Thomas - can you also review and include the new message support in the 
RFXCOM binding for Energy and Temperature messages?

Original comment by ben.jone...@gmail.com on 7 Aug 2013 at 8:38

[GoogleCodeExporter]

Original comment by teichsta on 13 Aug 2013 at 7:45

• Added labels: Version-1.3.0

[GoogleCodeExporter]

Pulled and pushed the two changesets
https://code.google.com/r/benjones12-latitude/source/detail?r=64c73837a5b6e8c23c
d923357dd78fdfd33ef73e
https://code.google.com/r/benjones12-latitude/source/detail?r=7d8a14a365e7821aca
2d97a92254fd65049b7c13
to the main repo.

Original comment by kai.openhab on 13 Aug 2013 at 9:22

• Changed state: Fixed