What does rain_mm actually measure?

[LaMalditaG]

I have a WH65B weather station, and in the included screen shows 0.0 mm of rain (which is correct), however, rtl_433 says 1956.6 mm.
As far as I know, this mm usually represents liters. So am I understanding this incorrectly, or there is something wrong with my setup?
Example rtl_433 output:

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2025-10-20 13:23:49
model     : Fineoffset-WH65B                       
ID        : 134
Battery   : 1            
Temperature: 23.4 C       
Humidity  : 45 %          
Wind direction: 264       
Wind speed: 1.3 m/s       
Gust speed: 1.5 m/s       
Rainfall  : 1956.6 mm     
UV        : 1212          
UVI       : 3             
Light     : 45880.0 lux   
Integrity : CRC

[gdt]

Please put text data as text, not images. Images are not accessible to the visually impaired, and image instead of text serves no useful purpose. Also, the image didn't work in the email notification, as my email client quite properly doesn't fetch random links in incoming email (and nobody's should do that).

This is question, not a bug report, so moving to discussion.

[LaMalditaG]

Okay, I fixed the post. My email client doesn't fetch links automatically either, I was just thinking about the GitHub client, my bad. Next time I'll try to use text.

[zuckschwerdt]

The rain_mm output is the absoulte amount of rain since the device was initialized (or the value rolled over).

You need to derive per-interval values yourself, e.g. capture the value each hour (or day...) and then present the difference as per hour (per day...) value.

[LaMalditaG]

That makes a lot of sense. Thank you.

[gdt]

@LaMalditaG If the source code doesn't have a comment that explains this, please submit a PR to add the briefest text that would have resolved your misunderstanding.

[LaMalditaG]

I suppose this is a common characteristic of Fineoffset devices. If that's the case, should the comment be added to every device or in the header of the fineoffset.c file?

[zuckschwerdt]

It would be interesting to hear where you looked or tried to look for this info. Are there obvious places besides the decoder source file?

I guess you didn't see https://triq.org/rtl_433/DATA_FORMAT.html#sensor-data (also there is not enough text there) -- would a link to that page in the README have helped?

[LaMalditaG]

Huh, it was always in front of my face. Well, I have two theories: maybe after reading the Readme too fast, I ignored the link to the docs because the domain name didn't actually catch my eye (that's on me). But also, it seems that I can't access the documentation while using a VPN, maybe I tried before and thought that the page was dead or something, but I should have tried to disconnect the VPN for a second... so that's on me too.
I also thought that this was a WH65B issue at first so all my internet searches were focused on the wrong thing.

[zuckschwerdt]

That's not on you, this question has been asked a dozend times. The info is not in the right place to be noticed. Maybe something like "For a description of fields, values, and units see ..." below the list of protocols?

Also we should try to move triq.org to some public hoster that does not care about abuse. The current host seems to mostly block certain countries (RU an BR currently), Hyperscalers (AWS), and VPNs as there is always someone running scans or trying exploits which trigger blocking.

[LaMalditaG]

Well, the thing is that the readme it's probably too big. Listing all the protocols causes that people will skip a big chunk of the readme.