rtl_433
rtl_433 copied to clipboard
multiple LaCrosse protocols responding to same packet
I use a LaCrosse TX37U-IT Wireless Temperature Sensor (915Mhz) and have noticed I am getting multiple devices (decoders) reporting for the same packet
I've attaches a sample to test and reproduce the issue
[75] LaCrosse TX35DTH-IT, TFA Dostmann 30.3155 Temperature/Humidity sensor
[76] LaCrosse TX29IT Temperature sensor
rtl_433 -s 1024k -R 76 -R 75 -f 915M -Y classic -r g002_915M_1024k.cu8 -F json
{"time" : "@0.043352s", "brand" : "LaCrosse", "model" : "LaCrosse-TX29IT", "id" : 8, "battery_ok" : 1, "newbattery" : 0, "temperature_C" : 20.400, "mic" : "CRC"}
{"time" : "@0.043352s", "brand" : "LaCrosse", "model" : "LaCrosse-TX35DTHIT", "id" : 8, "battery_ok" : 1, "newbattery" : 0, "temperature_C" : 20.400, "mic" : "CRC"}
Hardware : WS-8117U-IT-AL. (https://www.lacrossetechnology.com/ws-8117u-it-al-atomic-wall-clock) Sensor TX37U-IT (https://www.lacrossetechnology.com/tx37u-it)
Ok, each decoder is generating a bitbuffer based in the decoder parameters. Then it seems all bitbuffers are tested against all decoders and not just the one with the matching decoded parameters. Not sure how to handle this.
and merge lacrosse.c into lacrosse_tx35.c. :-)
They are both tagged with the protocol: https://github.com/merbanan/rtl_433/blob/master/src/devices/lacrosse_tx35.c#L150 and https://github.com/merbanan/rtl_433/blob/master/src/devices/lacrosse_tx35.c#L158 not sure what's wrong here. I'll take a look later.
Oh, I know. This is 58 µs PCM and the target are 55 or 105. Both are in range for the (newish) automatic PCM bit-width adjustment :) Tuning the .tolerance
down could work
https://github.com/merbanan/rtl_433/blob/master/src/pulse_demod.c#L66
Maybe you should just not differentiate between the two since the TX29IT, TX35DTHIT and TX37U-IT are simular enough.
Else i suppose you can attach metadata to the bitbuffer with the modulation and pulse width to id the signal ( and freq differentiate between the TX29IT at 868MHz width 55 and the TX37U-IT at 915M width 55 )
Minor observation: the TX37U-IT FCC ID is OMO-TX29U thus can simply be added to the TX29IT code branch. If the frequency is available that can differentiate between between the two when receive live data.
Here is info with a photo of the device label (and yes I submitted a pull request for rtl_433_tests with the data )
https://github.com/evilpete/rtl_433_tests/tree/tx37u-it/tests/lacrosse/tx37u-it
Also given the 58 µs vs. 55 µs difference, that can be from manufacturing / thermal drift. ( I'll take a few samples at a higher rate with my hackrf over a 80 degree thermal range if it wiill help)
no thermal drift found in a 102 degree delta
I just discovered the same issue with R1/R3, TH3 and BREEZEPRO decoders. I have a BREEZEPRO device with ID 682330. Until today I had no issue because I was using -R 0 and -R 166 to select one decoder. But today, I received my R3 rain gauge with ID 7405453 and after setting up without -R device selectors I receive the follow output:
{"time" : "2021-08-24 23:53:35", "model" : "LaCrosse-BreezePro", "id" : 682330, "seq" : 6, "flags" : 0, "temperature_F" : 76.820, "humidity" : 67, "wind_avg_mi_h" : 0.000, "wind_dir_deg" : 297, "mic" : "CRC", "mod" : "FSK", "freq1" : 914.948, "freq2" : 915.037, "rssi" : -0.123, "snr" : 36.000, "noise" : -36.124} {"time" : "2021-08-24 23:53:35", "model" : "LaCrosse-TH3", "id" : 682330, "seq" : 6, "flags" : 0, "temperature_F" : 76.820, "humidity" : 67, "mic" : "CRC", "mod" : "FSK", "freq1" : 914.948, "freq2" : 915.037, "rssi" : -0.123, "snr" : 36.000, "noise" : -36.124} {"time" : "2021-08-24 23:53:35", "model" : "LaCrosse-R3", "id" : 682330, "seq" : 6, "flags" : 0, "rain_in" : 26165.018, "rain2_in" : 2.923, "mic" : "CRC", "mod" : "FSK", "freq1" : 914.948, "freq2" : 915.037, "rssi" : -0.123, "snr" : 36.000, "noise" : -36.124} {"time" : "2021-08-24 23:54:06", "model" : "LaCrosse-BreezePro", "id" : 682330, "seq" : 7, "flags" : 0, "temperature_F" : 77.000, "humidity" : 66, "wind_avg_mi_h" : 0.000, "wind_dir_deg" : 293, "mic" : "CRC", "mod" : "FSK", "freq1" : 914.950, "freq2" : 915.037, "rssi" : -0.117, "snr" : 32.027, "noise" : -32.144} {"time" : "2021-08-24 23:54:06", "model" : "LaCrosse-TH3", "id" : 682330, "seq" : 7, "flags" : 0, "temperature_F" : 77.000, "humidity" : 66, "mic" : "CRC", "mod" : "FSK", "freq1" : 914.950, "freq2" : 915.037, "rssi" : -0.117, "snr" : 32.027, "noise" : -32.144} {"time" : "2021-08-24 23:54:06", "model" : "LaCrosse-R3", "id" : 682330, "seq" : 7, "flags" : 0, "rain_in" : 26205.322, "rain2_in" : 2.884, "mic" : "CRC", "mod" : "FSK", "freq1" : 914.950, "freq2" : 915.037, "rssi" : -0.117, "snr" : 32.027, "noise" : -32.144} {"time" : "2021-08-24 23:54:41", "model" : "LaCrosse-R3", "id" : 7405453, "seq" : 5, "flags" : 0, "rain_in" : 428.346, "rain2_in" : 428.346, "mic" : "CRC", "mod" : "FSK", "freq1" : 914.950, "freq2" : 915.034, "rssi" : -0.129, "snr" : 31.602, "noise" : -31.730}
If I use -R 0 -R 166 -R 175, I lose the TH3 detections but the R1/R3 decoder still thinks the BREEZEPRO packets are valid when in fact R1/R3 (and TH3 decoder) should have rejected the packet for length too long and CRC check fail. Somethings not right here.
Can you grab a sample (upload here as zip) that shows this behaviour on replay?
Here is a sample file from the BreezePro device. It tripped the breezepro, th3, and r3 decoders during capture but I couldn't get anything during playback. Perhaps you'll have better luck. breezepro.zip
Good capture, works. You need -s 1M
or -f 914.98M
on playback to set the sample rate.
As far as I can see the raw data and CRC is exactly the same for Breeze Pro and R3. No way to distinguish by data and checksum alone here. Additional trouble for the 11-byte packets is that 8-byte packets will clear the CRC if the padding is 0's For the TH3 the checksum is wrong, the condition is inverted, thus all packets match…
I've fixed the checksum for LaCrosse-TH3, but LaCrosse-TH3 and LaCrosse-R1 look the same if we just test the CRC. Also LaCrosse-BreezePro and LaCrosse-R3 look the same if we just test the CRC.
👀 Following this, as I also have the issue with the R3 and Breezepro co-reporting (as I have both actual devices, so am listening for both devices).
"rain_in" : 26205.322, "rain2_in" : 2.884,
The rain data is what I use to filter it out in my processing (rain 2 is LESS THAN rain 1), but I am admittedly worried about a future where the integer has to roll over because of too much rain (or resets for some reason, or who knows what else the actual board does). That is probably way too small of an edge case to worry about, but that's what I worry about, so.....
Throwing my hat into the ring for this as well. Running into the same issues as described by others above.
Status? Still an issue with git master?
Yes, this is still an issue.
Using rtl_433 version nightly-18-g02724080 branch master at 202309272030
Sep 27 15:45:39 piserve rtl_433[370]: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Sep 27 15:45:39 piserve rtl_433[370]: time : 2023-09-27 15:45:39
Sep 27 15:45:39 piserve rtl_433[370]: model : LaCrosse-BreezePro Sensor ID : 0a833b
Sep 27 15:45:39 piserve rtl_433[370]: Sequence : 3 unknown : 0 Temperature: 75.2 F Humidity : 58 % Wind speed: 5.5 mi/h Wind direction: 92 Integrity : CRC
Sep 27 15:45:39 piserve rtl_433[370]: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Sep 27 15:45:39 piserve rtl_433[370]: time : 2023-09-27 15:45:39
Sep 27 15:45:39 piserve rtl_433[370]: model : LaCrosse-R3
Sep 27 15:45:39 piserve rtl_433[370]: Sensor ID : 0a833b
Sep 27 15:45:39 piserve rtl_433[370]: Battery level: 1
Sep 27 15:45:39 piserve rtl_433[370]: Sequence : 3
Sep 27 15:45:39 piserve rtl_433[370]: Total Rain: 109757.84 in
Sep 27 15:45:39 piserve rtl_433[370]: Total Rain2: 37425.71 in
Sep 27 15:45:39 piserve rtl_433[370]: Integrity : CRC
Sep 27 15:47:13 piserve rtl_433[370]: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Sep 27 15:47:13 piserve rtl_433[370]: time : 2023-09-27 15:47:13
Sep 27 15:47:13 piserve rtl_433[370]: model : LaCrosse-BreezePro Sensor ID : 0a833b
Sep 27 15:47:13 piserve rtl_433[370]: Sequence : 6 unknown : 0 Temperature: 74.5 F Humidity : 56 % Wind speed: 6.3 mi/h Wind direction: 120 Integrity : CRC
Sep 27 15:47:13 piserve rtl_433[370]: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Sep 27 15:47:13 piserve rtl_433[370]: time : 2023-09-27 15:47:13
Sep 27 15:47:13 piserve rtl_433[370]: model : LaCrosse-R3
Sep 27 15:47:13 piserve rtl_433[370]: Sensor ID : 0a833b
Sep 27 15:47:13 piserve rtl_433[370]: Battery level: 1
Sep 27 15:47:13 piserve rtl_433[370]: Sequence : 6
Sep 27 15:47:13 piserve rtl_433[370]: Total Rain: 68472.86 in
Sep 27 15:47:13 piserve rtl_433[370]: Total Rain2: 130313.99 in
Sep 27 15:47:13 piserve rtl_433[370]: Integrity : CRC
Sep 27 15:47:45 piserve rtl_433[370]: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Sep 27 15:47:45 piserve rtl_433[370]: time : 2023-09-27 15:47:45
Sep 27 15:47:45 piserve rtl_433[370]: model : LaCrosse-BreezePro Sensor ID : 0a833b
Sep 27 15:47:45 piserve rtl_433[370]: Sequence : 7 unknown : 0 Temperature: 74.3 F Humidity : 56 % Wind speed: 7.3 mi/h Wind direction: 109 Integrity : CRC
Sep 27 15:47:45 piserve rtl_433[370]: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Sep 27 15:47:45 piserve rtl_433[370]: time : 2023-09-27 15:47:45
Sep 27 15:47:45 piserve rtl_433[370]: model : LaCrosse-R3
Sep 27 15:47:45 piserve rtl_433[370]: Sensor ID : 0a833b
Sep 27 15:47:45 piserve rtl_433[370]: Battery level: 1
Sep 27 15:47:45 piserve rtl_433[370]: Sequence : 7
Sep 27 15:47:45 piserve rtl_433[370]: Total Rain: 16869.81 in
Sep 27 15:47:45 piserve rtl_433[370]: Total Rain2: 130316.41 in
Sep 27 15:47:45 piserve rtl_433[370]: Integrity : CRC
Status? Still an issue with git master?
Yup..
What's the path forward? Feels like discussion of what to do that is not resolved.