weird value with rfxcom

[giejo]

Hi, thanks for your great work.
On a fresh new install (git clone) when i try rfxcom-rx, i ve got some weid values (i have some oregon sensors and X10 ms13)

[beanz]

Can you elaborate? For instance, what values are you seeing that you aren't expecting? Can you send xpl-logger output of for the unexpected values?

Note that xpl-rfxcom-rx reports everything it receives even if the sending device is not yours. ;-)

[giejo]

Thanks for your response
here is the output of "xpl-rfxcom-rx --rfxcom-rx-verbose --rfxcom-rx-tty /dev/ttyUSB0"
Processed: master version 4d.51
Processed: master mode 41.
Processed: master mode 41.
Processed: master unknown 2d.10e380197005
Processed: master unknown 2d.10e380197005(dup)
Processed: master unknown 2d.10cb50156006
Processed: master unknown 2d.10cb50156006(dup)
Processed: master x10 20.f00f00ff: x10/j1/on
xpl-trig/x10.basic: bnz-rfxcomrx.sheeva -> * on/j1
Processed: master x10 20.f00f00ff(dup): x10/j1/on

It seems to work for x10 but i cannot see my oregon sensors (maybe they are in the "unknown" line)
With an older version installed on debian with package, i was able to see oregon sensors

[beanz]

What are the model numbers of the oregon sensor you have?

[giejo]

I only have Thermo-Hygro sensors model : THGR228N

[vdomos]

Hi,
I have the same problem with THGR228N sensors.
I don't receive data from this model.
I have other working Oregon sensors like thn132n and thwr288a.de.

Here is verbose output of rfxcom-rx:
$ /usr/bin/xpl-rfxcom-rx --verbose --rfxcom-rx-verbose --interface eth0 --rfxcom-rx-baud 4800 --rfxcom-rx-tty /dev/rfxcom
Listening on 192.168.0.4:39372
Sending on 192.168.0.255
Processed: master version 4d.2b
Processed: master mode 41.
Processed: master mode 41.
Processed: master oregon 44.ea4c10ec602010f41e:
sensor/thn132n.ec[temp]=20.6
sensor/thn132n.ec[battery]=90%
Processed: master unknown 2d.20d684163005
Processed: master unknown 2d.20d684163005(dup)
Processed: master oregon 44.ea4c10ec602010f41e:
sensor/thn132n.ec[temp]=20.6
sensor/thn132n.ec[battery]=90%
Processed: master oregon 44.ea4c10ec602010f41e(dup):
sensor/thn132n.ec[temp]=20.6
sensor/thn132n.ec[battery]=90%
Processed: master unknown 2d.20d684163005
Processed: master unknown 2d.20d684163005(dup)
Processed: master oregon 50.aacc132d900820c75be2:
sensor/rtgr328n.2d[temp]=8.9
sensor/rtgr328n.2d[humidity]=72
sensor/rtgr328n.2d[battery]=90%
rtgr328n.2d/temp/8.9
Processed: master oregon 50.aacc132d900820c75be2(dup):
sensor/rtgr328n.2d[temp]=8.9
sensor/rtgr328n.2d[humidity]=72
sensor/rtgr328n.2d[battery]=90%
Processed: master unknown 2d.40fc70160005
Processed: master oregon 50.ea4c10de8008a0440e00:
sensor/thwr288a.de[temp]=8.8
sensor/thwr288a.de[battery]=90%
thwr288a.de/temp/8.8
Processed: master oregon 44.ea4c10ec602010f41e:
sensor/thn132n.ec[temp]=20.6
sensor/thn132n.ec[battery]=90%
Processed: master unknown 2d.40fc70169004
Processed: master oregon 50.9acc132d900820c75a84:
sensor/rtgr328n.2d[temp]=8.9
sensor/rtgr328n.2d[humidity]=72
sensor/rtgr328n.2d[battery]=90%

With libxpl-perl 0.11 version, I receive this data for thgr228n sensors:
Processed: 501a2d20d61608601641b6
xpl-trig/sensor.basic: bnz-rfxcomrx.nslu2 -> * - thgr228n.d6[temp]=8.1
xpl-trig/sensor.basic: bnz-rfxcomrx.nslu2 -> * - thgr228n.d6[humidity]=66
xpl-trig/sensor.basic: bnz-rfxcomrx.nslu2 -> * - thgr228n.d6[battery]=10
Processed: 501a2d40fc20187015477c
xpl-trig/sensor.basic: bnz-rfxcomrx.nslu2 -> * - thgr228n.fc[temp]=18.2
xpl-trig/sensor.basic: bnz-rfxcomrx.nslu2 -> * - thgr228n.fc[humidity]=57
xpl-trig/sensor.basic: bnz-rfxcomrx.nslu2 -> * - thgr228n.fc[battery]=90

I have this packages installed en Debian Squeeze:
$ dpkg -l|grep -E "xpl|rfx"
ii libanyevent-rfxcom-perl 1.111960-1 Perl AnyEvent extension for RFXCOM RF receivers/transmitters
ii libdevice-rfxcom-perl 1.110800-1 Perl extension for RFXCOM RF receivers/transmitters
ii libxpl-perl 0.12-1 Perl extension for xPL Protocol
ii xpl-common-perl 0.12-1 Common configuration for all xPL clients built on xPL-Perl
ii xpl-rfxcom-perl 0.12-1 xPL RFXCOM RF receiver/transmitter application
ii xpl-rfxcom-rx-perl 0.12-1 xPL RFXCOM RF receiver application
ii xpl-rfxcom-tx-perl 0.12-1 xPL RFXCOM RF transmitter application

thanks,

[beanz]

Can either of you - @giejo has fewer sensors so that might be marginally easier to figure out - send me some output from the command:

strace -tt -xx -s 1024 -e read -p <pid-of-xpl-rfxcom-rx>

so I can see what is actually being read from the tty device.

I think I see what is going on - thanks to @domos78 including the old 0.11 output - the lines like:

Processed: master unknown 2d.40fc70160005

are actually supposed to have 501a on the start and two more bytes on the end so they'd be recognized correctly but for some reason these are missing. No idea why but hopefully seeing the actual data on the tty will help figure it out. (Or at least reproduce it as a step to figuring it out.)

Regards,
Mark.

[vdomos]

Hello,
Here is the output of the strace and xpl-rfcom-rx commands:

Processed: master oregon 44.ea4c10ec702020841b:
sensor/thn132n.ec[temp]=20.7
sensor/thn132n.ec[battery]=90%
Processed: master oregon 44.ea4c10ec702020841b(dup):
sensor/thn132n.ec[temp]=20.7
sensor/thn132n.ec[battery]=90%
Processed: master unknown 2d.40fc40194005
Processed: master unknown 2d.40fc40194005(dup)
Processed: master unknown 2d.20d674184005
Processed: master oregon 44.ea4c10ec702020841b:
sensor/thn132n.ec[temp]=20.7
sensor/thn132n.ec[battery]=90%
Processed: master oregon 44.ea4c10ec702020841b(dup):
sensor/thn132n.ec[temp]=20.7
sensor/thn132n.ec[battery]=90%
Processed: master unknown 2d.40fc40194005
Processed: master unknown 2d.20d674184005
Processed: master unknown 2d.20d674184005(dup)
Processed: master oregon 44.ea4c10ec702020841b:
sensor/thn132n.ec[temp]=20.7
sensor/thn132n.ec[battery]=90%
Processed: master oregon 44.ea4c10ec702020841b(dup):
sensor/thn132n.ec[temp]=20.7
sensor/thn132n.ec[battery]=90%

17:14:07.691223 read(6, "\x44\xea", 8192) = 2
17:14:07.696148 read(6, "\x4c\x10", 8192) = 2
17:14:07.700048 read(6, "\xec\x70", 8192) = 2
17:14:07.703197 read(6, "\x20\x20", 8192) = 2
17:14:07.708049 read(6, "\x84\x1b", 8192) = 2
17:14:07.864234 read(6, "\x44\xea", 8192) = 2
17:14:07.865185 read(6, "\x4c", 8192) = 1
17:14:07.867070 read(6, "\x10", 8192) = 1
17:14:07.872017 read(6, "\xec\x70", 8192) = 2
17:14:07.876186 read(6, "\x20\x20", 8192) = 2
17:14:07.879083 read(6, "\x84", 8192) = 1
17:14:07.884363 read(6, "\x1b", 8192) = 1
17:14:08.759221 read(6, "\x2d", 8192) = 1
17:14:08.760070 read(6, "\x40", 8192) = 1
17:14:08.764450 read(6, "\xfc\x40", 8192) = 2
17:14:08.767107 read(6, "\x19", 8192) = 1
17:14:08.771098 read(6, "\x40\x05", 8192) = 2
17:14:08.776416 read(6, "\x46\x92", 8192) = 2
17:14:08.959206 read(6, "\x2d\x40", 8192) = 2
17:14:08.964073 read(6, "\xfc\x40", 8192) = 2
17:14:08.967106 read(6, "\x19", 8192) = 1
17:14:08.972150 read(6, "\x40\x05\x46", 8192) = 3
17:14:08.976103 read(6, "\x92", 8192) = 1
17:14:34.795216 read(6, "\x50", 8192) = 1
17:14:34.800083 read(6, "\x2d\x20", 8192) = 2
17:14:34.803129 read(6, "\xd6", 8192) = 1
17:14:34.803743 read(6, "\x74", 8192) = 1
17:14:34.808047 read(6, "\x18\x40", 8192) = 2
17:14:34.812118 read(6, "\x05", 8192) = 1
17:14:34.812710 read(6, "\x42", 8192) = 1
17:14:34.816051 read(6, "\xda", 8192) = 1
17:14:34.999209 read(6, "\x2d\x20", 8192) = 2
17:14:35.004100 read(6, "\xd6\x74", 8192) = 2
17:14:35.008241 read(6, "\x18\x40", 8192) = 2
17:14:35.012174 read(6, "\x05\x42", 8192) = 2
17:14:35.016092 read(6, "\xda", 8192) = 1
17:14:46.692187 read(6, "\x44\xea\x4c", 8192) = 3
17:14:46.696398 read(6, "\x10\xec", 8192) = 2
17:14:46.699186 read(6, "\x70", 8192) = 1
17:14:46.703060 read(6, "\x20\x20", 8192) = 2
17:14:46.707118 read(6, "\x84\x1b", 8192) = 2
17:14:46.863234 read(6, "\x44\xea", 8192) = 2
17:14:46.868523 read(6, "\x4c\x10\xec", 8192) = 3
17:14:46.871059 read(6, "\x70", 8192) = 1
17:14:46.875141 read(6, "\x20\x20", 8192) = 2
17:14:46.879103 read(6, "\x84\x1b", 8192) = 2
17:14:51.264121 read(6, "\x50\xea", 8192) = 2
17:14:51.268055 read(6, "\x4c\x10", 8192) = 2
17:14:51.272049 read(6, "\xde\x62", 8192) = 2
17:14:51.276092 read(6, "\x50", 8192) = 1
17:14:51.280078 read(6, "\x64\x0e", 8192) = 2
17:14:51.284109 read(6, "\x00", 8192) = 1
17:14:51.455223 read(6, "\x50", 8192) = 1
17:14:51.460056 read(6, "\xea\x4c", 8192) = 2
17:14:51.463944 read(6, "\x10\xde", 8192) = 2
17:14:51.467179 read(6, "\x62", 8192) = 1
17:14:51.472117 read(6, "\x50\x64", 8192) = 2
17:14:51.475130 read(6, "\x0e", 8192) = 1
17:14:51.479091 read(6, "\x00", 8192) = 1
17:14:51.755205 read(6, "\x50", 8192) = 1
17:14:51.759138 read(6, "\x2d", 8192) = 1
17:14:51.759919 read(6, "\x40", 8192) = 1
17:14:51.763081 read(6, "\xfc", 8192) = 1
17:14:51.768435 read(6, "\x40\x19", 8192) = 2
17:14:51.769137 read(6, "\x40", 8192) = 1
17:14:51.772097 read(6, "\x05", 8192) = 1
17:14:51.776043 read(6, "\x46\x92", 8192) = 2
17:14:51.959996 read(6, "\x2d\x40", 8192) = 2
17:14:51.963962 read(6, "\xfc\x40", 8192) = 2
17:14:51.967967 read(6, "\x19\x40", 8192) = 2
17:14:51.971955 read(6, "\x05\x46", 8192) = 2
17:14:51.975982 read(6, "\x92", 8192) = 1
17:15:15.795233 read(6, 0x9572097, 8192) = -1 EAGAIN (Resource temporarily unavailable)
17:15:15.800079 read(6, "\x2d\x20", 8192) = 2
17:15:15.804137 read(6, "\xd6\x74", 8192) = 2
17:15:15.807103 read(6, "\x18\x40", 8192) = 2
17:15:15.811099 read(6, "\x05", 8192) = 1
17:15:15.816114 read(6, "\x42\xda", 8192) = 2
17:15:15.999224 read(6, "\x2d\x20", 8192) = 2
17:15:16.004054 read(6, "\xd6\x74", 8192) = 2
17:15:16.007105 read(6, "\x18\x40", 8192) = 2
17:15:16.012044 read(6, "\x05\x42", 8192) = 2
17:15:16.015274 read(6, "\xda", 8192) = 1
17:15:25.692252 read(6, "\x44\xea\x4c", 8192) = 3
17:15:25.696057 read(6, "\x10", 8192) = 1
17:15:25.696557 read(6, "\xec", 8192) = 1
17:15:25.700024 read(6, "\x70", 8192) = 1
17:15:25.700484 read(6, "\x20", 8192) = 1
17:15:25.704122 read(6, "\x20", 8192) = 1
17:15:25.704660 read(6, "\x84", 8192) = 1
17:15:25.709680 read(6, "\x1b", 8192) = 1
17:15:25.863222 read(6, "\x44\xea", 8192) = 2
17:15:25.868341 read(6, "\x4c\x10\xec", 8192) = 3
17:15:25.872131 read(6, "\x70", 8192) = 1
17:15:25.875094 read(6, "\x20", 8192) = 1
17:15:25.875562 read(6, "\x20", 8192) = 1
17:15:25.880030 read(6, "\x84\x1b", 8192) = 2
17:15:28.251020 --- SIGINT (Interrupt) @ 0 (0) ---

Best reagrds,
Dan

[beanz]

Thanks. Now I'm really confused as it looks like the bytes read from the tty are exactly what is being reported as being processed in the case of the incorrect output. In other words, if those were really the bytes the code is interpreting them as I'd expect.

I've no idea why the bytes would be "missing" perhaps the serial port isn't initialized correctly or something? I might have to sleep on it as it isn't immediately obvious to me what would cause this sort of behaviour.

-Mark.

[vdomos]

Another note, I tested on two different PCs running Debian Squeeze, with the same problem.

Dan

[beanz]

Dan,

Just to rule out an obvious change between 0.11 and 0.12, can you try 0.12 with Device::RFXCom::RX with the change in:

beanz/device-rfxcom-perl@819698c

Regards,
Mark

[vdomos]

I modified the file /usr/share/perl5/Device/RFXCOM/RX.pm, it that does not seem to be the same as your ( only for comments)
and the file 01-rx.t does not exist.

Here are the changes made ​​in RX.pm:

*** /usr/share/perl5/Device/RFXCOM/RX.pm.origine 2011-03-21 21:06:12.000000000 +0100
--- /usr/share/perl5/Device/RFXCOM/RX.pm 2011-12-24 15:05:09.000000000 +0100

---

*** 31,38 ****
sub init {
my ($self, $cb) = @;
$self->_write(hex => 'F020', desc => 'version check');
! $self->_write(hex => 'F041', desc => 'variable length with visonic');
! $self->_write(hex => 'F02A', desc => 'enable all possible receiving modes',
callback => $cb || $self->{init_callback});
$self->{init} = 1;
}
--- 31,38 ----
sub init {
my ($self, $cb) = @;
$self->_write(hex => 'F020', desc => 'version check');
! $self->_write(hex => 'F02A', desc => 'enable all possible receiving modes');
! $self->_write(hex => 'F041', desc => 'variable length with visonic',
callback => $cb || $self->{init_callback});
$self->{init} = 1;
}

Unfortunately the problem remains the same:

dan@hestia:~$ /usr/bin/xpl-rfxcom-rx --verbose --rfxcom-rx-verbose --interface eth0 --rfxcom-rx-baud 4800 --rfxcom-rx-tty /dev/rfxcom
Listening on 192.168.0.28:55583
Sending on 192.168.0.255
Processed: master version 4d.2b
Processed: master mode 41.
Processed: master mode 41.
Processed: master oregon 44.ea4c10ec7128b0b417:
sensor/thn132n.ec[temp]=28.7
sensor/thn132n.ec[battery]=90%
thn132n.ec/temp/28.7
thn132n.ec/battery/90/%
Processed: master oregon 44.ea4c10ec7128b0b417(dup):
sensor/thn132n.ec[temp]=28.7
sensor/thn132n.ec[battery]=90%
Processed: master unknown 2d.20d635226044
Processed: master unknown 2d.20d635226044(dup)
Processed: master unknown 2d.40fc01216044
Processed: master unknown 2d.40fc01216044(dup)

Best regards,
Dan

[carbon15]

I've a similar problem myself, with v0.12 of rfxcom-rx, with Oregon some THN132ES sensors. My OWL119 works perfectly but for some reason the two Oregon sensor have stopped. Have there been any more thoughts on this one?

Thanks, Tim

[beanz]

Thanks for the additional information. I can get hold of an THN132ES in a few days. So hopefully I'll be able to reproduce the problem and get to the bottom of this now.

[carbon15]

Give me a shout if you need any more info.

[sparofr]

I have got exactly the same issues !!!!
So i use some sensor (X10, Oregon, OWL, ...) with an home made python script, i have decide to move to xPL-PERL on my brand new RaspberryPI.
Everything works (so i means all my sensors and remote controller) but one off my sensors (Oregon THGR228N) do not work, with the DEBUG mode (i have found it in the code) i realize the lake of one octet in the buffer (always the second octet just for this sensor 0x1a)

I take a look on the net and i found in this thread that it should be an os failure, so i decide to retry my homemade code and ...... my python script see this laking second octet !!!!
So i roll back to xPL-PERL and now the laking sensor work ....
If a reboot the serial link, i got the same issue.... i always have to initialize the link with my python script just by doing :
ser = serial.Serial('/dev/ttyUSB0', 4800, timeout=0.25)

I try on a standard PC with standard debian and i got the same issue ... i'm not a perl specialist and i have't be able to localize the mistake in the code but i think there is an ttyUSB initialization problem

[Clement87]

Hi, I have the same issue since upgrading.
Any news?