Fix detection of Bresser Professional Rain Gauge

[aimylios]

I have been using rtl_433 for roughly a year now to receive the data from my rain sensor, a Bresser Professional Rain Gauge. It worked out of the box, and I didn't experience any issues. Until two weeks ago. I had to change the batteries, and after that my setup stopped working. rtl_433 was still receiving the data from the sensor, but it was incorrectly labelled as a "Bresser-5in1" weather center, and the rain values were too low.

Looking at the code I realised that there is a magic nibble in each packet which is used to identify the type of device. Unfortunately I don't have any recordings from before the battery change. But it must have been 0x9 then (otherwise it wouldn't have worked). Now it is 0xA, though. So the assumption that the respective byte is static was incorrect.

I don't know if there is any way at all to identify the type of device from the packets themselves. And unfortunately I currently don't have physical access to the sensor to do another battery change and see what happens. For now I adapted the code to check for ((msg[15] & 0xF) >= 0x9) instead of ((msg[15] & 0xF) == 0x9).

Attached is a sample I captured today with my modified version of rtl_433.

time      : 2023-03-18 19:37:20
model     : Bresser-ProRainGauge                   id        : 194
Battery   : 1            Temperature: 9.9 C        Rain      : 35.0 mm       Integrity : CHECKSUM
[pulse_slicer_pcm] Bresser Weather Center 5-in-1
codes     : {276}aaaaaaaaaa2dd4ec3d45ffffffef66ff8ebffeff13c2ba00000010990071400100000

g001_868.3M_1000k.cu8.gz

[zuckschwerdt]

Thanks for the feedback! The >= 0x9 seems strange, could it be >= 0x8, i.e. only 7 bit are used? Or maybe it's != 0?
It would be really great if someone could reset their sensor a couple of times to see what the range there really is.

[aimylios]

Indeed, checking for ((msg[15] & 0xF) >= 0x9) is strange and almost certainly not the correct way to distinguish between the Rain Gauge and the 5-in-1 Weather Center. It's just the best I came up with based on the limited number of samples for both devices documented in the source code.

Maybe II and SS belong together somehow and there is a range of IDs assigned to each type of sensor. Or there is a counter that gets incremented each time the sensor and the base station go through the pairing process. Or it's just random values. Or something entirely different. Difficult to say without documentation from the manufacturer.

It will be another ~4 weeks until I get back on site and can try to repeat the battery change a few more times to see how it affects the SS bits. I will report back once I've collected more data. Let's leave this PR open until then. And maybe someone else who owns the Rain Gauge or the 5-in-1 Weather Center gets a chance to take a look at this before I do.

[aimylios]

I've finally found some time to play a bit more with the Bresser Professional Rain Gauge. It turns out that my initial assumption to check for ((msg[15] & 0xF) >= 0x9) instead of ((msg[15] & 0xF) == 0x9) was indeed incorrect.

I've reset the sensor about ~30 times now (either by taking out the batteries or via the reset button), and the values I get are either 0x9, 0xA, or 0xB. Here's an example for 0xB:

time      : 2024-01-03 13:46:53
model     : Bresser-ProRainGauge                   id        : 215
Battery   : 1            Temperature: 9.5 C        Rain      : 0.2 mm
Integrity : CHECKSUM
[pulse_slicer_pcm] Bresser Weather Center 5-in-1
codes     : {276}aaaaaaaaaa2dd4e92844ffffffef6aff8efeffff16d7bb00000010950071010000000
*** Saving signal to file g011_868.3M_1000k.cu8 (67411 samples, 262144 bytes)

g011_868.3M_1000k.cu8.gz

So at least one of the two least-significant bits is always set, but none of the other bits ever change. I first thought this is something like a "reset counter", but the change doesn't seem to be predictable (i.e., the nibble may not change at all or jump to any of the other two possible values). Both changing the batteries and pressing the reset button is a bit tricky, though, so it could be that I may have inadvertently performed multiple resets in a row without noticing. Or maybe these bits are part of the ID (since this is the only other value that changes between resets), but then I would expect 0x8 to show up as well. It would be interesting to know if the 5-in-1 Weather Center shows a similar behaviour.

My current understanding of the sS byte is that:

• the most-significant bit indicates a reset within the last hour
• the following five bits indicate the sensor type
• the two least significant bits have an unknown meaning

Based on this I've adapted my patch for this PR. Please let me know whether it can be accepted as-is or you would like me to make additional changes.

[zuckschwerdt]

Thanks, this look very thoroughly researched and probable!