merbanan / rtl_433

Program to decode radio transmissions from devices on the ISM bands (and other frequencies)
GNU General Public License v2.0
6.09k stars 1.32k forks source link

Support for Bresser Explore Scientific 7 in 1 Weather Center at 868 MHz #1492

Closed Tuxyso closed 3 years ago

Tuxyso commented 4 years ago

Hi!

I own:

https://www.bresser.de/en/EXPLORE-SCIENTIFIC-professional-7-in-1-Wi-Fi-Weather-Centre-with-Light-Intensity-and-UV-Measurement-Function.html

The sensor transmits data at 868 MHz. With

rtl_433 -f 868.3M

I do not receive any data.

Can I provide some raw data to you so that you can add support?

Kind regards, Tuxyso

Tuxyso commented 4 years ago

Just recognized another strange behaviour: Rain (mm) is not in mqtt output:

rtl_433/Bresser-7in1outdoor/44906 {"time":"2020-10-03 17:22:53","model":"Bresser-7in1outdoor","id":44906,"temperature_C":11.4,"humidity":97,"wind_max_m_s":0,"wind_avg_m_s":0,"wind_dir_deg":287,"light_klx":4.5,"mic":"CRC"}

zuckschwerdt commented 4 years ago

"Bresser-7in1outdoor" is not the current code, it should read "Bresser-7in1".

Tuxyso commented 4 years ago

I have started rtl_433 (your testing branch) with the following options: ./rtl_433 -f 868.3M -s 1000k -C si -F "mqtt://localhost:1883,events=rtl_433[/model][/id]" and got the output from above.

rtl_433/Bresser-7in1outdoor/44906 is the MQTT topic. That seems OK for me. The point is: rain field is missing.

zuckschwerdt commented 4 years ago

Your copy of the branch seems outdated, perhaps git fetch ; git reset --hard origin/feat-bresser6in1 when you are on the branch. Otherwise remove the local branch and checkout fresh.

konserninjohtaja commented 4 years ago

Could this work with Bresser 6in1(https://www.bresser.de/en/Weather-Time/Weather-Center/BRESSER-Professional-WIFI-Weather-Centre-6in1.html) too?

zuckschwerdt commented 4 years ago

@Tuxyso so flags is always 2 for this sensor? Is that the indoor unit, there is no UV on that, right? what about the soil probe?

zuckschwerdt commented 4 years ago

@konserninjohtaja there is no interface to the Weather Center (display unit), but the sensor for that is the 6-in-1 outdoor and should work, yes.

konserninjohtaja commented 4 years ago

@konserninjohtaja there is no interface to the Weather Center (display unit), but the sensor for that is the 6-in-1 outdoor and should work, yes.

Which branch should i try?

zuckschwerdt commented 4 years ago

https://github.com/merbanan/rtl_433/tree/feat-bresser6in1 from #1225

Tuxyso commented 4 years ago

@Tuxyso so flags is always 2 for this sensor? Is that the indoor unit, there is no UV on that, right? what about the soil probe?

That's right, FLAG ist always 2, as you can see in the Bitbench of the sample.

Length (the value {XXX} is between 240-242 for the indoor sensor. Probably that helps for identification?

Indoor sensor has no UV.

Indoor sample:

indoor-sample.txt

In the next days I will check the soil sensor.

zuckschwerdt commented 4 years ago

The length sadly isn't reliable, it's mostly the lead-out which is detected wrong. It will always depend on the reset limit.

Tuxyso commented 3 years ago

What has to be done to get this request closed? Is support for the Bresser 7in1 already in the main branch?

zuckschwerdt commented 3 years ago

Yes, both 7in1 and 6in1 (indoor sensor) are merged. Please test and then close.

Tuxyso commented 3 years ago

Thanks for your fast reply. Outdoor and indoor sensor work very reliable. But I think support for the moisture sensor is not integrated yet?!

zuckschwerdt commented 3 years ago

It should be: https://github.com/merbanan/rtl_433/blob/master/src/devices/bresser_6in1.c#L180

Tuxyso commented 3 years ago

I can confirm that also the moisture sensors works well with the current version from git (rtl_433 version 20.11-12-ga20cd1a6 branch master at 202012232126 i). But probably the fields humidity and moisture are flipped:

The 16 level scale for moisture is shown as "humidity" and the value for humidity shown as moisture.

Example output:

rtl_433/Bresser-6in1/409993443 {"time":"2021-01-02 22:28:23","model":"Bresser-6in1","id":409993443,"channel":6,"battery_ok":0,"temperature_C":23.8,"humidity":5,"sensor_type":4,"moisture":27,"wind_max_m_s":0,"wind_avg_m_s":0,"wind_dir_deg":0,"mic":"CRC"}

In this case on my weather station (23,8 °C and humidity of 27% is shown).

zuckschwerdt commented 3 years ago

Yes, humidity is the raw value from the humidity field in the packet. Perhaps we should hide that when a valid moisture is shown? I guess having normalized humidity for standard processing in automation could be useful too?

Who is using this already? Please let me know. I might flip the fields otherwise.

Tuxyso commented 3 years ago

Just for clarification:

This display on the weather station IMG_5415

corresponds to

time : 2021-01-03 13:24:15 model : Bresser-6in1 id : 187000e3 channel : 6 Battery OK: 0 Temperature: 21.6 C Humidity : 7 Sensor type: 4 Moisture : 40 Wind Gust : 0.0 m/s Wind Speed: 0.0 m/s Direction : 0 Integrity : CRC

I think both values are useful, but I would state that "humidity" in the output should be identical to the "humidity" value for the sensor on the weather station. Probably instead of "moisture" you could name the 16 level value "Moisture Level"

zuckschwerdt commented 3 years ago

We have three other devices that report moisture:

All with "moisture" as percentage. While moisture might look like humidity for an application or display it's a distinctive physical property an should likely not be reported as "humidity". I propose to show a "moisture" percentage here, no level, and no "humidity".

zuckschwerdt commented 3 years ago

I'm just seeing that Springfield moisture is 0-10. We should change that to percentage also. Four decoders with a normalized interface for (soil) moisture is good news for application implementers.

zuckschwerdt commented 3 years ago

See #1595 for the change. It will be open for discussion for a week or so.

merbanan commented 3 years ago

This looks done. Closing issue.