merbanan
Add support for RainPoint - High Precision Rain Sensor Model HCS012ARF
Good Day,
I am new to this and was wondering if someone could please assist me in extracting the rainfall data from the below device.
All i have done is run rtl_433 -A and i get the below dump. Please let me know what else i need to execute to get more details.
bartoszs-Mac-mini:~ bartosz$ rtl_433 -A rtl_433 version 25.02 (2025-02-19) inputs file rtl_tcp RTL-SDR with TLS Found Rafael Micro R820T tuner [SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM" Exact sample rate is: 250000.000414 Hz [R82XX] PLL not locked! Detected OOK package 2025-03-03 17:22:26 Analyzing pulses... Total count: 659, width: 499.00 ms (124750 S) Pulse width distribution: [ 0] count: 509, width: 320 us [312;336] ( 80 S) [ 1] count: 150, width: 624 us [616;636] ( 156 S) Gap width distribution: [ 0] count: 150, width: 592 us [584;604] ( 148 S) [ 1] count: 499, width: 284 us [280;300] ( 71 S) [ 2] count: 9, width: 900 us [900;904] ( 225 S) Pulse period distribution: [ 0] count: 100, width: 912 us [900;928] ( 228 S) [ 1] count: 109, width: 1220 us [1212;1228] ( 305 S) [ 2] count: 449, width: 608 us [596;624] ( 152 S) Pulse timing distribution: [ 0] count: 1008, width: 304 us [280;336] ( 76 S) [ 1] count: 300, width: 608 us [584;636] ( 152 S) [ 2] count: 9, width: 900 us [900;904] ( 225 S) [ 3] count: 1, width: 10004 us [10004;10004] (2501 S) Level estimates [high, low]: 15873, 3 RSSI: -0.1 dB SNR: 37.2 dB Noise: -37.4 dB Frequency offsets [F1, F2]: 943, 0 (+3.6 kHz, +0.0 kHz) Guessing modulation: Pulse Width Modulation with multiple packets view at https://triq.org/pdv/#AAB04C0409013002600384271481918091918080918080808080919191908180808080808080918080808080808080809081908180808080808080908180808080808080808080808091809190808255+AAB04B04010130026003842714819180919180809180808080809191919081808080808080809180808080808080808090819081808080808080809081808080808080808080808080918091908355 Attempting demodulation... short_width: 320, long_width: 624, reset_limit: 908, sync_width: 0 Use a flex decoder with -X 'n=name,m=OOK_PWM,s=320,l=624,r=908,g=608,t=122,y=0' [pulse_slicer_pwm] Analyzer Device codes : {66}a6f87fbfebfdfff4c, {66}a6f87fbfebfdfff4c, {66}a6f87fbfebfdfff4c, {66}a6f87fbfebfdfff4c, {66}a6f87fbfebfdfff4c, {66}a6f87fbfebfdfff4c, {66}a6f87fbfebfdfff4c, {66}a6f87fbfebfdfff4c, {66}a6f87fbfebfdfff4c, {65}a6f87fbfebfdfff48
I then ran the below command
rtl_433 -X 'n=RainpointSensor,m=OOK_PWM,s=320,l=624,r=908,g=608,t=122,y=0'
bartoszs-Mac-mini:~ bartosz$ rtl_433 -X 'n=RainpointSensor,m=OOK_PWM,s=320,l=624,r=908,g=608,t=122,y=0' rtl_433 version 25.02 (2025-02-19) inputs file rtl_tcp RTL-SDR with TLS Found Rafael Micro R820T tuner [SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM" Exact sample rate is: 250000.000414 Hz [R82XX] PLL not locked!
time : 2025-03-03 17:25:13 model : RainpointSensor count : 10 num_rows : 10 rows : len : 65 data : a6f87fbfebf7ffe18, len : 65 data : a6f87fbfebf7ffe18, len : 65 data : a6f87fbfebf7ffe18, len : 65 data : a6f87fbfebf7ffe18, len : 65 data : a6f87fbfebf7ffe18, len : 65 data : a6f87fbfebf7ffe18, len : 65 data : a6f87fbfebf7ffe18, len : 65 data : a6f87fbfebf7ffe18, len : 65 data : a6f87fbfebf7ffe18, len : 64 data : a6f87fbfebf7ffe1 codes : {65}a6f87fbfebf7ffe18, {65}a6f87fbfebf7ffe18, {65}a6f87fbfebf7ffe18, {65}a6f87fbfebf7ffe18, {65}a6f87fbfebf7ffe18, {65}a6f87fbfebf7ffe18, {65}a6f87fbfebf7ffe18, {65}a6f87fbfebf7ffe18, {65}a6f87fbfebf7ffe18, {64}a6f87fbfebf7ffe1
Thank you
Hi,
I have supplied some more info by removing batteries and then putting batteries back in and capturing the first code and then manually tipping the bucket and then capturing the code again once it gets sent. i did this 10 times. Hope this helps somehow
It seems to send 10 codes each time, 9 of which are the same but the 10th one is different. Below are the results.
Tipping code (duplicated 9 times),tip number, 10th code (could be battery or other info)
{67}a6f87fbdd7ffffef6 - 0 tip (On inserting batteries) , {66}a6f87fbdd7ffffef4 {67}a6f87fbfebf7ffef6 - 1 tip, {66}a6f87fbfebf7ffef4 {67}a6f87fbfebfbfffd6 - 2 tip, {66}a6f87fbfebfbfffd4 {66}a6f87fbfebf7ffeac - 3 tip, {65}a6f87fbfebf7ffea8 {66}a6f87fbfebfdfff2c - 4 tip, {65}a6f87fbfebfdfff28 {65}a6f87fbfebf3ffd58 - 5 tip, {64}a6f87fbfebf3ffd5 {67}a6f87fbfebfbfffb6 - 6 tip, {66}a6f87fbfebfbfffb4 {66}a6f87fbfebf7ffe6c - 7 tip, {65}a6f87fbfebf7ffe68 {67}a6f87fbfebfefff76 - 8 tip, {66}a6f87fbfebfefff74 {66}a6f87fbfebf5ffdec - 9 tip, {65}a6f87fbfebf5ffde8 {66}a6f87fbfebf9fffcc - 10 tip, {65}a6f87fbfebf9fffc8
Thank you
@zuckschwerdt
Hi. Just want to ask if i am posting the correct info here. Not sure if i am supposed to tag someone in order for someone to get notified to be able to assist me.
Thank you
@effort10 : this is the good place, he's may be busy like me nowadays.
Check here https://triq.org/rtl_433/ANALYZE.html to get how to proceed.
Can you record few files with rtl_433 -S unknown Drag n' drop cu8 files to check if good sample with pulseview https://triq.org/pdv/ And share the good files here to confirm the flex options Share also the values from the display station for each sample, it will help to get the figures.
Add some water , very slowly, until one toggle, and record values at the same time. Notice what change on the display.
Edit: you can play with bitbench to decode the signal and guess the data layout
@ProfBoc75
Hi.
Thank you for getting back to me. No problem :)
Will follow the instructions that you have provided. I will provide an update soon :)
Regards
Hi. @ProfBoc75
I have attached a few files using rtl_433 -S unknown when inserting batteries that are new (Cufiles.zip)
I have also provided the below data using new batteries and old batteries, every tip is 0.1mm
I also dont have a lcd screen for this so I cant tell you the values but know for a fact that the below collected data represents movement in the amount of tips as i have manually tipped the bucket and then captured the signals.
Rain Gauge - Batteries are fully charged. 2025-03-14 11:41:20|{67}a6f87fbdd7ffffef6|{66}a6f87fbdd7ffffef4| New batteries inserted -- First_433.92M_250k.cu8 2025-03-14 11:44:07|{68}a6f87fbfebfffffbb|{67}a6f87fbfebfffffba|0 tip - First code sent no tips --Second_433.92M_250k.cu8 2025-03-14 11:46:54|{67}a6f87fbfebf7ffef6|{66}a6f87fbfebf7ffef4|1 tip - Third_433.92M_250k.cu8 2025-03-14 11:52:28|{67}a6f87fbfebfbfffd6|{66}a6f87fbfebfbfffd4|2 tip 2025-03-14 11:58:02|{66}a6f87fbfebf7ffeac|{65}a6f87fbfebf7ffea8|3 tip 2025-03-14 12:09:10|{66}a6f87fbfebfdfff2c|{65}a6f87fbfebfdfff28|4 tip 2025-03-14 12:17:31|{65}a6f87fbfebf3ffd58|{64}a6f87fbfebf3ffd5|5 tip 2025-03-14 12:23:05|{67}a6f87fbfebfbfffb6|{66}a6f87fbfebfbfffb4|6 tip 2025-03-14 12:34:13|{66}a6f87fbfebf7ffe6c|{65}a6f87fbfebf7ffe68|7 tip 2025-03-14 12:37:00|{67}a6f87fbfebfefff76|{66}a6f87fbfebfefff74|8 tip 2025-03-14 12:50:55|{66}a6f87fbfebf5ffdec|{65}a6f87fbfebf5ffde8|9 tip 2025-03-14 12:53:42|{66}a6f87fbfebf9fffcc|{65}a6f87fbfebf9fffc8|10 tip
Rain Gauge - Weak batteries 2025-03-14 12:59:52|{66}a6f87fbdd7ffffeac|{65}a6f87fbdd7ffffea8| weak batteries inserted. 2025-03-14 13:02:39|{67}a6f87fbed7fffffd6|{66}a6f87fbed7fffffd4| 0 tip - First code sent/Initialized no tips yet. 2025-03-14 13:08:13|{65}a6f87fbed7efffd58|{64}a6f87fbed7efffd5|1 tip. 2025-03-14 13:10:59|{65}a6f87fbed7f7ffe58|{64}a6f87fbed7f7ffe5|2 tip 2025-03-14 13:22:07|{65}a6f87fbed7efffd58|{64}a6f87fbed7efffd5|3 tip 2025-03-14 13:24:55|{66}a6f87fbed7fbfff6c|{65}a6f87fbed7fbfff68|4 tip 2025-03-14 13:30:29|{64}a6f87fbed7e7ff9b|{63}a6f87fbed7e7ff9a|5 tip 2025-03-14 13:36:02|{66}a6f87fbed7f7ffeec|{65}a6f87fbed7f7ffee8|6 tip 2025-03-14 13:41:36|{66}a6f87fbed7efffdec|{65}a6f87fbed7efffde8|7 tip 2025-03-14 13:44:24|{66}a6f87fbed7fdfffcc|{65}a6f87fbed7fdfffc8|8 tip 2025-03-14 14:20:35|{64}a6f87fbed7ebffb3|{63}a6f87fbed7ebffb2|9 tip 2025-03-14 14:23:21|{64}a6f87fbed7f3ffd3|{63}a6f87fbed7f3ffd2|10 tip
Hope the above data helps.
Thank you
@effort10 : My first findings is that the flex proposed by rtl_433 is not good. It's not OOK_PWM but OOK_PCM with MC.
Try this:
rtl_433 -X 'n=name,m=OOK_PCM,s=320,l=320,r=1000,g=700,repeats>=5,unique'
This will give you data that must be Manchester decoded, with bitbench it's easy
You can replay your cu8 files, just add the cu8 file name at the end of the above command or *.cu8 to replay all files.
rtl_433 -X 'n=name,m=OOK_PCM,s=320,l=320,r=1000,g=700,repeats>=5,unique' *.cu8
rtl_433 -X 'n=name,m=OOK_PCM,s=320,l=320,r=1000,g=700,repeats>=5,unique' First_433.92M_250k.cu8
I did some attempt, to be confirmed, as we need more sample codes to fully guess the data layout.
- The ID looks fixed even if you change the battery, my attempt is based on your sample codes
- Then we have battery information for sure, at least one bit for battery inserted and low bat flag, same my attempt is based on your sample codes.
- Then we have rain gauge information, I reflected the 16 bit for the rain gauge to be confirmed as I don't have enough samples.
- The last byte looks like an XOR of previous 9 bytes and final XOR 0xDA.
Hi @ProfBoc75
Awesome. This is great. I will test with your proposed flex to gather some more tip data and provide you with the samples/data.
Thank you again :)
Regards
Hi @ProfBoc75
I have obtained some more samples for you of data for 11 tips for both a full battery and a weak battery.
I needed to change the TIP_RAIN_GAUGE_DEC to a different format from h(hex) to d(decimal) because when the tip count hit 10/11 it showed as 000a/000b
Please let me know if you need anything more.
Below are the bitbench links
Thank you :)
Looks promising, just after the battery inserted flag 1b you have low bat flag 1b also, replace the 7h8h by 1b 14h and you will see the low bat value 1 if weak battery.
If you can try to have more than 256 tips to confirm the 16 bit rain gauge coding. Not sure about the exact formula for the checksum, I will see later today.
@effort10
I probably guessed the data layout and the checksum formula in 2 steps.
1)- Need to Manchester decode and to reflect each byte ( ^8h ) : MC and Reflected
2)- From previous raw result here the final data layout: Data Layout
Bitbench Layout: (because of reflect, flag position changed)
HEADER 8h [ID 32h FIXED ? 6h LOW_BAT 1b BAT_INSERT 1b FIXED ? 8h RAIN GAUGE <16d] [BYTE_SUM] 8h
HEADER a5 [ID 08540304 FIXED ? 18 LOW_BAT 1 BAT_INSERT 1 FIXED ? 03 RAIN GAUGE 00000] [BYTE_SUM] c9
Data Layout
0 1 2 3 4 5 6 7 8 9
a5 08 54 03 04 61 03 00 00 c7 [Batt inserted]
HH[II II II II FB FF RR RR]SS
- HH: {8} Header, fixed 0xa5
- ID: {32} Sensor ID, does not change with new battery // May be done during the pairing task ?
- FF: {6} Fixed value, 0x6
- B:{1} Low Battery flag
- B:{1} Battery inserted flag
- FF:{8} Fixed value, 0x03 --> Channel ?
- RR:{16} little-endian rain gauge value, scale 10 (1 Tip = 0,1 mm)
- SS:{8} Byte sum of previous bytes except header [value in the hooks, from ID to Rain gauge].
What I saw from rainpoint.c existing decoder (temp & moisture sensor), it's very similar approach / data layout. From this user guide the rain gauge range is 0-9999 mm, strange as the 16 bit could be up to 6553.5 mm (scale by 10), so may be another MSB 1 bit is used somewhere into the data layout ? And confirmed the +0.1 mm accuracy (= 1 tip = scale 10)
In the user guide, Page 9 - 4.2 Basic Setting : You have Device ID and Device Address shown into the application, these values may be confirmed also, this will be helpful to validate the data layout and my assumptions. From my data layout, the ID is kept as "big-endian" (0x08540304 = 0139723524) , and could be "little-endian" coded (0x04035408 = 0067326984) like the rain gauge. to be checked please. Could be another number as you may have one nibble used for the channel /device address too ?
Looks promising, just after the battery inserted flag 1b you have low bat flag 1b also, replace the 7h8h by 1b 14h and you will see the low bat value 1 if weak battery.
If you can try to have more than 256 tips to confirm the 16 bit rain gauge coding. Not sure about the exact formula for the checksum, I will see later today.
Hi @ProfBoc75
Thank you for the update :) Genius stuff :)
Here are some more data sample for tips over the 256 count.
I probably guessed the data layout and the checksum formula in 2 steps.
1)- Need to Manchester decode and to reflect each byte ( ^8h ) : MC and Reflected
2)- From previous raw result here the final data layout: Data Layout
Bitbench Layout: (because of reflect, flag position changed)
HEADER 8h [ID 32h FIXED ? 6h LOW_BAT 1b BAT_INSERT 1b FIXED ? 8h RAIN GAUGE <16d] [BYTE_SUM] 8h HEADER a5 [ID 08540304 FIXED ? 18 LOW_BAT 1 BAT_INSERT 1 FIXED ? 03 RAIN GAUGE 00000] [BYTE_SUM] c9Data Layout
0 1 2 3 4 5 6 7 8 9 a5 08 54 03 04 61 03 00 00 c7 [Batt inserted] HH[II II II II FB FF RR RR]SS
- HH: {8} Header, fixed 0xa5
- ID: {32} Sensor ID, does not change with new battery // May be done during the pairing task ?
- FF: {6} Fixed value, 0x6
- B:{1} Low Battery flag
- B:{1} Battery inserted flag
- FF:{8} Fixed value, 0x03 --> Channel ?
- RR:{16} little-endian rain gauge value, scale 10 (1 Tip = 0,1 mm)
- SS:{8} Byte sum of previous bytes except header [value in the hooks, from ID to Rain gauge].
What I saw from rainpoint.c existing decoder (temp & moisture sensor), it's very similar approach / data layout. From this user guide the rain gauge range is 0-9999 mm, strange as the 16 bit could be up to 6553.5 mm (scale by 10), so may be another MSB 1 bit is used somewhere into the data layout ? And confirmed the +0.1 mm accuracy (= 1 tip = scale 10)
In the user guide, Page 9 - 4.2 Basic Setting : You have Device ID and Device Address shown into the application, these values may be confirmed also, this will be helpful to validate the data layout and my assumptions. From my data layout, the ID is kept as "big-endian" (0x08540304 = 0139723524) , and could be "little-endian" coded (0x04035408 = 0067326984) like the rain gauge. to be checked please. Could be another number as you may have one nibble used for the channel /device address too ?
Hi @ProfBoc75
Wow. this is amazing. Thank you
I cant confirm the values for Device ID and Device Address as I dont have the gateway so i cant use the app. Also there is no channel setting on the rain gauge. Just batteries so i think it just defaults to whatever channel that is hardcoded into the device.
Regards
@effort10 , or may be you have an id on a sticker , underside, around or inside the battery trap ?
One very interesting finding here
I discovered that the rf module is common to other Rainpoint sensors, this means that we have probably the type of sensor inside the data layout, may be inside the ID or in the other fixed values 0x18 and 0x03. I will draft a decoder and expose these value.
Edit: your last samples confirmed the 2 bytes for Rain gauge, now, missing 1 bit for MSB , but you have to get more than 65536 TIPs (without breaking the sensor ), good luck 😄 ... or wait few months / years ...
@effort10 , or may be you have an id on a sticker , underside, around or inside the battery trap ?
One very interesting finding here
I discovered that the rf module is common to other Rainpoint sensors, this means that we have probably the type of sensor inside the data layout, may be inside the ID or in the other fixed values 0x18 and 0x03. I will draft a decoder and expose these value.
Edit: your last samples confirmed the 2 bytes for Rain gauge, now, missing 1 bit for MSB , but you have to get more than 65536 TIPs (without breaking the sensor ), good luck 😄 ... or wait few months / years ...
Hi @ProfBoc75
I have looked all over to find the DeviceID without any luck. Interesting info you found online regarding the module.
With regards to the MSB bit I can manually move the tipping bucket over time until it goes over the 65536 count. It normally takes me like 4-5 min do get to a count of 1000 tips so will do it everyday until i get to 65536 and let u know:)
Regards
@effort10 : I created a PR #3240 , if you can test it and let me know.
@effort10 : I created a PR #3240 , if you can test it and let me know.
Hi @ProfBoc75
Awesome. I will test this shortly and provide feedback.
Regards
Hi @ProfBoc75
I have done the test. All looks good.
The red section is low battery and the green section is strong battery. Both tests are on insert of weak/strong batteries and then a few tips and then a lot of tips.
Regards
Hi @ProfBoc75 ,
After some rain and comparisons between neighbours rainfall devices etc i came to the conclusion that the mm per tip of the rainpoint rain gauge is actually 0.5mm and not 0.1mm.
I used a plastic rain gauge plus neighbours feedbacks for comparisons and also did some tests.
- I used a syringe to measure how much water when added to the plastic rain gauge equals 1mm, this worked out to 15ml of water.
- Did the same test with the rainpoint rain sensor and it tips once there is 7.5ml of water in the tipping bucket so that equates to 0.5mm per tip if 15ml is reporting 1mm on the plastic gauge.
- The code needs to be modified to display 0.5mm per tip instead of 0.1mm :)
Regards
Hi @ProfBoc75 ,
After some rain and comparisons between neighbours rainfall devices etc i came to the conclusion that the mm per tip of the rainpoint rain gauge is actually 0.5mm and not 0.1mm.
I used a plastic rain gauge plus neighbours feedbacks for comparisons and also did some tests.
1. I used a syringe to measure how much water when added to the plastic rain gauge equals 1mm, this worked out to 15ml of water. 2. Did the same test with the rainpoint rain sensor and it tips once there is 7.5ml of water in the tipping bucket so that equates to 0.5mm per tip if 15ml is reporting 1mm on the plastic gauge. 3. The code needs to be modified to display 0.5mm per tip instead of 0.1mm :)Regards
@effort10 , another way is to calculate with the rain gauge opening to get figures and exact value.
Rain gauge value unit is in mm/m² , when reported as 1 mm/m² = 1 Liter.
Long story short:
- You have to take care about unit, between m and cm , 1m² = 10000 cm², 1m3 = 1 000 000 cm3 = 1 000 L
- You have to take care about volume in Liter or m3, to be reported in length/height in mm : 1 Liter into a cube box of 1x1x1 m = 1 mm of height.
- circle surface is pi x radius² (most of rain gauges are round)
So, each time 1L is going into the rain gauge, how many liter is going to 1m². The result is:
- 1m2 / rain gauge surface in m² = ratio factor = number of liter.
Example with a gauge surface with 12 cm diameter = pi x 6² = 113.097 cm²
- Ratio is 10 000 / 113.097 = 88.4
- So each time 1 L is going into that rain gauge, in reality it's 88.4 L/m² = 88.4 mm/m2
Now you have found the 7.5 ml / tip. If I revert back your estimation, I should be able to found the rain gauge diameter:
- With 0.1 mm / tip = 0.1 mm/m² = 0.1 L = 100 ml in reality. With 7.5 ml input , ratio = 100 / 7.5 = 13.3333 square root of (13.3333 / pi) = 2 cm, so a rain gauge diameter of 4 cm, not good or very small.
- With 0.5 mm / tip = 0.5 mm/m2 = 0.5 L = 500 ml in reality. With 7.5 ml input, ratio = 500 / 7.5 = 66.666 square root of (66.6666 / pi) = 4.6 cm, so a rain gauge diameter of 9.2 cm, much more realistic, and probably the case.
If you confirm your rain gauge diameter of 9.2 cm, I can update the conversion too 😃
Hi @ProfBoc75
Thanks for this. Yes, I can confirm that the diameter is 9cm. Below is also a formula that chatgpt provided me to calculate the mm per tip.
Regards
Bartosz
I think we need to have an outright ban on LLM-generated content in this repo. It's at best trained on stolen content, and often wrong.
