ThermoPro TX2 Sensor: Almost a Prologue

[azuca]

Hi,

I have ThermoPro TX2 Temperature and Humidty sensor integrated with Home Assistant using rtl_433 and MQTT. This remote sensor came with my ThermoPro TP60S but it ships with various ThermoPro products

https://buythermopro.com/product/thermopro-tp-60-replacement-sensor/

rtl_433 identifies the TX2 as a Prologue-TH sensor and it correctly reports the temperature and humidity values. It has always reported the battery condition as "LOW" but I originally assumed this was due to the TX2 missing a battery monitor and ignored it.

However, the batteries are now getting low and I just notice that rtl_433 is now reporting that the battery is OK. I've concluded that the battery condition bit value must be inverted in the TX2 compared to the Prologue-TH.

I can hack this in Home Assistant to flip the "OK"/"LOW" battery values but I'd rather contribute a code fix to rtl_433 if possible. Would cloning the Prologue-TH code and fixing the battery indicator be the preferred solution here?

I'm also preparing samples for the rtl_433_tests repo.

Thanks

[Christian Z.]

The Prologue-type has no checksum and a very weak header (just 4 bits) to identify. We need samples to see if there is anything to distinguish your ThermoPro TX2 from other Prologue-type transmissions.

[azuca]

I have the TX2 samples ready to go but I'm unclear on how to contribute to the rtl_433_tests repo. Do you want me to open a new issue on the rtl_433 repo and then create a PR on the rtl_433_tests repo to contribution the samples?

I already submitted PR #344 on the rtl_433_tests to contribute missing scenarios for the x10_sec DS10A door sensor devices back on May 28th. I see it is still open so I assume I'm not following the process correctly. If you can clarify then I'll make the required changes.

Thanks

[azuca]

Here is the rtl_433 analysis of one of my samples (Temperature: 26.6; Humidity: 50; Channel: 1; Battery: OK):

Test mode active. Reading samples from file: tx2_ch_1_433.92M_250k.cu8

Detected OOK package    @0.111532s
Analyzing pulses...
Total count:  265,  width: 861.50 ms        (215376 S)
Pulse width distribution:
 [ 0] count:  265,  width:  540 us [536;556]    ( 135 S)
Gap width distribution:
 [ 0] count:   90,  width: 3832 us [3828;3880]    ( 958 S)
 [ 1] count:  168,  width: 1908 us [1908;1916]    ( 477 S)
 [ 2] count:    6,  width: 8636 us [8636;8640]    (2159 S)
Pulse period distribution:
 [ 0] count:   90,  width: 4376 us [4372;4420]    (1094 S)
 [ 1] count:  168,  width: 2448 us [2448;2456]    ( 612 S)
 [ 2] count:    6,  width: 9188 us [9188;9192]    (2297 S)
Level estimates [high, low]:  15955,      7
RSSI: -0.1 dB SNR: 33.6 dB Noise: -33.7 dB
Frequency offsets [F1, F2]:   19253,      0    (+73.4 kHz, +0.0 kHz)
Guessing modulation: Pulse Position Modulation with fixed pulse width
Attempting demodulation... short_width: 1908, long_width: 3832, reset_limit: 8644, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_PPM,s=1908,l=3832,g=3884,r=8644'
pulse_demod_ppm(): Analyzer Device
bitbuffer:: Number of rows: 7
[00] {37} 9c 90 10 a3 28 : 10011100 10010000 00010000 10100011 00101
[01] {37} 9c 90 10 a3 28 : 10011100 10010000 00010000 10100011 00101
[02] {37} 9c 90 10 a3 28 : 10011100 10010000 00010000 10100011 00101
[03] {37} 9c 90 10 a3 28 : 10011100 10010000 00010000 10100011 00101
[04] {37} 9c 90 10 a3 28 : 10011100 10010000 00010000 10100011 00101
[05] {37} 9c 90 10 a3 28 : 10011100 10010000 00010000 10100011 00101
[06] {36} 9c 90 10 a3 20 : 10011100 10010000 00010000 10100011 0010

Without analysis mode:

{"time" : "@0.111532s", "model" : "Prologue-TH", "subtype" : 9, "id" : 201, "channel" : 1, "battery_ok" : 0, "temperature_C" : 26.600, "button" : 0, "humidity" : 50}

[Christian Z.]

That exactly matches the Prologue protocol. I see no reasonable way to distinguish the TX2 :/

[azuca]

Thanks for confirming, Christian. It looks like I'm stuck with flipping the battery_ok value in Home Assistant. No big deal.

[Benjamin Larsson]

I think we would accept a manual override for that. We have it for another protocol.

MvH

Benjamin Larsson

[Christian Z.]

The overrides are rather obscure. We could add a disabled protocol copied from Prologue for the TX2. Then you need to disable Prologue and enable the TX2. But you can't have both types at the same time.

[azuca]

Either works for me. For now,  I can add an issue against the rtl_433 repo to capture this thread and submit a PR against rtl_433_tests with the TX2 samples. Is that ok?

Thanks

[Doug Weiss]

I would suggest adding a protocol....if for no other reason than to indicate that RTL-433 supports the thermapro TX2....and perhaps (likely) it supports more thermapro products.

[Christian Z.]

Done. PR: https://github.com/merbanan/rtl_433/pull/1450