Bresser-6in1 no UV being received

[davidaswan]

Evening,

I have recently set up rtl_433 to receive data from my Bresser-6in1 weather station. I am receiving the two transmissions as described in Bresser_6in1.c at the stated interval but the content is different and crucially, I am lacking the UV index, which, is actually what I am after.

The data I receive arrives in the following:

• model, id, channel, battery, temperature, humidity, sensor type, wind gust, wind speed, wind direction, integrity
• model, id, channel, battery, sensor type, wind gust, wind speed, wind direction, rain, integrity

My Bresser receiver appears to be correctly showing the UV index.

Now my internal temperature sensor for the (separate 7 channel unit) is transmitting the following:

• model, id, channel, battery, temperature, humidity, sensor type, UV, integrity

It doesn't add up that the indoor sensor is transmitting a UV reading (which is always 0).

I suspect the error is mine but Im not sure how to resolve it. Im running the following command to obtain my data: rtl_433 -f 868300000 -R 172

Any pointers would be greatly appreciated. David

[zuckschwerdt]

The 6in1 protocol uses a "clever" scheme to encode multiple values into the same fields. We might not have the decoding perfectly right yet. If you can use -R 172:vv to show the raw codes and post some which could have UV data. E.g. the ff 01 near the end would be the (invalid here) UV value:

bresser_6in1_decode: : {144} df 9c 18 c0 06 c0 18 ff 99 ff 13 58 ff fe 7f ff 01 cb

[davidaswan]

Thank you for the very quick reply. Running '-R 172:vv' gives me the following message.....Protocol [172] "Bresser Weather Center 6-in-1" does not take arguments "vv"!

[zuckschwerdt]

Ok, might be and old version of rtl_433 then. Maybe use just -vv or -vvv but then, but it's more output to look through ;)

[davidaswan]

Hi there, Here is the data I have captured. UV index at the time of recording was 5.7

{204} 55 55 55 55 54 5b a9 16 5c 32 20 0b da 31 ff ff fe 08 f1 ff ff ff fe 02 ac 00
{204} 55 55 55 55 54 5b a9 8e 6e 32 20 0b da 31 ff ff fe 0e 70 24 e8 ab fc e0 8f f0
{205} aa aa aa aa aa 2d d4 c2 10 19 10 05 ed 18 ff ff ff 07 88 ff ff ff ff 01 43 f8
{202} 55 55 55 55 54 5b a9 63 d6 32 20 0b da 31 ff ff fe 0e 10 24 e8 ad fc e0 ec 00
{205} aa aa aa aa aa 2d d4 f8 7a 19 10 05 ed 18 ff ff ff 03 38 ff ff ff ff 01 97 f8
{205} aa aa aa aa aa 2d d4 05 31 19 10 05 ed 18 ff ff ff 04 28 12 74 55 fe 70 5a 00
{205} aa aa aa aa aa 2d d4 9c d9 19 10 05 ed 18 ff ff ff 08 08 ff ff ff ff 01 c2 00
{205} aa aa aa aa aa 2d d4 62 52 19 10 05 ed 18 ff ff ff 08 08 12 74 55 fe 70 76 00
{205} aa aa aa aa aa 2d d4 d4 36 19 10 05 ed 18 ff ff ff 04 18 ff ff ff ff 01 b6 00
{204} 55 55 55 55 54 5b a9 bc 76 32 20 0b da 31 ff ff fe 0c f0 24 e8 ab fd 41 b0 00
{204} 55 55 55 55 54 5b a8 73 78 32 20 0b da 31 ff ff fe 0e 71 ff ff ff fe 03 27 f0
{204} 55 55 55 55 54 5b a8 8e c0 32 20 0b da 31 ff ff fe 08 50 24 e8 b1 fc e0 af f0

The shorter strings contain the rain data, where as the longer strings contain the temperature. The wind is 0 for all reading as I taped the anemometer in place. It seems my neighbour also has a station that decodes as a Bresser-6in1.

Thanks again!

[zuckschwerdt]

Looks like the packets have data in that field, as seen in this BitBench. Not sure if the coding is correct though. Is that a value you expect (15 and 18)? Note that the values with f are not valid.

[davidaswan]

Interesting. No, the value should have been around 5.7 when that data was received.
Do you think it could be poor signal strength? I don't receive any reference to UV in the decode at all which seems a little strange as there seems to be data in that field.

[zuckschwerdt]

The reception is good. We've only seen a value of ff 01 in that field so far, so no clue what a valid reading would look like. The decoder tries to read it as BCD which isn't correct, it would be something like inverted BCD. Values seen here (original and inverted) are:

ff01 / 00fe
fe70 / 018f
fea0 / 015f

not sure how to decode this though. Could you get readings of that field slowly ramping up or down?

[davidaswan]

Evening, Here is some data from today. Values for UV index on by internal unit read 1.9, 2.8 and 3.8 I didn't see any values in-between these and I suspect the read out resolution doesn't exactly match the data....? If I come across a UV torch, I will see if I can get some more gradual and steady increase in data.

{204} 55 55 55 55 54 5b a8 5b d2 32 20 0b da 31 ff ff fe 29 11 ff ff ff fe 02 6c 00
{204} 55 55 55 55 54 5b a8 77 9e 32 20 0b da 31 ff ff fe 2e 31 ff ff ff fe 03 47 f0
{205} aa aa aa aa aa 2d d4 95 88 19 10 05 ed 18 ff ff ff 15 88 ff ff ff ff 01 35 f8
{204} 55 55 55 55 54 5b a9 32 54 32 20 0b da 31 ff ff fe 2c 11 ff ff ff fe 03 68 00
{202} 55 55 55 55 54 5b a8 f3 a6 32 20 0b da 31 ff ff fe 32 91 ff ff ff fe 02 e3 c0
{205} aa aa aa aa aa 2d d4 99 2a 19 10 05 ed 18 ff ff ff 16 08 ff ff ff ff 01 b4 00

Thanks again!

[zuckschwerdt]

Put those codes in the BitBench linked above. All UV values read FF 01 --- invalid. So strange!

[MacH-21]

Hi Christian, David, I am building my own Weather Station / Remote sensors based on the Bresser/Youshiko units. Christian, we looked at these data streams in issue #1214 -12 Feb 21. Can we link/merge issues #1214, #1993, #2013.

I can see David's UV, it is as we said when the low nibble is "0" UV is valid "fe70", fe7 is UV 1.8 and fea is UV 1.5, 0 is flag when the low nibble is "1" Rainfall is valid "ff01"

I have inserted David's data into my Transmitter and it displays correct see attachments.

David does your station look like the station in issue #1214, If so can you see if it has a UV index gain It maybe incorrectly set as your display is UV 5.7, Can you give model numbers of you station an remote sensors.

The reception is good. We've only seen a value of ff 01 in that field so far, so no clue what a valid reading would look like. The decoder tries to read it as BCD which isn't correct, it would be something like inverted BCD. Values seen here (original and inverted) are:

ff01 / 00fe
fe70 / 018f
fea0 / 015f

not sure how to decode this though. Could you get readings of that field slowly ramping up or down?

I will test Battery Level and Rain Soon. sorry for large post hope it's of use Regards Mac

Bresser-Youshiko 6 in 1 decode.txt

[zuckschwerdt]

Oh, thanks! So we do have the mapping correct already:

ff01 -> no UV
fe70 -> UV valid -> 018f -> 1.8
fea0 -> UV valid -> 015f -> 1.5

We just need to invert the UV bytes. I'll add that now.

[zuckschwerdt]

The fixed decoding can be tested with the codes above, e.g. rtl_433 -y '{204}55555555545ba98e6e32200bda31fffffe0e7024e8abfce08ff0' shows the 1.8 UV.

[davidaswan]

Good Morning Mac, My station is a colour version of that in issue #1214 I believe. See attached photo's. Model number of the receiver station is 7002540CM3000 and the outdoor sensor shares the same number. The inside sensor is model 7009999. My gain is set to the value stated on the sensor battery case and this seems to be giving sensible results....

Mac and Christian, thank you for the amazing support and your great software. I have updated the the latest version with the fix and it seems to be running as expected. The only peculiarity is that the indoor temp/ humidity sensor is also giving a UV index and seems to be fixed at 166.5 but this can obvioulsy be ignored. '{428} 55 55 55 55 55 16 ea 18 79 8c b8 0c 66 14 80 00 00 00 00 10 c3 21 00 00 40 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'

Thank again, David

[zuckschwerdt]

peculiarity is that the indoor temp/ humidity sensor is also giving a UV index and seems to be fixed at 166.5

That would be a raw value of 0000 (000 -> fff -> 150+15+1.5) where we suspected the last digit =0 to flag a valid reading. It seems more complicated than that. But we can just add 0000 to the existing exclusion of ff01. I.e. we want the last digit to be 1 and no 0's in the value.

[davidaswan]

Got it. Thanks again!

[zuckschwerdt]

Fixed with 8228f0d.