merbanan
Support for ThermoPro TX-7B sensor
Hello!
I recently bought 3 of these ThermoPro TX-7B outdoor sensors in use with a TP260B. I would love to get these onto my Home Assistant.
Attached the capture samples for a 35 second period, so it should have caught all 3 sensors.
The temps were around this at time of capture: Ch1: 88.9F 10% RH Ch2: 91.2F 10% RH Ch3: 88.2F 12% RH
I used this command to capture: rtl_433 -f 915M -s 1000k -S unknown -T 35
Version: 25.02 branch at 202502191252 Using device 0: Nooelec, NESDR SMArt v5, SN: XXXXX, "Generic RTL2832U OEM"
Thanks for any help!
@akaSurreal ,
Only the g004 contains useful data.
To get sample, please remove antenna, put the sensor around 50 cm from RTL device, and check the cu8 into pdv https://triq.org/pdv/ , keep only signals with some green/yellow information, with orange/white it's too strong, clipping, with blue not enough, too low.
From g004 file, we have classic thermopro data layout and preamble/sync word (very similar to tp82xb)
rtl_433 -X "n=tx7b,m=FSK_PCM,s=104,l=104,r=1000" -Y minmax -Y filter=100 g004_915M_1000k.cu8 2>&1 | grep codes
codes : {212}eaaaaaaaaaaaaaad2552dd425202ca00daa55aabbd2d2d2d2d200
After preamble/sync word 0xd2552dd4 we have:
rtl_433 -X "n=tx7b,m=FSK_PCM,s=104,l=104,r=1000,preamble=d2552dd4"
{120}25202ca00daa55aabbd2d2d2d2d200
Possible Data Layout
Byte Position 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Sample 25 20 2c a0 0d aa 55 aa bb d2 d2 d2 d2 d2 00
II UF ?? ?? ?? ?? ?? ?? CC TT TT TT TT TT TT
Where II = ID U = Display Unit, 0x2 = F, 0x0 = C F = Flags ? ?? to guess with Temp and Humidity --> Need more sample using the flex command. CC = Checksum/CRC ? TT = Trailing bits
Only my guess, compared with other ThermoPro sensors.
@akaSurreal . Some information from the user guide, I saw that on the remote sensor you can select one from 3 channels, channel must be different if more than one remote sensor is used. The station can also display low battery of the remote sensor, all these information are transmit and need some tests to get the data, this will help to find the correct data layout.
There is the "Reset" mode to force the pairing, this should also trigger a flag into the data, that would be nice to get. TX button could also trigger another flag to capture as well
About the temp and hum, we can see that the temp is shown with one decimal, and humidity is whole number. We may expect the temp is offset / scale as usual and humidity is same a raw hexa value.
From you sample:
- 0x2ca = 714, offset 400 and scale 10 = 31,4 °C = 88.52 °F , could match your value
- 0x00c = 13, could match a 13% of humidity ?
Just need some tests and codes from you, please.
rtl_433 -f 915M -X "n=tx7b,m=FSK_PCM,s=104,l=104,r=1000,preamble=d2552dd4"
For each code, please share the situation (temp, hum, button pres, channel, battery level ....)
Took the antenna off to try to isolate the channels
These should be from Channel 1: 75.0F 35% RH (from indoor display, should be close)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-23 14:16:35
model : tx7b count : 1 num_rows : 1 rows :
len : 123 data : 2520139015d52ad56e6969696974800
codes : {123}2520139015d52ad56e6969696974800
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-23 14:16:55
model : tx7b count : 1 num_rows : 1 rows :
len : 14 data : e800
codes : {14}e800
These should be from Channel 2: 75.9F 36% RH (from indoor display, should be close)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-23 14:22:37
model : tx7b count : 1 num_rows : 1 rows :
len : 126 data : fda80a08023d52ad54df4b4b4b4b4800
codes : {126}fda80a08023d52ad54df4b4b4b4b4800
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-23 14:22:45
model : tx7b count : 1 num_rows : 1 rows :
len : 15 data : f400
codes : {15}f400
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-23 14:23:35
model : tx7b count : 1 num_rows : 1 rows :
len : 15 data : f400
codes : {15}f400
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-23 14:24:01
model : tx7b count : 1 num_rows : 1 rows :
len : 124 data : fd880a12022aa6b5460d2d2d2d2d200
codes : {124}fd880a12022aa6b5460d2d2d2d2d200
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-23 14:24:25
model : tx7b count : 1 num_rows : 1 rows :
len : 15 data : f400
codes : {15}f400
I also have a channel 3 device, but its not easy to dismount at the moment, so I am hoping these help enough.
Occasionally I see these short ones, not sure if related but included above. I dont know how to check battery level but all of them should be pretty full right now.
@akaSurreal Thanks for the codes, as I suspected the signal is unstable, we have trouble with ThermoPro, it's probably using GFSK and rtl_433 is not working well with this modulation.
I tried to get the figures with bitbench, to shift the data, I guess that my assumption are correct around the Temp offset 400 and scale 10 and the humidity is = the raw value.
Can you please capture some other cu8 files like you did already, and also some codes. You can replay file and share only files and codes that are answering something.
rtl_433 -f 915M -X "n=tx7b,m=FSK_PCM,s=108,l=108,r=1000,preamble=d2552dd4,bits>=160" -Y minmax -S unknown
To replay, try with the file name at the end
rtl_433 -X "n=tx7b,m=FSK_PCM,s=108,l=108,r=1000,preamble=d2552dd4,bits>=160" -Y minmax g004_915M_1000k.cu8
I increase a little the pulse duration to 108 us (as your codes length is more than 120 bits), filter message if less than 160 bits (size of the message including preamble and sync word), and added the filter -Y minmax to increase the success.
All codes must finished by .....d2d2d2d2d200, if not it's because of bit shifted, try to reduce or increase the pulse by 1 us at a time. And should have a fixed value of aa55aa in the middle.
As the first bits are shifted, I can't conclude yet around the id / the channel position, for sure channel 1 and channel 2 is set at the beginning of the message. Need more cu8 files and codes.
And to try any battery flag, just put old batteries into the sensor and capture messages.
Thanks.
Thanks for your help! So here are the samples from the first command you gave me after running for ~45 seconds with my Ch1 sensor near with no antenna attached.
Temp reading is around 75.6F 33% RH
While it was running I also saw this once:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-27 12:24:59
model : tx7b count : 1 num_rows : 1 rows :
len : 122 data : fd880ad005ea956a89b4b4b4b4b4800
codes : {122}fd880ad005ea956a89b4b4b4b4b4800
I tried the replay command on each file and got nothing:
PS C:\Apps\rtl_433-win-x64-25.02> ./rtl_433 -X "n=tx7b,m=FSK_PCM,s=108,l=108,r=1000,preamble=d2552dd4,bits>=160" -Y minmax g001_915M_1000k.cu8
rtl_433 version 25.02 branch at 202502191252 inputs file rtl_tcp RTL-SDR SoapySDR
[Input] Test mode active. Reading samples from file: g001_915M_1000k.cu8
PS C:\Apps\rtl_433-win-x64-25.02> ./rtl_433 -X "n=tx7b,m=FSK_PCM,s=108,l=108,r=1000,preamble=d2552dd4,bits>=160" -Y minmax g002_915M_1000k.cu8
rtl_433 version 25.02 branch at 202502191252 inputs file rtl_tcp RTL-SDR SoapySDR
[Input] Test mode active. Reading samples from file: g002_915M_1000k.cu8
PS C:\Apps\rtl_433-win-x64-25.02> ./rtl_433 -X "n=tx7b,m=FSK_PCM,s=108,l=108,r=1000,preamble=d2552dd4,bits>=160" -Y minmax g003_915M_1000k.cu8
rtl_433 version 25.02 branch at 202502191252 inputs file rtl_tcp RTL-SDR SoapySDR
[Input] Test mode active. Reading samples from file: g003_915M_1000k.cu8
@akaSurreal Thanks for the samples, the first g001 is working and some progress from my side.
Byte Position 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
(phase 1) g004 25 20 2c a0 0d aa 55 aa bb d2 d2 d2 d2 d2 00
(phase 2) g001 e8 00 28 00 21 aa 55 aa e1 d2 d2 d2 d2 d2 00
II CF 11 12 22 aa 55 aa CC d2 d2 d2 d2 d2 00
Data layout:
- II:{8} Sensor ID , 0x25 or 0xe8
- C:{4} Channel ? -- 2 = Channel 3, sample g004 -- 0 = Channel 1, sample g001
- F:{4} Some flags, always zero, could be battery ?
- 111:{12} Temp °C , offset 400, scale 10 -- Sample g004 0x2ca = 714 --> -400 = 314 = 31.4 °C = 88.52 °F , close to temp Channel 3 88.2 F -- Sample g001 0x280 = 640 --> -400 = 240 = 24 °C = 75.2 °F, close to temp Channel 1 75.6 F
- 222:{12} Humidity, % -- Sample g004 0x00d = 13 % , close to Channel 3 and 12% -- Sample g001 0x021 = 33 %, match Channel 1, 33%.
- 0xaa55aa : Fixed value
- CC Checksum, 2 possibilities, but need much more samples to confirm the key -- Galois bit reflect and byte reflect, gen 0x98, key 0x25 or key 0xca
This was working for me on the first new g001 (notice r=1500 instead of r=1000, and without -Y minmax)
rtl_433 -X "n=tx7b,m=FSK_PCM,s=108,l=108,r=1500,preamble=d2552dd4,bits>=160" g001_915M_1000k.cu8
So you can try more samples, with:
rtl_433 -f 915M -X "n=tx7b,m=FSK_PCM,s=108,l=108,r=1500,preamble=d2552dd4,bits>=160" -S unknown
You need to let it run longer, around 10 minutes to get 10 samples, the sensor is sending one information every 50 seconds. So be patient to get responses and we will find the good data layout.
Here's 10 minutes of samples using your command. I don't know if its picking up my 2 other channels as I took the antenna off and have only Channel 1 near it. The other 2 channels are in my back yard so pretty far away at the moment. Let me know if you also want some with all 3 channels going.
Ch.1 temperature readings: Started at: 79.9F 21% RH Ended at: 75.7F 26% RH
@akaSurreal Thanks for the samples, we have at least 2 Sensors and now I can confirm the checksum is gen 0x98, key 0x25.
I'm drafting a new decoder for the tx-7b, I have enough information here to PR it later today or tomorrow.
May be, if you can play with older battery to get codes with the battery flag, would be nice, this data is missing into the data layout.
To increase the success, you can keep the antenna and put the sensor little further to avoid clipping. I don't need anymore cu8 files just codes. I saw that you are under Windows and Powershell so try:
./rtl_433 -f 915M -X "n=tx7b,m=FSK_PCM,s=108,l=108,r=1500,preamble=d2552dd4,bits>=160" 2>&1 | Where {$_ -match "d2d2d2" -and $_ -match "codes"}
Then share the codes with Temp / Hum values.
Thx.
@akaSurreal : I let you test my PR and let me know if ok for you ?
Decoder works with 8 of your cu8 samples,
Phase 1 & g004, channel 3
°C
°F with -C customary option
Phase 2 & g001, channel 1
Phase 3 & g006, g007, g009, g011, g014, g019
rtl_433 g*.cu8 -C customary -Y autolevel -Y minmax -Y filter=20 -M level
Channel 1 , ID 0xe8 is probably the sensor near you, and Channel 3, ID 0x25 is further, the signal is lower.
Works! Built this under WSL (Ubuntu) in Windows 11 and seems to be working perfectly for all 3 channels. Do you still need anything else to finalize this?
Oh and heres using your command line:
@akaSurreal very good. the last thing you can do is about the low battery information, one bit into the flags is probably the low battery indicator, play with old battery to test it, put the old battery into the fridge will reduce their performance before could help you. The best is using an adjustable DC power supply to get the exact moment when low battery is triggered.
If you can't test, let me know, I will merge the PR and any other contributor could check the battery later.
Gotcha. A few more notes for context:
I changed the batteries on my CH1 sensor to trigger the low battery indicator. After doing so, the sensor lost sync with the base unit and received a new ID. Also, it looks like every time I hit the reset button, the sensor gets assigned a new ID and needs to be re-synced.
When I press the TX button on the unit, it transmits immediately (instead of waiting for the normal interval), but the RTL_433 output shows it as Channel 13. This seems to be consistent, even after the ID changes:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 15:43:57
model : ThermoPro-TX7B id : d9
Channel : 13 Flags : 0000 Temperature: 81.0 F Humidity : 25 %
Integrity : CHECKSUM
Modulation: FSK Freq1 : 915.0 MHz Freq2 : 915.0 MHz
RSSI : 1.2 dB SNR : 24.8 dB Noise : -24.8 dB
I then re-synced the unit to the base on Channel 1. On the base unit, it shows as Channel 1, but in the RTL_433 output, it shows up as Channel 9 now:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 15:44:28
model : ThermoPro-TX7B id : d9
Channel : 9 Flags : 0000 Temperature: 81.3 F Humidity : 25 %
Integrity : CHECKSUM
Modulation: FSK Freq1 : 915.0 MHz Freq2 : 915.0 MHz
RSSI : 1.3 dB SNR : 33.7 dB Noise : -33.7 dB
At the time of the test below, the sensor on Channel 1 was reading around 79.9°F and 26% RH. RTL_433 is also picking up other channels during this period. The low battery indicator should be associated with the sensor identified above as Channel 1 (even though it appears as Channel 9 in the RTL output).
Here's a code from a manual TX press on the Channel 1 sensor:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 16:02:33
model : tx7b count : 1 num_rows : 1 rows :
len : 126 data : d9c014b806aa956ab0f4b4b4b4b48000
codes : {126}d9c014b806aa956ab0f4b4b4b4b48000
*** Saving signal to file g023_915M_1000k.cu8 (37527 samples, 131072 bytes)
And these are the codes I captured while letting it run for about 5 minutes:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 15:58:01
model : tx7b count : 1 num_rows : 1 rows :
len : 129 data : 2520151004aa956ab2b4b4b4b4b480000
codes : {129}2520151004aa956ab2b4b4b4b4b480000
*** Saving signal to file g004_915M_1000k.cu8 (57240 samples, 131072 bytes)
*** Saving signal to file g005_915M_1000k.cu8 (74278 samples, 262144 bytes)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 15:58:38
model : tx7b count : 1 num_rows : 1 rows :
len : 127 data : d98014d806aa956a90fa5a5a5a5a4000
codes : {127}d98014d806aa956a90fa5a5a5a5a4000
*** Saving signal to file g006_915M_1000k.cu8 (74271 samples, 262144 bytes)
*** Saving signal to file g007_915M_1000k.cu8 (34453 samples, 131072 bytes)
*** Saving signal to file g008_915M_1000k.cu8 (34098 samples, 131072 bytes)
*** Saving signal to file g009_915M_1000k.cu8 (44496 samples, 131072 bytes)
*** Saving signal to file g010_915M_1000k.cu8 (74261 samples, 262144 bytes)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 15:59:28
model : tx7b count : 1 num_rows : 1 rows :
len : 128 data : d98014e803554ab547fd2d2d2d2d2000
codes : {128}d98014e803554ab547fd2d2d2d2d2000
*** Saving signal to file g011_915M_1000k.cu8 (43837 samples, 131072 bytes)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 15:59:53
model : tx7b count : 1 num_rows : 1 rows :
len : 129 data : 2520151804ea956ab87a5a5a5a5a40000
codes : {129}2520151804ea956ab87a5a5a5a5a40000
*** Saving signal to file g012_915M_1000k.cu8 (35011 samples, 131072 bytes)
*** Saving signal to file g013_915M_1000k.cu8 (188482 samples, 393216 bytes)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 16:00:18
model : tx7b count : 1 num_rows : 1 rows :
len : 126 data : d98014c806aa956aaef4b4b4b4b48000
codes : {126}d98014c806aa956aaef4b4b4b4b48000
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 16:00:20
model : tx7b count : 1 num_rows : 1 rows :
len : 127 data : fd880ae4020acab5579a5a5a5a5a4000
codes : {127}fd880ae4020acab5579a5a5a5a5a4000
*** Saving signal to file g014_915M_1000k.cu8 (314743 samples, 655360 bytes)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 16:00:49
model : tx7b count : 1 num_rows : 1 rows :
len : 130 data : 2520151004ea956aa774b4b4b4b480000
codes : {130}2520151004ea956aa774b4b4b4b480000
*** Saving signal to file g015_915M_1000k.cu8 (47196 samples, 131072 bytes)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 16:01:08
model : tx7b count : 1 num_rows : 1 rows :
len : 125 data : d98029700d552ad518e9696969690000
codes : {125}d98029700d552ad518e9696969690000
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 16:01:13
model : tx7b count : 1 num_rows : 1 rows :
len : 127 data : fd880ae402154ab5579a5a5a5a5a4000
codes : {127}fd880ae402154ab5579a5a5a5a5a4000
*** Saving signal to file g016_915M_1000k.cu8 (188468 samples, 393216 bytes)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 16:01:45
model : tx7b count : 1 num_rows : 1 rows :
len : 127 data : 2520151804ea956ab87a5a5a5a5a4000
codes : {127}2520151804ea956ab87a5a5a5a5a4000
*** Saving signal to file g017_915M_1000k.cu8 (188482 samples, 393216 bytes)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 16:01:58
model : tx7b count : 1 num_rows : 1 rows :
len : 127 data : d98014b806aa956a8c7a5a5a5a5a4000
codes : {127}d98014b806aa956a8c7a5a5a5a5a4000
*** Saving signal to file g018_915M_1000k.cu8 (34471 samples, 131072 bytes)
*** Saving signal to file g019_915M_1000k.cu8 (74276 samples, 262144 bytes)
*** Saving signal to file g020_915M_1000k.cu8 (44303 samples, 131072 bytes)
*** Saving signal to file g021_915M_1000k.cu8 (42781 samples, 131072 bytes)
*** Saving signal to file g022_915M_1000k.cu8 (82213 samples, 262144 bytes)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 16:02:33
model : tx7b count : 1 num_rows : 1 rows :
len : 126 data : d9c014b806aa956ab0f4b4b4b4b48000
codes : {126}d9c014b806aa956ab0f4b4b4b4b48000
*** Saving signal to file g023_915M_1000k.cu8 (37527 samples, 131072 bytes)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-28 16:02:41
model : tx7b count : 1 num_rows : 1 rows :
len : 127 data : 12900a8c02754ab55c3a5a5a5a5a4000
codes : {127}12900a8c02754ab55c3a5a5a5a5a4000
And here are the raw samples just in case:
@akaSurreal Thanks, it helps.
Does the channel back to 1 after a while or still 9 from rtl_433 ?
The current data layout for the channel is based on 4 bit which is too much just for a max of 3 sensors. 2 bit are enough.
Then the 2 other can be used for the reset/pairing/sync and the TX button pressed.
Byte position 0 1 ...
Data hexa D 9 C 0 ... [TX pressed]
Data hexa D 9 8 0 ... [Reset pressed]
Data binary 1101 1001 1100 0000 ... TX
Data binary 1101 1001 1000 0000 ... Reset
Bit position 8765 4321 8765 4321 ...
Data IIII IIII BBCC FFFF
I for ID 0xd9 B8 for button RESET pressed and value probably kept few minutes to let the station be aware of the reset. B7 for button TX pressed, value shown one time. C6 C5 for channel (offset -1) F4321 for some flags, like low battery, here always 0x0
I'm not with my laptop, will check samples later.
Edit: in fact, the B8 is the low battery flag.
Byte position 0 1 ...
Data hexa D 9 C 0 ... [Low Battery + TX pressed, Channel 1]
Data hexa D 9 8 0 ... [Low Battery, Channel 1]
Data binary 1101 1001 1100 0000 ... Low Battery / TX / CH1
Data binary 1101 1001 1000 0000 ... Low Battery / CH1
Bit position 8765 4321 8765 4321 ...
Data IIII IIII BBCC FFFF
@akaSurreal : I just updated the code with your last findings, I updated also the digest part, thanks @zuckschwerdt for that part.
Please test and let us know, from my point view we are ready to merge the PR, nothing more to guess. Thanks for your contribution.
Awesome thanks!
Testing with new build this is what I am seeing:
Channel 1 normal interval: (And it does say Channel 1 now again?)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-30 11:42:22
model : ThermoPro-TX7B id : db
Battery : 1 Button : 0 Channel : 1 Flags : 0000
Temperature: 68.2 F Humidity : 56 % Integrity : CHECKSUM
Modulation: FSK Freq1 : 915.0 MHz Freq2 : 915.0 MHz
RSSI : 1.2 dB SNR : 23.8 dB Noise : -23.8 dB
Channel 1 when I press the TX button:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-30 11:42:22
model : ThermoPro-TX7B id : db
Battery : 1 Button : 1 Channel : 1 Flags : 0000
Temperature: 68.2 F Humidity : 56 % Integrity : CHECKSUM
Modulation: FSK Freq1 : 915.0 MHz Freq2 : 915.0 MHz
RSSI : 1.2 dB SNR : 23.5 dB Noise : -23.5 dB
When pressing Reset, I don't know if anything actually gets transmitted, but when I press TX again, its just on a new ID now. Which I think may be by design? It still says Channel 1 now though even after a reset which is good.
And here's after putting the low batteries back in:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-30 11:46:03
model : ThermoPro-TX7B id : f4
Battery : 0 Button : 0 Channel : 1 Flags : 0000
Temperature: 71.8 F Humidity : 61 % Integrity : CHECKSUM
Modulation: FSK Freq1 : 915.0 MHz Freq2 : 915.0 MHz
RSSI : 1.2 dB SNR : 24.9 dB Noise : -24.9 dB
So I think this is all working as intended now?
Edit: I didn't show here, but Channel 2 & 3 are working and reporting properly as well.
Edit2: Not sure if this is a concern but I let it run for awhile and it eventually quit after about 15 minutes with this error:
[Input] Async read stalled, exiting!
Edit3: Let it run again, this time took about 45 minutes before exiting with that same error.
@akaSurreal : Hi, good feedback !
Your errors are linked to the RTL USB dongle. If you are using the WSL and USBIPD to attach the USB device to UBUNTU, you may be impacted by Windows when going into Standby after a while for example and you resume your session, then the USB connection may be lost and rtl_433 hang.
Depends also of your connection between the RTL USB with a usb cable or directly plugged to your computer.
It's easy to reproduce, restart the rtl_433 , then when it's starting to give you some answer, unplug the dongle, and you will see the same error, something like that:
I see.. yes I am using USBIPD to attach. I do have my computer set to never sleep though. It is also using a USB cable and not directly attached.
Is this anything to be concerned about? Once I move this to my Home Assistant server (Windows Hyper-V VM), not sure if this will have the same issues or will it auto-restart if it exits anyways?
Edit: BTW, I just noticed I got this when I let it run for 45 minutes yesterday. Its not mine (neighbor?), but the temperatures seem odd:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-06-30 13:10:35
model : ThermoPro-TP829b id : 0a
Display Unit: Celsius Temperature 1: 52.9 F Temperature 2: -48.5 F Temperature 3: 432.5 F
Temperature 4: 203.0 F Flags : 0 Integrity : CHECKSUM
Modulation: FSK Freq1 : 915.0 MHz Freq2 : 915.0 MHz
RSSI : 1.1 dB SNR : 24.2 dB Noise : -24.2 dB
Edit: BTW, I just noticed I got this when I let it run for 45 minutes yesterday. Its not mine (neighbor?), but the temperatures seem odd:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ time : 2025-06-30 13:10:35 model : ThermoPro-TP829b id : 0a Display Unit: Celsius Temperature 1: 52.9 F Temperature 2: -48.5 F Temperature 3: 432.5 F Temperature 4: 203.0 F Flags : 0 Integrity : CHECKSUM Modulation: FSK Freq1 : 915.0 MHz Freq2 : 915.0 MHz RSSI : 1.1 dB SNR : 24.2 dB Noise : -24.2 dB
That's what I was worried about conflict between the TX7B and the TB829B Both are based on the same modulation, pulse width, message length, ...long story short they differ only at Checksum level.
TB829B and TX7B Data layout:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
II UF 11 12 22 33 34 44 CC TT TT TT TT TT
II BF 11 12 22 aa 55 aa CC TT TT TT TT TT
Data Layout:
- I: ID = 0x0a
- U: Display Unit °F / °C (°C because 0x0), for TB829B or B: Low Battery/TX pressed/Channel for TX7B
- F: Unknown Flags, but here = 0x0
- 111: Temperature °C, offset 500, scale 10 for TB829B, offset 400, scale 10 for TX7B
- 222: Temperature °C, second prob, offset 500, scale 10 for TB829B, or Humidity % for TX7B
- 333: Temp probe 3, TB829B
- 444: Temp probe 4, TB829B
- 55AA55: Fixed value for TX7B
- CC: Checksum, lfsr_digest8_reverse(b, 8, 0x98, 0x55) for TB829B, or lfsr_digest8_reverse(b, 8, 0x98, 0x25) for TX7B
- TT: Trailing bytes, always D2 D2 D2 D2 D2 00, both sensor.
If we try to reverse your TB829B message we have:
| °F | °C | RAW Decimal | RAW Hexa | |
|---|---|---|---|---|
| Temp probe 1 | 52.9 | 11.6 | 616 | 268 |
| Temp probe 2 | -48.5 | -44.7 | 53 | 035 |
| Temp probe 3 | 432.5 | 222.5 | 2725 | AA5 |
| Temp probe 4 | 203 | 95.0 | 1450 | 5AA |
So the data layout looks like this:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
II UF 11 12 22 33 34 44 CC TT TT TT TT TT
0a 00 26 80 35 aa 55 aa ?? ?? ?? ?? ?? ??
It's clearly a TX7B message with the aa 55 aa fixed value in the middle.
Using the checksum formula gives a bad 0x00, bad because such result will work for both sensors, this is an exception and the limit of such checksum, the reason why both sensors are decoded.
If you retry the original message, you have 2 answers, one for each sensor model:
rtl_433 -y aaaad2552dd40a00268035aa55aa00d2d2d2d2d200 -C customary
You probably had both also, and your id is 0x0a (10)
Based on that finding, we may be able to add another control, to filter values and show only values for TX7B.
@zuckschwerdt what can we do here ? In the real life, I'm pretty sure that the TB829b station will be fooled and will show the bad temp values. Is it at rtl_433 to check that ? Or as usual, only transmit information as is and the controls could be done outside/externally.
Correct, each time this has happened, I got both at the same time:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-07-01 13:30:02
model : ThermoPro-TP829b id : 25
Display Unit: Fahrenheit Temperature 1: 59.4 F Temperature 2: -52.1 F Temperature 3: 432.5 F
Temperature 4: 203.0 F Flags : 0 Integrity : CHECKSUM
Modulation: FSK Freq1 : 915.0 MHz Freq2 : 915.0 MHz
RSSI : -1.6 dB SNR : 21.2 dB Noise : -22.9 dB
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2025-07-01 13:30:02
model : ThermoPro-TX7B id : 25
Battery : 1 Button : 0 Channel : 3 Flags : 0000
Temperature: 77.4 F Humidity : 33 % Integrity : CHECKSUM
Modulation: FSK Freq1 : 915.0 MHz Freq2 : 915.0 MHz
RSSI : -1.6 dB SNR : 21.2 dB Noise : -22.9 dB
Running this for hours, it only happened 3 times though, so maybe this isn't a big problem?
Is this anything to be concerned about? Once I move this to my Home Assistant server (Windows Hyper-V VM), not sure if this will have the same issues or will it auto-restart if it exits anyways?
I guess no, as the WSL is not a real VM, if you close all your sessions the Linux will stop few minutes after last session is closed, so you need to keep open one session for ever. I'm using also WSL and I'm facing some memory issue time to time and also CPU going to 100 % used and the session is no more responding, I need to run wsl --shutdown to stop it.
HA and Windows Hyper-V VM is not the same as WSL so, it will probably work, I don't have experience on Hyper-V but if I'm not wrong the VM is using the host usb device directly, must be offline in disk manager at MS Windows Host level before the VM can use it.
USBIPD for WSL is using/adding a network layer to attach the host usb device to Linux. When rtl_433 is used, go to the task manager of Windows, go to performance page and you will see the vEthernet (WSL) card and lot of traffic here, this is the rtl_433 traffic between Linux and USB, and it's directly related with the sample rate.
With default sample rate at 250Kps, you have around 2 to 4 Mbs used, with -s 1024k, it's going to 16 Mbs, with -s 2048k, then up to 33 Mbs.
So here, may be also something to deep dive, but my advice is to test on Hyper-V, and avoid waste of time on WSL which is only for testing, from my point of view, up to you.
Correct, each time this has happened, I got both at the same time:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ time : 2025-07-01 13:30:02 model : ThermoPro-TP829b id : 25 Display Unit: Fahrenheit Temperature 1: 59.4 F Temperature 2: -52.1 F Temperature 3: 432.5 F Temperature 4: 203.0 F Flags : 0 Integrity : CHECKSUM Modulation: FSK Freq1 : 915.0 MHz Freq2 : 915.0 MHz RSSI : -1.6 dB SNR : 21.2 dB Noise : -22.9 dB _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ time : 2025-07-01 13:30:02 model : ThermoPro-TX7B id : 25 Battery : 1 Button : 0 Channel : 3 Flags : 0000 Temperature: 77.4 F Humidity : 33 % Integrity : CHECKSUM Modulation: FSK Freq1 : 915.0 MHz Freq2 : 915.0 MHz RSSI : -1.6 dB SNR : 21.2 dB Noise : -22.9 dBRunning this for hours, it only happened 3 times though, so maybe this isn't a big problem?
Now that we know why, yes, we can add a simple control into the TB829B decoder to exclude such result, and -52.1 F is probably not expected for BBQ. 😄
In the real life, I'm pretty sure that the TB829b station will be fooled and will show the bad temp values. Is it at rtl_433 to check that ? Or as usual, only transmit information as is and the controls could be done outside/externally.
If there is a known collision value like 55aa55 for temp then we can add a check for that. But otherwise we can't really do anything else for these rare (1/256) bad messages.
So what's the process from here to getting a build I can use with HA?
@akaSurreal , I need to commit a last update for tb829b to exclude the tx7b false positive value and I will merge to the master branch. Then into your HA VM you have to get/ install this last version like you did in Ubuntu to test it. I will commit tomorrow probably.
I'll also tag a nightly version after this and then the -next version of the HA plugin should have this change.
@zuckschwerdt , @akaSurreal I did it, the TX-7B now merged into rtl_433 master branch. Thanks for your contribution.
Got it working! currently using MQTT to publish from my Windows side
Thanks so much for all your help guys!!