johnnyfleet commented 2 years ago

Hi there, I've got a National Geographic branded bresser 5-in-1 weather station (this model). I run rtl_433 using the docker image (hertzg/rtl_433_docker). It has been working great until about 4 days ago I got odd behaviour where I was getting bad readings intermittently for temperature and humidity.

Below is an extract of the readings, notice almost every other reading the temperature shows 65.5C and then goes back (correctly) to 25.9C.

{"time" : "1643423944.650275", "model" : "Bresser-6in1", "id" : 415241188, "channel" : 0, "battery_ok" : 1, "temperature_C" : 25.900, "humidity" : 51, "sensor_type" : 1, "wind_max_m_s" : 1.800, "wind_avg_m_s" : 1.600, "wind_dir_deg" : 68, "mic" : "CRC"}
{"time" : "1643423956.650543", "model" : "Bresser-6in1", "id" : 415241188, "channel" : 0, "battery_ok" : 1, "temperature_C" : 65.500, "humidity" : 121, "sensor_type" : 1, "wind_max_m_s" : 1.800, "wind_avg_m_s" : 1.600, "wind_dir_deg" : 68, "mic" : "CRC"}
{"time" : "1643423980.650375", "model" : "Bresser-6in1", "id" : 415241188, "channel" : 0, "battery_ok" : 1, "temperature_C" : 65.500, "humidity" : 121, "sensor_type" : 1, "wind_max_m_s" : 2.100, "wind_avg_m_s" : 1.900, "wind_dir_deg" : 68, "mic" : "CRC"}
{"time" : "1643423992.650353", "model" : "Bresser-6in1", "id" : 415241188, "channel" : 0, "battery_ok" : 1, "temperature_C" : 26.000, "humidity" : 50, "sensor_type" : 1, "wind_max_m_s" : 2.100, "wind_avg_m_s" : 1.900, "wind_dir_deg" : 68, "mic" : "CRC"}
{"time" : "1643424004.650342", "model" : "Bresser-6in1", "id" : 415241188, "channel" : 0, "battery_ok" : 1, "temperature_C" : 65.500, "humidity" : 121, "sensor_type" : 1, "wind_max_m_s" : 0.600, "wind_avg_m_s" : 0.600, "wind_dir_deg" : 90, "mic" : "CRC"}
{"time" : "1643424016.650369", "model" : "Bresser-6in1", "id" : 415241188, "channel" : 0, "battery_ok" : 1, "temperature_C" : 26.000, "humidity" : 50, "sensor_type" : 1, "wind_max_m_s" : 1.700, "wind_avg_m_s" : 1.400, "wind_dir_deg" : 68, "mic" : "CRC"}
{"time" : "1643424052.650531", "model" : "Bresser-6in1", "id" : 415241188, "channel" : 0, "battery_ok" : 1, "temperature_C" : 65.500, "humidity" : 121, "sensor_type" : 1, "wind_max_m_s" : 1.300, "wind_avg_m_s" : 1.000, "wind_dir_deg" : 270, "mic" : "CRC"}

When visualised you can see the error (visual over 1 hour)

What I did notice however was the rainfall_mm was no longer being recognised. Notice how the rain_mm field is no longer in the message packet shown in the text sample above.

Looking into the records in my Influxdb instance (which I store the records in) the rainfall measurement abruptly stopped a few days ago with the last reading 998.4mm. This also coincides with when then temperature and humidity goes wrong.

Looking at the official base station that came with the weather station the display reads the temperatures correctly.

I have a theory that the rainfall reached > 1000mm for readings, and that has made the overall message longer. This is then screwing with the other fields as the mapping doesn't line up anymore. The intermittent issue makes sense as I've noted on my readings in the past that some fields aren't always transmitted with each message (for some reason).

But...this is all just a theory. I'm not sure on the best way to help troubleshoot further.

I expect I can reset the device by removing the batteries for a while, which will reset the rainfall counter to 0, but I'd rather first see if I can help flag this issue and help fix is with diagnosis while I'm experiencing it to help avoid for others.

Please point me to some instructions of give me guidance on how I can help provide better data to troubleshoot further.

Cheers.

johnnyfleet commented 2 years ago

For reference it is configured as the Bresser 6-in-1 device profile (172)

johnnyfleet commented 2 years ago

I hope this helps. I followed some of the guidance here to save output of all devices (-S all).

I've saved several samples here to help analyse further.

File References

Temp Correct @ 19.2C

Temp Incorrect @ 65.5C

60 second sample

Following the guidance here

I ran through rtl_sdr -A <xxx> but I didn't see anything obvious that jumped out. Mind you, I'm new to this so may be overlooking some obvious things...

zuckschwerdt commented 2 years ago

There are at least two different message types:

24 seconds interval for temperature, hum, uv and rain (alternating messages)
12 seconds interval for wind data (every message)

Rain is reported when the temperature field is not valid (0xff). It's either "temperature_C" and "humidity" or "rain_mm". But indication here is that this is not the correct approach, rain might overflow (into temp?), and there could be an identifier if temp/hum or rain somewhere else.

To debug this further the best option is to run with -R 172:vv to see the full messages. E.g. rtl_433 -R 172:vv g030_868M_1000k.cu8 shows:

bresser_6in1_decode: {144} 84 85 18 c0 13 e4 18 ff ff ff 06 88 fe ff bb ff 01 d5

Put that in a BitBench with a format string of

DIGEST:8h8h ID:8h8h8h8h FLAGS:4h BATT:1b CH:3d WSPEED:~8h~4h ~4h~8h WDIR:12h ?4h TEMP:8h.4h ?4h HUM:8h UV?~12h ?4h CHKSUM:8h
DIGEST:8h8h ID:8h8h8h8h FLAGS:4h BATT:1b CH:3d WSPEED:~8h~4h ~4h~8h WDIR:12h ?4h RAINFLAG:8h RAIN:8h8h UV:8h8h CHKSUM:8h

Looks good, but it's a special state we have not seen before: If this should be a temp/hum message, temperature is 0xfef(f) and humidity is 0xbb, or if this is a rain message: the temperature invalid is 0xfe (instead of the expected 0xff) and rain is 0xffbb, which also looks invalid.

It looks like this is a third type, neither temp/hum or rain available? Can you watch this over some time, collect the codes in BitBench and see what the pattern is?

zuckschwerdt commented 2 years ago

Ah, now I see. This actually a wind message but with the quirk that temp and hum are not valid?

DIGEST:8h8h ID?8h8h8h8h FLAGS:4h BATT:1b CH:3d WSPEED:~8h~4h ~4h~8h WDIR:12h ?4h TEMP8h.4h ?4h HUM8h UV?~12h ?4h CHKSUM:8h

However, watch this over some time, my suspicion is that temp=0xff -> rain valid and additionally temp=0xfe -> neither temp or rain valid.

johnnyfleet commented 2 years ago

Thanks for above. I did a little extra digging into this. Did a resync of the base station and it does seem from display that there are two types of messages:

Wind speed, wind direction, temp & humidity
Wind speed, wind direction and rainfall

When resyncing I saw those different displays reset at alternating times depending on when I told it to resync.

So yes, I think from what I understand of your message above, the message sent with temp is correct and being read correctly (19C) but the second message is being misinterpreted as another temp reading (hence send 65C temp on an alternating fashion and no rainfall measurement). I think this does still fall back to the fact that the cumulative rainfall measurments have gone over 1000mm. The manual states it can read up to 9999mm cumulative (I assume it resets the counter to 0 then). So I wonder if the original rule assumed 4 digit max (with 1 d.p.) and now it might be 5 digits max (with 1 d.p) or still 4 digit max but precision dropped to 0 d.p.?

Apologies, I'm still trying to figure out all the message formatting and ways to interpret in BitBench. (Is there further info/documentation somewhere to help understand what to do to manually try and adjust it?)

In the meantime...more data...

I captured some further 2 min samples today - this time I manually poured water into the rain bucket, which registered 6mm on the official display. Hopefully this can help to troubleshoot further.

Sample 1 - 120s - this was a normal reading on a dry day - to act as the baseline
Sample 2 - 120s - this I started and then shortly after manually poured in water to the rain meter over about 10-20s. This measured 6mm during that time on the official display.
Sample 3 - 120s - Added another small amount of water. This time is measured 0.4mm on the internal reading. This hopefully can check for minor rainfall (where 1 decimal place e.g. <1mm).

Hopefully this can help spot what might be wrong with the rainfall.

johnnyfleet commented 2 years ago

I took an extract of the above sample files and placed into BitBench.

{144} 34 f7 18 c0 13 e4 18 fa 96 fb 02 28 24 40 63 ff f0 ad [Sample 1 - baseline reading - temperature message]
{144} 58 4c 18 c0 13 e4 18 f8 8e f9 06 88 fe ff bb ff 01 53 [Sample 1 - baseline reading - rainfall message]
{144} 4f 80 18 c0 13 e4 18 fb 88 fc 31 58 24 40 62 ff f0 5b [Sample 2 - after 6mm water poured - temperature message]
{144} 26 47 18 c0 13 e4 18 fd ee fd 33 88 fe fe fb ff 01 7e [Sample 2 - after 6mm water poured - rainfall message]
{144} 73 16 18 c0 13 e4 18 f9 ac fa 02 28 24 90 59 ff f0 53 [Sample 3 - after 0.4mm water poured - temperature message]
{144} 78 6d 18 c0 13 e4 18 fa f9 fb 00 08 fe fe f7 ff 01 2f [Sample 3 - after 0.4mm water poured - rainfall message]

This might help spot more easily what is changing as we step from Baseline > +6mm > +~0.4mm

zuckschwerdt commented 2 years ago

Very good, this does close the case ;) A temp=0xff, or here now temp=0xfe is not the rain message flag but the upper bits of rain fall. Still not sure how the distinction is flagged, might be the last byte at the UV light field. (above BitBench updated)

zuckschwerdt commented 2 years ago

Fixed now, two more rain digits added, also an additional output "flags" with the very last data nibble.

Please keep an eye on that flags output, it seems to indicate something, the values are usually 0/1 but 2,3,5 also seen.

johnnyfleet commented 2 years ago

Awesome. thanks. I'll try out tomorrow and confirm.

johnnyfleet commented 2 years ago

A sample today with the latest code seems to be looking a lot happier.

bresser_6in1_decode: {144} 83 5f 18 c0 13 e4 18 fc 7f fc 02 28 25 30 61 ff f0 d2 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2022-02-01 12:48:50
model     : Bresser-6in1 id        : 18c013e4
channel   : 0            Battery   : 1             Temperature: 25.3 C       Humidity  : 61            Sensor type: 1            Wind Gust : 3.8 m/s
Wind Speed: 3.0 m/s      Direction : 22            Flags     : 0             Integrity : CRC
pulse_demod_pcm(): Bresser Weather Center 6-in-1, 7-in-1 indoor, new 5-in-1, 3-in-1 wind gauge, Froggit WH6000, Ventus C8488A
bitbuffer:: Number of rows: 1 
[00] {364} 55 55 55 55 55 16 ea 41 af 8c 60 09 f2 0c 7e 3f fe 01 14 12 98 30 ff f8 69 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Exact bit width (in us) is 121.74 vs 124.00, 38 bit preamble
bresser_6in1_decode: {144} 7c 1b 18 c0 13 e4 18 fc 7f fc 02 28 fe fe f7 ff 01 84 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2022-02-01 12:49:02
model     : Bresser-6in1 id        : 18c013e4
channel   : 0            Battery   : 1             Sensor type: 1            Wind Gust : 3.8 m/s       Wind Speed: 3.0 m/s       Direction : 22
Rain      : 1010.8 mm    Flags     : 1             Integrity : CRC
pulse_demod_pcm(): Bresser Weather Center 6-in-1, 7-in-1 indoor, new 5-in-1, 3-in-1 wind gauge, Froggit WH6000, Ventus C8488A
bitbuffer:: Number of rows: 1 
[00] {363} 55 55 55 55 55 16 ea 3e 0d 8c 60 09 f2 0c 7e 3f fe 01 14 7f 7f 7b ff 80 c2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Exact bit width (in us) is 121.76 vs 124.00, 38 bit preamble
bresser_6in1_decode: {144} 7d 2b 18 c0 13 e4 18 fc 7b fc 06 88 25 40 61 ff f0 62 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2022-02-01 12:49:14
model     : Bresser-6in1 id        : 18c013e4
channel   : 0            Battery   : 1             Temperature: 25.4 C       Humidity  : 61            Sensor type: 1            Wind Gust : 3.8 m/s
Wind Speed: 3.4 m/s      Direction : 68            Flags     : 0             Integrity : CRC
pulse_demod_pcm(): Bresser Weather Center 6-in-1, 7-in-1 indoor, new 5-in-1, 3-in-1 wind gauge, Froggit WH6000, Ventus C8488A
bitbuffer:: Number of rows: 1 
[00] {364} 55 55 55 55 55 16 ea 3e 95 8c 60 09 f2 0c 7e 3d fe 03 44 12 a0 30 ff f8 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Exact bit width (in us) is 121.76 vs 124.00, 38 bit preamble
bresser_6in1_decode: {144} 6b d6 18 c0 13 e4 18 fa 7f fa 04 58 fe fe f7 ff 01 56 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2022-02-01 12:49:26
model     : Bresser-6in1 id        : 18c013e4
channel   : 0            Battery   : 1             Sensor type: 1            Wind Gust : 5.8 m/s       Wind Speed: 5.0 m/s       Direction : 45
Rain      : 1010.8 mm    Flags     : 1             Integrity : CRC
pulse_demod_pcm(): Bresser Weather Center 6-in-1, 7-in-1 indoor, new 5-in-1, 3-in-1 wind gauge, Froggit WH6000, Ventus C8488A
bitbuffer:: Number of rows: 1 
[00] {364} 55 55 55 55 55 16 ea 35 eb 0c 60 09 f2 0c 7d 3f fd 02 2c 7f 7f 7b ff 80 ab 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I'll update my main setup today with the latest docker version when ready and let it run for a few days to see how it looks in Influx compared to historicals.

Thanks

johnnyfleet commented 2 years ago

Looking good after a few days piped into influxdb. You can see when things went wrong originally

thanks team for all your wonderful support.

zuckschwerdt commented 2 years ago

No problem, thanks for the feedback to figure this out!

And if you ever find out what that last digit "flags" could mean let us know :)

tnsaul commented 2 years ago

Just an FYI as a breadcrumb for other looking for this issue. I have a Digitech XC0434 5in1 Weather Station from my local Australian retailer (Jaycar). It has the same >999mm of rain issue as that reported above; we had that in the last three days of solid rain. Thanks to johnnyfleet for his investigation and to the team for the fix. I've downloaded the patched code, compiled it (RPI) and now have good data into Influx. Great little product.

zuckschwerdt commented 2 years ago

Thanks for the feedback. The next release is to come shortly and will include this fix.

derhappy commented 2 years ago

I just ran into the same issue today. First of all thanks to both of you for investigating and fixing the issue. Is there any release including the fix already? I' working with the docker version (hertzg / rtl_433_docker) and it looks like it's still the version from December 2021.

johnnyfleet commented 2 years ago

I'll let others comment on time frames for a new release.

However if you're using that dockerised version you don't have to wait.

I use image: hertzg/rtl_433:debian-master in my docker-compose file.

That is built against the master branch of this repo so scoops up the latest and greatest fixes, including this one.

derhappy commented 2 years ago

Huge thanks johnnyfleet, this is exactly what I needed! I tried updating to latest, but it did not work. Waiting some more minutes for your answer would have saved me a lot of trouble. When latest did not work I tried installing the latest rtl_433 from a new repository.. Didn't go well. Long story short, I completely reinstalled my OS, slapped on docker and hertzg/rtl_433:debian-master and it's working like a charm.

johnnyfleet commented 2 years ago

Glad you got it all worked out in the end.

The credit really belongs both to the team here for a great program and also hertzg for packaging nicely in docker with multiple flavours.

zuckschwerdt commented 2 years ago

The credit really belongs both to the team here for a great program and also hertzg for packaging nicely

Happy to extend that to all the users and contributors exploring, documenting, and helping!

merbanan / rtl_433

Bresser 5-in-1 issues when rainfall goes over 999mm #1969

File References

Temp Correct @ 19.2C

Temp Incorrect @ 65.5C

60 second sample

In the meantime...more data...