zuckschwerdt
commented
5 months ago Taking your initial packet of 2d d4 21 5c 83 88 6a 60 00 56 58 and reflecting the bytes back (I use just ^8h in BitBench) we get b42b843ac1115606006a1a.
Klimalogg is protocol 150 and we can switch that to verbose (to see the raw code) and feed the test data with:
rtl_433 -R 150:v -y b42b843ac1115606006a1a
I see the expected output:
model : Klimalogg-Pro Id : 215c
Battery : 1 Temperature: -1.2 C Humidity : 106 Sequence Number: 0 Integrity : CRC
codes : {88}b42b843ac1115606006a1aTry to log those codes when you see strange values.
To help with gain issues it's recommended to try: -Y autolevel -Y magest -M level -M noise
ProfBoc75
Rob-2
Hello, thank you for all the great work!
I am using a TFA Klimalogg Pro and have roughly 15 sensors in use. Some 30.3180.IT (temp+hum) and some 30.3181.IT (temp with wire sensor, no humidity). I'm using a RTLSDR since ~3 years with the TFREC project.
However, I would like to switch to rtl_433, because I would like to add a ecowitt weather station and I am hoping, that rel_433 can receive both, the TFA sensors and the Ecowitt in future, so that I don't need to maintain two SDRs.
I've set up rtl_433 and it works very good so far. One strange thing I've noticed.
I have one 30.3181.IT which I am using as binary sensor, so this sensor sends -1.2°C in 99% of the time. This works fine. The sensor shows -1.2°C, tfrec receives -1.2°C: #030 1718215951 2d d4 21 5c 83 88 6a 60 00 56 58 TFA1 ID 215c -1.2 0% seq 0 lowbat 0 RSSI 80 EXEC publish-tfrec-to-mqtt.sh 215c -1.2 0 0 0 80 0 1718215951
However, rtl_433 decodes this into -2.8°C time : 2024-06-12 20:11:59 model : Klimalogg Pro Id : 215c Battery : 1 Temperature: -2.8 C Humidity : 106 Sequence Number: 0 Integrity : CRC Modulation: ASK Freq : 868.4 MHz RSSI : -0.4 dB SNR : 31.3 dB Noise : -31.7 dB
Now I wonder why the 2 libs decode this differently while still reporting CRC OK. Is it because it's an 30.3181.IT without humidity? Is there an option to see the decoded output as hex as on the tfrec example?
According to the tfrec source the telegram format is: // 0x2d 0xd4 ID ID sT TT HH BB SS 0x56 CC // 2d d4: Sync bytes // ID(14:0): 15 bit ID of sensor (printed on the back and displayed after powerup) // ID(15) is either 1 or 0 (fixed, depends on the sensor) // s(3:0): Learning sequence 0...f, after learning fixed 8 // TTT: Temperatur in BCD in .1degC steps, offset +40degC (-> -40...+60) // HH(6:0): rel. Humidity in % (binary coded, no BCD!) // BB(7): Low battery if =1 // BB(6:4): 110 or 111 (for 3199) // SS(7:4): sequence number (0...f) // SS(3:0): 0000 (fixed) // 56: Type? // CC: CRC8 from ID to 0x56 (polynome x^8 + x^5 + x^4 + 1)
Splitting the tfrec received telegram (2d d4 21 5c 83 88 6a 60 00 56 58): ID: 2d d4 21 5c s: 8 TTT: 3 88 (in BCD!) HH: 6a (binary coded, not BCD) BB: 60 SS: 00 56: 56 CC: 58
So temp is 38.8°C - 40°C Offset, so -1.2°C.
Now rtl_433 decodes this obviously to -2.8°C, plus 40°C offset, so I assume the rtl_433 decoded raw value for temp was 3 72.
The next 2 bytes are humidity, the 30.3181.IT doesn't have humidity, it usually sends 0x6a as seen above. rtl433 reads this 0x6a as 106, which is fine/correct. So the bit's are not shifted.
Do you have any idea why this is decoded differenly (wrong) in rtl_433?
BR Rob
PS: Just a note: One challenge I still have is the same as with tfrec... I need set gain to auto to receive the far away sensors, but with this setting very close sensor come in to strong and can't be decoded. When I cover the close sensors to lower the signal strength, they are also received fine. I read someone here was confused, that he only could receive 3 out of 5 sensors and I wanted so say, with these sensors and RTL, it might be that they are to close and/or the gain is set to high. But I need the high gain to receive the very far out sensors.