Bresser 5-in-1/6-in-1 868 MHz Weather Sensor Radio Receiver for Arduino based on CC1101 or SX1276/RFM95W
The Bresser 5-in-1 Weather Stations seem to use two different protocols. First, the 6-in-1 decoder is tried. If this fails, the 5-in-1 decoder is tried.
| Model | Sensor Type | Decoder Function |
|---|---|---|
| 7002510..12 | Weather | decodeBresser5In1Payload() |
| 7902510..12 | Weather | decodeBresser5In1Payload() |
| 7002585 | Weather | decodeBresser6In1Payload() |
| 7009999 | Thermo-/Hygrometer | decodeBresser6in1Payload() |
| 7009972 | Soil Moisture/Temperature | decodeBresser6In1Payload() |
Configure the desired radio module by (un-)commenting USE_CC1101 or USE_SX1276 in WeatherSensorCfg.h.
Uses default configuration src/WeatherSensorCfg.h
Really a very basic example. Good for testing the SW build, wiring and sensor reception/decoding. Output is printed to the serial console (example).
Data is provided by the getMessage()-method, which returns almost immediately (i.e. after a small multiple of expected time-on-air), even if no data has been received.
Uses default configuration src/WeatherSensorCfg.h
Very similar to BresserWeatherSensorBasic, but data is provided by the getData()-method, which waits until a complete set of data has been received or a timeout occurred. Output is printed to the serial console (example).
Uses default configuration src/WeatherSensorCfg.h
Based on BresserWeatherSensorWaiting, but repeatedly invokes a callback function while waiting for data. In this example, in each iteration of the wait-loop, a dot is printed. Output is printed to the serial console (example).
Uses default configuration src/WeatherSensorCfg.h
Based on BresserWeatherSensorWaiting, but demonstrates the different options of the getData()-method which defined if enough sensor data has been received before returning. Output is printed to the serial console (example).
Uses default configuration src/WeatherSensorCfg.h
This is finally a useful application.
At startup, first a WiFi connection and then a connection to the MQTT broker is established. (Edit secrets.h accordingly!) Then receiving data of all sensors (as defined in NUM_SENSORS, see WeatherSensorCfg.h) is tried periodically. If successful, sensor data is published as MQTT messages, one message per sensor.
If the sensor ID can be mapped to a name (edit sensor_map[]), this name is used as the MQTT topic, otherwise the ID is used. From the sensor data, some additional data is calculated and published with the extra topic.
The data topics are published at an interval of >DATA_INTERVAL. The status and the radio topics are published at an interval of STATUS_INTERVAL.
If sleep mode is enabled (SLEEP_EN), the device goes into deep sleep mode after data has been published. If AWAKE_TIMEOUT is reached before data has been published, deep sleep is entered, too. After SLEEP_INTERVAL, the controller is restarted.
MQTT publications:
<base_topic>/data/<ID|name> sensor data as JSON string - see publishWeatherdata()
<base_topic>/radio CC1101 radio transceiver info as JSON string - see publishRadio()
<base_topic>/status "online"|"offline"|"dead"$
$ via LWT
<base_topic> is set by #define HOSTNAME ...
<base_topic>/data JSON Example:
{"sensor_id":12345678,"ch":0,"battery_ok":true,"humidity":44,"wind_gust":1.2,"wind_avg":1.2,"wind_dir":150,"rain":146}
Dashboard with IoT MQTT Panel (Example)
Customized version of the example BresserWeatherSensorMQTT
The file BresserWeatherSensorReceiver/examples/BresserWeatherSensorMQTTCustom/src/WeatherSensorCfg.h has been customized (from BresserWeatherSensorReceiver/src/WeatherSensorCfg.h.
See examples/BresserWeatherSensorMQTTCustom/Readme.md for details.
Based on BresserWeatherSensorMQTT. Provides sensor data as MQTT messages via WiFi to Domoticz (https://domoticz.com/) (MQTT plugin for Domoticz required). The MQTT topics are designed for using with Domticz virtual sensors (see https://www.domoticz.com/wiki/Managing_Devices#Temperature and https://www.domoticz.com/wiki/Managing_Devices#Weather).
Pinout ESP8266 WeMos D1-Mini with cc1101
Texas Instruments CC1101 Product Page
Note: CC1101 Module Connector Pitch is 2.0mm!!!
Unlike most modules/breakout boards, most (if not all) CC1101 modules sold on common e-commerce platforms have a pitch (distance between pins) of 2.0mm. To connect it to breadboards or jumper wires with 2.54mm/100mil pitch (standard), the following options exist:
- solder wires directly to the module
- use a 2.0mm pin header and make/buy jumper wires with 2.54mm at one end and 2.0mm at the other (e.g. Adafruit Female-Female 2.54 to 2.0mm Jumper Wires)
- use a 2.0mm to 2.54 adapter PCB
Note 2: Make sure to use the 868MHz version!
Note: Make sure to use the 868MHz version!
- ADA3231 - Adafruit LoRa Radio FeatherWing - RFM95W 900 MHz - RadioFruit
- ADA3232 - Adafruit LoRa Radio FeatherWing - RFM95W 433 MHz - RadioFruit
- ADA5303 - Adafruit ESP32-S2 Feather with BME280 Sensor - STEMMA QT - 4MB Flash + 2 MB PSRAM
Solder-Bridges on the Module/Wing:
- E to IRQ
- D to CS
- C to RST
- A to DI01
Note: Make sure to use the 868MHz version!
See Adafruit RFM69HCW and RFM9X LoRa Packet Radio Breakouts - Pinouts.
Note: The RFM95W also supports FSK modulation and thus can be used to receive the weather sensor data.
The required antenna depends on the signal path between weather sensor and CC1101 or RFM95W receiver.
Some options are:
- wire antenna
- spring antenna (helical wire coil)
- rubber antenna
See Adafruit Tutorial - Antenna Options for wire antenna lengths and uFL connector soldering.
The Data Alliance website helped to sort out my RF connector confusion:
Applications of MHF Connectors & Cables
The MHF series of RF micro-connectors (mating heights listed below are the maximum):
- MHF1 (also known as MHF) has a Mating Height of 2.5mm
- MHF2 has a Mating Height of 2.1mm
- MHF3 has a Mating Height of 1.6mm
- MHF4 has a Mating Height of 1.2mm
MHF3 connector is compatible with a W.FL connector while MHF2 connector is equivalent of U.FL connector. The MHF4 cable connector is the smallest while MHF1 connector is the largest which is comparable to a U.FL connector.
Personally I prefer the SMA connector over the uFL connector - but be aware of the (usual) male/female connector types and the normal/reverse polarity types. See SMA vs RP-SMA what is the difference? by Digikey.
See issue matthias-bs#12 (comment)