Handling of shared rain / temperature&humidity data (6-in-1 protocol)

[DL4AAS]

Hi Matthias,

this is more a question, not an issue - hopefully. The rain counter of my sensor is wrong in LoRaWAN.

The sensor 6in1 sends two different packets every 12s:

• one has temp/hum information
• one has rain information

You mention this in the software, but how do you handle it? Your sensor module sets rain_ok OR temp_ok, but you always send both information to LoraWAN. I think, I missed a detail...

Second thing: I'm using the rtl_433-software on RPi to decode the same sensor and send results to my local MQTT broker. So I'm somewhat familiar with the sources. RTL_433 decides with msg[12] == 0xFF, if it is rain or temp/hum data. I've seen you have made a correction yesterday, but are you sure, that you always get only rain OR temp/hum?

Best Regards, Jens.

[matthias-bs]

Hi Jens,

the BresserWeatherSensorReceiver basically tries to receive both kind of packets to collect the data.

I'm re-using the decoder functions from the rtl_433 project. There is currently a discussion on how to distinguish both kinds of packets. The current version gets the rain gauge values wrong if the temperature falls below zero. There is a fix which I added yesterday (please see https://github.com/matthias-bs/BresserWeatherSensorReceiver/issues/21) , but it seems it is more of a workaround than a final solution. It seems to work and improve the decoding, but a definite reverse-engineering of the packet encoding would be better.

It seems @MacH-21 has done this: https://github.com/merbanan/rtl_433/issues/1214#issuecomment-1346856949. Let's see if others can confirm that.

Currently I do not have as much time to spend on this as I would like.

Best Regards Matthias

[matthias-bs]

BTW: Which rain counter value is wrong? rain_mm or the other ones? rain_mm is the current sensor value, the other values are calculated. The rain statistics still have a problem when a rain value of '0' occurs by accident. Normally this should be marked by an invalid flag, but obviously it isn't. The '0' is considered as a roll-over of the counter value, this leading to high daily/weekly/monthly values.

[DL4AAS]

BTW: Which rain counter value is wrong? rain_mm or the other ones? rain_mm is the current sensor value, the other values are calculated. The rain statistics still have a problem when a rain value of '0' occurs by accident. Normally this should be marked by an invalid flag, but obviously it isn't. The '0' is considered as a roll-over of the counter value, this leading to high daily/weekly/monthly values.

Hi Matthias, it is rain_mm. I will make some tests and come back with the results.

Jens

[DL4AAS]

Hi Matthias, after some debugging, I would say, this part of code is doing the decoding for me:

temp_ok = (msg[12] != 0xff);
if (temp_ok) {
        int   temp_raw = (msg[12] >> 4) * 100 + (msg[12] & 0x0f) * 10 + (msg[13] >> 4);
        float temp     = temp_raw * 0.1f;
        if (temp_raw > 600)
            temp = (temp_raw - 1000) * 0.1f;
        sensor[slot].temp_c      = temp;
        sensor[slot].battery_ok  = (msg[13] >> 1) & 1; // b[13] & 0x02 is battery_good, s.a. #1993
        sensor[slot].humidity    = (msg[14] >> 4) * 10 + (msg[14] & 0x0f);
} else {
    rain_ok = true;
    msg[13] ^= 0xff;
    msg[14] ^= 0xff;
    int rain_raw     = (msg[13] >> 4) * 1000 + (msg[13] & 0x0f) * 100
                 + (msg[14] >> 4) * 10 + (msg[14] & 0x0f);
    sensor[slot].rain_mm   = rain_raw * 0.1f;
}

But often there is only one part (temp/hum or rain) set in the data. I've found two possible reasons:

• in setup() the call mySensor.setup(); ends with a timeout - but the next function myLoRaWAN.setup(); is called even in this case.
• bool decode_ok = weatherSensor.getData(WEATHERSENSOR_TIMEOUT * 1000, DATA_ALL_SLOTS); I think, DATA_COMPLETE should be added.

Jens

[DL4AAS]

Hi Matthias, the massive problems to decode enough messages before timeout were homemade by debug code. The reasons mentioned above are still there, but with the better reception after fixing my debug code they are not so relevant. Jens

[DL4AAS]

Aeh, using your library example BresserWeatherSensorBasic I saw that the first row of the code should look like this:

humidity_ok = temp_ok = (msg[12] != 0xff);

Jens

[matthias-bs]

Hi,

Currently, msg[12] is also considered part of the rain gauge value (inverted BCD), so we cannot rely on this byte to distinguish between message types. Please see https://github.com/merbanan/rtl_433/blob/master/src/devices/bresser_6in1.c

It seems, msg[16] contains the desired information. Let's see how this works out...

Regarding the option to weatherSensor.getData() - DATA_ALL_SLOTS/DATA_COMPLETE: There is always a compromise between run time (regarding energy consumption while battery powered) and completeness of data. I made my choice, because I wanted to receive data from both a weather sensor and a soil moisture sensor (therefore DATA_ALL_SLOTS) and receiving incomplete data from time to time was acceptable. And my choice was to send a LoRaWAN message even if some/all data was corrupt/incomplete to see that the node is still up and running. But I also considered to have a compile time option for that, which is not implemented yet.

In my main application, I receive data from a weather sensor with 5-in-1 protocol (which is very reliable) and the soil moisture sensor (6-in-1 protocol). I am currently receiving the weather sensor with 6-in-1 protocol (my neighbours') in my test environment.

Best regards Matthias

[DL4AAS]

Hi,

Currently, msg[12] is also considered part of the rain gauge value (inverted BCD), so we cannot rely on this byte to distinguish between message types. Please see https://github.com/merbanan/rtl_433/blob/master/src/devices/bresser_6in1.c

It seems, msg[16] contains the desired information. Let's see how this works out... I see what you mean: 0xff inverted is 0 - may be the upper numbers of rain. My counter is on 278,4 now, we have to wait 2 more years... Our LoRaWAN-Group has some of the bresser 6in1 (with 5 sensors) . I'll try to test it with a servo moving the rain sensor.

Regarding the option to weatherSensor.getData() - DATA_ALL_SLOTS/DATA_COMPLETE: There is always a compromise between run time (regarding energy consumption while battery powered) and completeness of data. I made my choice, because I wanted to receive data from both a weather sensor and a soil moisture sensor (therefore DATA_ALL_SLOTS) and receiving incomplete data from time to time was acceptable. And my choice was to send a LoRaWAN message even if some/all data was corrupt/incomplete to see that the node is still up and running. But I also considered to have a compile time option for that, which is not implemented yet. Ok, I understand. A comment would help, perhaps. But on the other hand: Now I know something more about your software ;-)

In my main application, I receive data from a weather sensor with 5-in-1 protocol (which is very reliable) and the soil moisture sensor (6-in-1 protocol). I am currently receiving the weather sensor with 6-in-1 protocol (my neighbours') in my test environment.

Best regards Matthias Regards and thank you for this project, Jens

[matthias-bs]

Hi Jens,

this should be fixed now - in a clean way, I think.

Regards Matthias