-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong temperature on negative values for Klimalogg Pro sensor #2967
Comments
Taking your initial packet of Klimalogg is protocol 150 and we can switch that to verbose (to see the raw code) and feed the test data with:
Try to log those codes when you see strange values. To help with gain issues it's recommended to try: |
Do your 30.3181.IT's always report |
@Rob-2 : Can you check if you have the last version of rtl_433 as it seems to work at @zuckschwerdt level ? |
Hello Christian, hello Bruno, thank you very much for your respone. Bruno, you were spot on, I also noticed that the commands from Christian (thanks for the example. :) ) were somewhat unknown. And then the signal decoded fine. Sorry, that I didn't thought about the version. So the issue can be closed. I'll try the suggested gain settings, as soon as I find some time. @zuckschwerdt Yes, the 30.3181.IT always report 6a for the humidity. However, there's a catch. When a 30.3180.IT's humidity goes into saturation (>99%), it also reports 6a (106), not 100 as one might have assumed. So there's the question how to handle hum=6a. It could be a saturated, humidity=100% 30.3180.IT sensor OR it could be a 30.3180.IT sensor. tfrec's code sets humidity output value to 0 if it see's hum=6a. However, that was annoying, because in grafana my humidity value then jumped between 99% and 0%, and not between 99% and 100%. I solved this in my personal tfrec compile by an addition "if" check agains my personal used sensor id's. And if it's an id of a 30.3180.IT, it outputs 100% if it decodes 6a. But that's not a general solution because one would need to have the IDs o the 30.3180.IT's. I checked the left over / unknown bits output of the raw output of my sensors, but I didn't find an indicator to 100% reliably distinguish between a 30.3180.IT and a 30.3181.IT (because hum=6a is not enough). I was curious what the Klimalogg display unit shows on a 100% saturated 30.3180.IT and checked the history. It then displays "-" for humidity (not 100%). It also shows "-" for 30.3181.ITs. So yeah, I don't know whats the best way to handle 6a. Skipping humidity output on 6a would be fine for 30.3181.ITs, but if you have a 30.3180.IT in the winter, it could be that it would jump between 0x64 (99%) and 0x6a (>99%). A little bit annoying. So thank you again for your help and sorry that I claimed your time. If you need samples recordings of the Klimalogg sensors for whatever resons, feel free to ping me. Have a good amount in use. :) BR |
Thanks for the very detailed analysis and writeup on humidity oddities. I guess we should just document the behaviour and not suppress the 6a value then. I'll close this upon adding those notes. |
If you want to have a look at the different sensor raw output, I've just recorded a ~20s sample with tfrec and directly after a ~20s sample with rtl_433. ./tfrec -g -1 -t 450 -f 868325 -T 1 -e "publish-tfrec-to-mqtt.sh" -D rtl_433 -R 150:v -f 868M -s 2000k -H 30 -M highres -M level |
One could think about reporting 0x6a as humidity=100%... And 30.3181.IT sensor would then always report 100%. Maybe a small enhancement to the 106% reported as it is now. |
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:
#30 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.
The text was updated successfully, but these errors were encountered: