Bresser-6in1 rain value flag for SENCOR SWS 9898

[Gollam]

Hi, I have bought a SENCOR SWS 9898 station. I think it has the Bresser chip inside, it is identified as protocol 172, Bresser 6in1. Mine is in fact a 5 in 1 sensor group, it does not have UV sensor. The decoder says 0 for UV, all the time, I had no problem with that, I ignored it. Every other measurement was accurate (temperature, humidity, rain, wind direction, wind speed and gust). I have measurements for these:

However, today was the first day that the temperature drop below 0 °C and this is where the decoder started to behave interestingly.

As you can see, some fields have changed. The second type of message also has a new rain value, with some random content, and the battery indicator field went missing.

The samples for both cases: sencor_sws9898_correct_samples.zip sencor_sws9898_incorrect_samples.zip

I have no clue in which direction should we start investigating this, I'd appreciate some help.

[Gollam]

I just found https://github.com/merbanan/rtl_433/issues/2096, and as I read it, it may be related to my problem.

[zuckschwerdt]

The samples are very clean. The timings are exactly the Bresser ones: FSK PCM with 124 µs. Get raw codes with rtl_433 -R 0 -X 'n=sencor,m=FSK_PCM,s=124,l=124,r=3000':

correct_g007_868.33M_1000k.cu8   {225}d55555555545ba850d82560283831fffffe2251fffbfffe0388000000
correct_g008_868.33M_1000k.cu8   {228}eaaaaaaaaaa2dd45af312b0141c18ffffff1128119280fff0ad000000
correct_g009_868.33M_1000k.cu8   {226}eaaaaaaaaaa2dd4286c12b0141c18ffffff1128fffdffff01c4000000
correct_g010_868.33M_1000k.cu8   {226}eaaaaaaaaaa2dd4273012b0141c18ffffff1128119279fff0b4000000
incorrect_g001_868.33M_1000k.cu8 {226}d55555555545ba86f5a2560283831fffffe121132d52fffe0bc000000
incorrect_g003_868.33M_1000k.cu8 {225}d55555555545ba973642560283831fffffe1211fffbfffe03d8000000
incorrect_g004_868.33M_1000k.cu8 {226}d55555555545ba86f5a2560283831fffffe121132d52fffe0bc000000
incorrect_g005_868.33M_1000k.cu8 {225}d55555555545ba973642560283831fffffe1211fffbfffe03d8000000

Here as a BitBench with the formats we expect. Now we need to inspect the fields to see what differs.

[MacH-21]

Hi Christian/Gollam, I took a look at the received data, All looks good to me RTL_433 should not report Rain when Flags : 0 I have included a text file with findings also bitbench links and formating. hope this is of some help. Gollam, Can you please report if your indoor display is showing a low battery symbol for the outside station, any chance of attaching a photo? RTL_433 Issue #2184.txt

[Gollam]

@MacH-21 well it does not show it at the moment (batteries are new), but it has the feature:

[MacH-21]

@Gollam, Thanks for quick reply, The reason for asking is I am testing the unknown bits/flags of the Bresser protocol, when you have low battery symbol please post data captures (if possible). I have a 6in1 station soon to have 7in1(WiFi).

[Gollam]

I'll try to find some used batteries to trigger it.

[Gollam]

Here you go.

sencor_sws9898_battlow_samples.zip

[franki29]

Hi , for me it looks like int rain ok in the code is the value that is not working correctly. int rain_ok = msg[12] <= 0x99 && msg[13] <= 0x99 && msg[14] <= 0x99; If you change it to int rain_ok = msg[12] <= 0x65 && msg[13] <= 0x99 && msg[14] <= 0x99; it seems to work correctly.

In you samples file incorrect_g005_868.33M_1000k.cu8 you have the correct value of 20mm but in file incorrect_g004_868.33M_1000k.cu8 you have a value for msg[12] of 66.

For me it looks like that the msg[12] contains a bit for temperature below 0 ?

I have also a Bresser 6 in 1 Sensor but I do not have this behavior seen yet.

Looking at the Bit in msg[12] you have (Just if rain should not be OK, other wise msg[12] is 0x00)

11101110 (ee) for the correct samples and the battery low

01100110 (66) for the incorrect samples (Temperature below 0)

My Bresser 6 in 1 shows ( I do not have a sample below 0) 11101111 (ef)

@MacH-21 what is the value of msg[12] in your case?

[zuckschwerdt]

If you change it to int rain_ok = msg[12] <= 0x65 ... it seems to work correctly.

But why 0x65? Any value 0-9 (00-99) would likely be a valid rain value there. The original fields 12-14 are 99 6a 97 (inverted for possible rain 669568) -- what would those fields contain then? It's not TEMP:99.6 HUM:97 (your values are 11.9 C, 80%) -- temp and rain share that field, or is something else in that field too?

[franki29]

Hi, 0x65 might not be the final right one, it would just work for Gollam.

The original fields 12-14 are 99 6a 97

At my side the values are 00 64 24 if the rain values are transmitted

For rain not OK it is ed xx xx (depending on the temperature and humidity) so the current code is working as ed is larger than 99

At Gollam rain OK is 00 02 00 no matter if temperature is above or lower than 0

For rain not OK it is ee if temperature is above 0 and 66 if temperature is below 0 so the current code does not detect that rain is not OK

I assume that the transmission code if rain values are send has changed?

Also I do not have a UV sensor but it is detecting the UV as OK. As the fields ~msg[15],~msg[16] are used for the UV, our transmission values are also different.

If our sensor transmit rain values, the message msg[15],msg[16] has a value of ff 01 (I did not invert the values) If our sensor transmit temp/hum, the message msg[15],msg[16] has a value of ff f0

My resume for that is that at our side one of the Bit in the message 15 or 16 is the indicator if we receive rain values or temp/hum values. Make this sense?

[zuckschwerdt]

To be clear: Temp/Hum and Rain share the same field. We must choose if we see that field as Temp/Hum or Rain. (e.g. field 12 of 11 is 11 ^ ff = ee for rain.

At my side the values are 00 64 24 if the rain values are transmitted

That would be ff 9b db if see as Temp/Hum and thus invalid -> this works well.

For rain not OK it is ed, ... ee

Yes, that is a Temp value of 12 or 11 and thus valid.

But 99 as Temp is 66 as Rain, both valid -> this is not good.

And going back to the unexpected Temp value: 99.6 -- that is actually –0.4 C (we use temp > 600 then temp = temp - 1000) but that value will also produce a valid rain reading, which is bad.

My resume for that is that at our side one of the Bit in the message 15 or 16 is the indicator if we receive rain values or temp/hum values.

I was hoping for a bit that indicates temp or rain, but I never found that bit.

[MacH-21]

@Gollam, Thanks for Screenshot and Zip I will check out samples later.

@zuckschwerdt I was hoping for a bit that indicates temp or rain, but I never found that bit.

I use the LSB of msg16 (0 = Temperature Valid) (1 = Rain Valid)

[anthyz]

I must be missing something. Why isn't msg[16] & 1 a sufficient indicator?

[franki29]

Hi anthyz, looks like this is working with Bresser Station Sensor 6 in 1 that have no UV sensor. They are selling this station as 5 in 1.

The questions is how to detect a Bresser 6 in 1 with UV sensor and will msg[16] & 1 still working ?

[matthias-bs]

Hi, Is there any difference in the sensor type ('stype' if I remember correctly) between the two variants? Regards Matthias

[Gollam]

@matthias-bs is that a question for my sensor? If yes, is that written on it somewhere?

[franki29]

Hi, Is there any difference in the sensor type ('stype' if I remember correctly) between the two variants? Regards Matthias

Does not look like. Using data from a older post #2013 , the sensor type is the same. rtl_433 -y '{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' -R172

But msg[16] & 1 still working for rain ok with those data.

[Gollam]

@franki29 @zuckschwerdt so what is the conclusion?

[franki29]

Hi @Gollam , I would suggest to you to use the solution that @anthyz is suggesting and change the code to:

//int rain_ok = msg[12] <= 0x99 && msg[13] <= 0x99 && msg[14] <= 0x99; int rain_ok = msg[16] & 1; Recompile it and test it with your sensors

[Gollam]

All right, will do! As soon as the negative degrees settle in again :D Nowadays we have quite warm weather.

[Mindavi]

Another way to try it out is to put it in the freezer to go below zero.

[Gollam]

I know, thanks for the tip :) I did that with my previous device I was decoding. But the outdoor unit of this one is far too big for that, and I don't want to disassemble it anyways.

[Gollam]

But just our luck, it started freezing, because of a cold front. It seems it works as expected. So how to move forward with this? Can this change be made permanent? I'm thinking about, won't this break any other type of sensor's data which also use this decoder?

sencor_sws9898_everything_fine.zip

[zuckschwerdt]

Can this change be made permanent? I'm thinking about, won't this break any other type of sensor's data which also use this decoder?

That's the important question. We would really need feedback from someone with the UV option, as that tested bit is shared with the UV output -- but we do suspect it's all flags.

https://github.com/merbanan/rtl_433/blob/e066b669f7574c37f943f251ec8023b00cff1df6/src/devices/bresser_6in1.c#L153-L157

[Gollam]

The issue which added it is: https://github.com/merbanan/rtl_433/issues/1214 (why is it still open?)

@f4gqk, @RebeckaJohansson, @MacH-21 I saw you had UV readings for a 6in1 sensor, can you please help verify the new code?

[MacH-21]

Bresser6in1-Sencor5in1.txt edited in notepad++

@Gollam I could not test the low battery samples as the file seems to be corrupt (signal clipping) can you retest/resend if possible.

what is the value of msg[12] in your case? @franki29 please check out line 26 of included txt file.

@zuckschwerdt I find Rain uses msg12,13,14 & 15. see txt file, as stated I used notepad++ (hopefully the formatting stays ok). Max value = 19999.000mm (a lot of rain)!

[merbanan]

bresser_6in1_decode: : {144} 41 ef 38 05 35 05 18 ff ff ff 19 28 99 9e 99 ff f0 73 bresser_6in1_decode: : {144} 6e 1b 38 05 35 05 18 ff ff ff 19 28 ff af c9 ff 01 bb bresser_6in1_decode: : {144} 8c 45 38 05 35 05 18 ff ff ff 19 28 00 06 99 ff f0 a4 bresser_6in1_decode: : {144} cc b6 38 05 35 05 18 ff 99 ff 19 28 ff af c9 ff 01 21

Some messages from another issue when the temperature got to minus.

[MacH-21]

@merbanan

bresser_6in1_decode: : {144} 41 ef 38 05 35 05 18 ff ff ff 19 28 99 9e 99 ff f0 73 bresser_6in1_decode: : {144} 6e 1b 38 05 35 05 18 ff ff ff 19 28 ff af c9 ff 01 bb bresser_6in1_decode: : {144} 8c 45 38 05 35 05 18 ff ff ff 19 28 00 06 99 ff f0 a4 bresser_6in1_decode: : {144} cc b6 38 05 35 05 18 ff 99 ff 19 28 ff af c9 ff 01 21

I take it this is a bresser 5in1 not a 6in1, as msg[15] is always (ff) when flags = (msg[16] & 0x0f) = 0 (Valid Wspeed,Wgust,Wdirection,Battery flag,Temperature Sign flag,Tempurature,Humidity,UV) The 5in1 does not have a UV sensor therefore msg[14]lower nibble and msg[15] would not be used.

when flags = (msg[16] & 0x0f) = 1 (Valid Wgust,Wspeed,Wdirection,Rain) I think the 5in1 stores Rain in increments of 0.4mm this would require 3 bytes msg[12],msg[13],msg[14] and the 6in1 stores Rain in increments of 0.254mm this would require 4 bytes msg[12],msg[13],msg[14],msg[15]

rx1- 999e99 = Temp -0.1C (e=flag) 99 = Humidity 99% rx2- FFAFC9 inverted 5036 = 503.6mm rx3- 000699 = Temp 0.0C (6=flag) 99 =Humidity 99% rx4- FFACC9 inverted 5036 = 503.6mm

flag 0 Pos 0000 Lo flag 6 Pos 0110 Ok flag 8 Neg 1000 Lo flag E Neg 1110 Ok
Temp------^--^ Batt------------^^--^ ?------------------^ These flags seems to be the same as my tests in issue #1214 for the Remote Thermo/Hygro (s_type = 2) (msg[13] >> 2) & 1) == 0 Battery Lo (msg[13] >> 2) & 1) == 1 Battery Ok (msg[13] >> 3) & 1) == 0 Temperature Positive (msg[13] >> 3) & 1) == 1 Temperature Negative

merbanan.txt

[merbanan]

The messages are from issue #2257.

[matthias-bs]

The issue which added it is: #1214 (why is it still open?)

@f4gqk, @RebeckaJohansson, @MacH-21 I saw you had UV readings for a 6in1 sensor, can you please help verify the new code?

I am currently receiving a sensor with 6In1 protocol an UV readings (from some unknown location in the neighbourhood) - the assumption regarding msg[16] seems to be valid for this case, too. (Not rtl_433, but same algorithm.)

11:02:04.571 -> [ 23361][V][WeatherSensor.cpp:209] getMessage(): [SX1276] Data: D4 54 1B 21 10 34 27 18 FF 88 FF 29 28 06 42 87 FF F0 C6 00 00 00 00 00 00 00 00 
11:02:04.604 -> [ 23363][D][WeatherSensor.cpp:211] getMessage(): [SX1276] R [D4] RSSI: -100.5
11:02:04.638 -> [ 23390][D][WeatherSensor.cpp:688] decodeBresser6In1Payload(): UV: 1 0.0
11:02:04.638 -> [ 23396][D][WeatherSensor.cpp:691] decodeBresser6In1Payload(): flags: 0x0
11:02:04.638 -> [ 23403][D][WeatherSensor.cpp:695] decodeBresser6In1Payload(): Wind, Battery, Temperature, Humidity, UV
11:02:04.638 -> [ 23412][D][WeatherSensor.cpp:697] decodeBresser6In1Payload(): Temperature sign: +
11:02:16.570 -> [ 35362][V][WeatherSensor.cpp:209] getMessage(): [SX1276] Data: D4 2A AF 21 10 34 27 18 FF AA FF 29 28 FF BB 89 FF 01 1F 00 00 00 00 00 00 00 00 
11:02:16.604 -> [ 35363][D][WeatherSensor.cpp:211] getMessage(): [SX1276] R [D4] RSSI: -98.0
11:02:16.637 -> [ 35390][D][WeatherSensor.cpp:688] decodeBresser6In1Payload(): UV: 0 0.0
11:02:16.637 -> [ 35396][D][WeatherSensor.cpp:691] decodeBresser6In1Payload(): flags: 0x1
11:02:16.637 -> [ 35403][D][WeatherSensor.cpp:693] decodeBresser6In1Payload(): Wind, Rain