Skip to content

Latest commit

 

History

History
442 lines (304 loc) · 30.2 KB

README.md

File metadata and controls

442 lines (304 loc) · 30.2 KB
Raw

BresserWeatherSensorReceiver

CI CppUTest GitHub release License: MIT

Bresser 5-in-1/6-in-1/7-in-1 868 MHz Weather Sensor Radio Receiver for Arduino based on CC1101, SX1276/RFM95W or SX1262

See the Wiki for additional information.

To allow automatic handling of all Bresser weather station variants, the decoders are tried in the following order until decoding succeeded:

  1. 7-in-1-Decoder
  2. 6-in-1-Decoder
  3. 5-in-1 Decoder
  4. Lightning Sensor Decoder
  5. Water Leakage Sensor Decoder

(The Bresser 5-in-1 Weather Stations seem to use two different protocols - 5-in-1 and 6-in-1.)

Model Type Decoder Function
7002510..12, 9602510 Weather Station decodeBresser5In1Payload()
7902510..12 Weather Station (Base) decodeBresser5In1Payload()
7002531 3-in-1 Professional Wind Gauge / Anemometer decodeBresser6In1Payload() 1)
7002585 Weather Station decodeBresser6In1Payload()
7009999 Thermo-/Hygrometer Sensor decodeBresser6in1Payload()
7009970 Air Quality Sensor PM 2.5 / PM 10 decodeBresser7In1Payload()
7009972 Soil Moisture/Temperature Sensor decodeBresser6In1Payload()
7009973 Pool / Spa Thermometer decodeBresser6In1Payload()
7009975 Water Leakage Sensor decodeBresserLeakagePayload()
7009976 Lightning Sensor decodeBresserLightningPayload()
7009977 CO2 Sensor decodeBresser7In1Payload() 2)
7009978 Air Quality Sensor HCHO / VOC decodeBresser7In1Payload() 3)
7003600 and WSX3001 Weather Station decodeBresser7In1Payload() 4)
7003210 Weather Station decodeBresser7In1Payload()
7803200 Weather Sensor decodeBresser7In1Payload()
7003300 Weather Station decodeBresser7In1Payload()
7803300 Weather Sensor decodeBresser7In1Payload()

Some guesswork:

Numbering Scheme Type
700[25|32|33|36]* Weather Station, Base + Sensor
780[25|32|33]* Weather Station Sensor (Replacement)
790* Weather Station Base (Replacement)
700[99]* Accessory Sensor

1) The flag DATA_COMPLETE must not be set in getData(), otherwise the return value would always indicate a timeout. (I.e. use #define RX_STRATEGY 0 in some of the example sketches.)

2) Request for testing, see #138

3) Request for testing, see #139

4) The part number is specific to the actual variant, i.e. some more characters are appended

Note

Weather sensors which are using the 6-in-1 protocol are actually transmitting two different kind of messages alternately:

  1. Temperature, Humidity, Wind and Battery status
  2. Wind and Rain

All other sensors/protocols are transmitting a single type of message which contains a complete set of data.

The behavior decribed above can be observed with BresserWeatherSensorBasic, which just shows each message as it is received by using the function getMessage().

The other examples are using the function getData(), which buffers and combines messages from the 6-in-1 protocol until a complete set of data — with some configuration options regarding completeness, see BresserWeatherSensorOptions — is available.

Contents

Configuration

Predefined Board Configurations

By selecting a Board and a Board Revision in the Arduino IDE, a define is passed to the preprocessor/compiler. For the boards in the table below, the default configuration is assumed based on this define. I.e. you could could use an Adafruit Feather ESP32-S2 with a CC1101 connected to the pins of your choice of course, but the code assumes you are using it with a LoRa Radio Featherwing with the wiring given below. In some cases (bold entries in the table below) an additional define has to be enabled manually in WeatherSensorCfg.h.

If you are not using the Arduino IDE, you can use the defines in the table below with your specific tool chain to get the same result.

If this is not what you need, you have to switch to Manual Configuration

Setup Board Board Revision Defines
bold: to be enabled manually in WeatherSensorCfg.h		 Radio Module Notes
LILYGO®TTGO-LORA32 V1 "TTGO LoRa32-OLED" "TTGO LoRa32 V1 (No TFCard)" ARDUINO_TTGO_LORA32_V1 SX1276 (HPD13A) -
LILYGO®TTGO-LORA32 V2 "TTGO LoRa32-OLED" "TTGO LoRa32 V2" ARDUINO_TTGO_LoRa32_V2 SX1276 (HPD13A) Only needed for LMIC: Wire DIO1 to GPIO33
LILYGO®TTGO-LORA32 V2.1 "TTGO LoRa32-OLED" "TTGO LoRa32 V2.1 (1.6.1)" ARDUINO_TTGO_LoRa32_v21new SX1276 (HPD13A) -
Heltec Wireless Stick "Heltec Wireless Stick" n.a. ARDUINO_HELTEC_WIRELESS_STICK SX1276 -
Heltec Wireless Stick V3 "Heltec Wireless Stick" n.a. ARDUINO_HELTEC_WIRELESS_STICK_V3 SX1262 -
Heltec WiFi LoRa 32 V2 "Heltec WiFi LoRa 32(V2)" n.a. ARDUINO_HELTEC_WIFI_LORA_32_V2 SX1276 -
Heltec WiFi LoRa 32 V3 "Heltec WiFi LoRa 32(V3)" n.a. ARDUINO_HELTEC_WIFI_LORA_32_V3 SX1262 -
Adafruit Feather ESP32S2 with Adafruit LoRa Radio FeatherWing "Adafruit Feather ESP32-S2" n.a. ARDUINO_ADAFRUIT_FEATHER_ESP32S2 SX1276 (RFM95W) Wiring on the Featherwing:
E to IRQ
D to CS
C to RST
A to DI01
Adafruit Feather ESP32 or Adafruit Feather ESP32 V2 with Adafruit LoRa Radio FeatherWing "Adafruit ESP32 Feather"
"Adafruit Feather ESP32 V2"		 n.a. ARDUINO_FEATHER_ESP32 SX1276 (RFM95W) Wiring on the Featherwing:
A to RST
B to DIO1
D to IRQ
E to CS
ThingPulse ePulse Feather with Adafruit LoRa Radio FeatherWing "Thingpulse ePulse Feather" n.a. ARDUINO_THINGPULSE_EPULSE_FEATHER SX1276 (RFM95W) Wiring on the Featherwing:
A to RST
B to DIO1
D to IRQ
E to CS
DFRobot FireBeetle with FireBeetle Cover LoRa Radio 868MHz "FireBeetle-ESP32" n.a. ARDUINO_DFROBOT_FIREBEETLE_ESP32 & DFROBOT_COVER_LORA SX1276 (LoRa1276) Wiring on the cover:
D2 to RESET
D3 to DIO0
D4 to CS
D5 to DIO1

Additional connections required for battery voltage measurement.
M5Stack Core2 with M5Stack Module LoRa868 "M5Core2" n.a. ARDUINO_M5STACK_CORE2 SX1276
(RA-01H)		 Only needed for LMIC - wiring on the LoRa868 Module:
DIO1 to GPIO35

"M5Unified" must be installed
M5.begin()is called to control power management
ESP32-S3 PowerFeather with Adafruit LoRa Radio FeatherWing "ESP32-S3 PowerFeather" n.a. ARDUINO_ESP32S3_POWERFEATHER SX1276 (RFM95W) Wiring on the Featherwing:
A to RST
B to DIO1
D to IRQ
E to CS

"PowerFeather-SDK" must be installed
Board.init(); is called to control power management
Adafruit Feather RP2040 with Adafruit LoRa Radio FeatherWing "Adafruit Feather RP2040" n.a. ARDUINO_ADAFRUIT_FEATHER_RP2040 SX1276 (RFM95W) Wiring on the Featherwing:
A to RST
B to DIO1
D to IRQ
E to CS

External voltage divider required for battery voltage measurement.

The preprocessor will provide some output regarding the selected configuration if enabled in the Arduino IDE's Preferences ("Verbose Output"), e.g.

ARDUINO_ADAFRUIT_FEATHER_ESP32S2 defined; assuming RFM95W FeatherWing will be used
[...]
Receiver chip: [SX1276]
Pin config: RST->0 , CS->6 , GD0/G0/IRQ->5 , GDO2/G1/GPIO->11

Note

The AVR architecture — including Adafruit Feather 32u4 RFM95 LoRa Radio — is no longer supported due to code size.

User-Defined Configuration

See WeatherSensorCfg.h for configuration options.

  • Set the desired radio module by (un-)commenting USE_CC1101, USE_SX1262 or USE_SX1276.

    SX1276 is compatible with RFM95W and HPD13A.

  • Set the I/O pinning according to your hardware

    Define Radio Module Configuration
    ESP32 user-defined generic, used for ESP32 boards if none of the above is defined
    ESP8266 user-defined generic, used for ESP8266 boards if none of the above is defined

  • Data from multiple sensors can be received by setting MAX_SENSORS_DEFAULT to an appropriate value in WeatherSensorCfg.h.

    e.g. #define MAX_SENSORS_DEFAULT 1

  • The sensors to be handled can be configured by two ways:

    • Add any unwanted sensor IDs to the exclude list SENSOR_IDS_EXC

      e.g. #define SENSOR_IDS_EXC { 0x39582376 }

    • Specify the wanted sensors explicitly in the include list SENSOR_IDS_EXC - if empty, all sensors will be used

      e.g. #define SENSOR_IDS_INC { 0x83750871 }

  • Unused decoders can be disabled to save computation time/power by commenting out:

    e.g. //#define BRESSER_LEAKAGE

See How Sensor Reception works for a detailed description.

Rain Statistics

The weather sensors transmit the accumulated rainfall since the last battery change or reset. This raw value is provided as rain_mm. To provide the same functionality as the original weather stations, the class RainGauge (see RainGauge.h) is used to calculate

  • hourly (past 60 minutes) rainfall,
  • daily rainfall,
  • weekly rainfall,
  • and monthly rainfall.

These values are named rain_h, rain_d, rain_w and rain_m in the MQTT software examples.

Note

Time and date must be set correctly in order to reset the daily, weekly and monthly rain values correctly. This is achieved by setting the real time clock (RTC) from an available time source, e.g. via SNTP from a network time server if the device has internet connection via WiFi. The user must set the appropriate time zone (TZ_INFO) in the sketch.

See Implementing Rain Gauge Statistics for more details.

Lightning Sensor Post-Processing

The lightning sensor transmits the accumulated number of strikes and the estimated distance from the storm front (at the time of the last strike) at an interval. The post-processing algorithm implemented in the class Lightning (see Lightning.h) calculates the number of events during the past 60 minutes — using the same algorithm as the rain statistics — and stores information of the last event:

  • Timestamp (UTC),
  • Estimated distance and
  • Number of strikes since the previous event.

Note

Time and date must be set correctly in order to store the timestamp. This is achieved by setting the real time clock (RTC) from an available time source, e.g. via SNTP from a network time server if the device has internet connection via WiFi.

SW Examples

BresserWeatherSensorBasic

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.

BresserWeatherSensorWaiting

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).

BresserWeatherSensorCallback

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).

BresserWeatherSensorOptions

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).

BresserWeatherSensorMQTT

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)

IoTMQTTPanel_Bresser_5-in-1

BresserWeatherSensorMQTTCustom

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.

BresserWeatherSensorMQTTWiFiMgr

Same core functionality as BresserWeatherSensorMQTT, but instead of using static WiFi- and MQTT-connection data, WiFiManager is used instead.

Note:

When using the sketch on a device for the first time, you must format the flash file system (SPIFFS) first, otherwise the configuration cannot be saved.

Configuration:

  • Access Point SSID: ESPWeather-<chip_id>
  • Access Point Password: password
  • Configuration URL: http://192.168.4.1/ (The browser must be connected to the access point above!)

Please refer to the WiFiManager documentation for details!

After a successful setup, you can perform two consecutive resets (within 10 seconds) to enable WiFiManager for changing the configuration. This is achieved by using ESP_DoubleResetDetector.

WiFiManager Start Screen
WiFiManager Configuration Screen

BresserWeatherSensorDomoticz

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 Domoticz virtual sensors (see https://www.domoticz.com/wiki/Managing_Devices#Temperature and https://www.domoticz.com/wiki/Managing_Devices#Weather).

BresserWeatherSensorM5Core2

Example for BresserWeatherSensorReceiver on M5Stack Core2 with M5Stack Module LoRa868 (and optionally M5Go Bottom2). Using getMessage() for non-blocking reception of a single data message. Weather sensor data is presented on the display.

BresserWeatherSensorM5Core2

MQTT Integrations

Home Assistant

Shadowpost provided a Home Assistant configuration which can be modified as required:
Bresser_HA_MQTT_custom_config.yaml

Debug Output Configuration

See Debug Output Configuration in Arduino IDE

HW Examples

Note: The SX1276/RFM95W also supports FSK modulation and thus can be used to receive the weather sensor data.

ESP8266 D1 Mini with CC1101

Bresser5in1_CC1101_D1-Mini

Pinout ESP8266 WeMos D1-Mini with cc1101

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:

Note 2: Make sure to use the 868MHz version!

Adafruit Feather ESP32S2 with Adafruit LoRa Radio FeatherWing

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
  • ADA5400 - Adafruit ESP32 Feather V2 - 8MB Flash + 2 MB PSRAM - STEMMA QT

Solder-Bridges on the Module/Wing:

  • E to IRQ
  • D to CS
  • C to RST
  • A to DI01

Adafruit Feather ESP32 or ThingPulse ePulse Feather with Adafruit LoRa Radio FeatherWing

ePulse_Feather+FeatherWing

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
  • ADA3405 - Adafruit HUZZAH32 – ESP32 Feather Board
  • B0BSC1PVL4 - ThingPulse ePulse Feather

Solder-Bridges on the Module/Wing:

  • A to RST
  • B to DIO1
  • D to IRQ
  • E to CS

Adafruit RFM95W LoRa Radio Transceiver Breakout

Note: Make sure to use the 868MHz version!

  • ADA3072 - 868/915 MHz version
  • ADA3073 - 433 MHz version
  • RF connector
  • Antenna

See Adafruit RFM69HCW and RFM9X LoRa Packet Radio Breakouts - Pinouts.

DFRobot FireBeetle ESP32 with FireBeetle Cover LoRa Radio 868MHz

firebeetle_esp32+cover_lora Note: Stacking headers were included with TEL0125.

Note: Make sure to use the 868MHz version!

  • DFR0478 - FireBeetle ESP32 IoT Microcontroller
  • TEL0125 - LoRa Radio 868MHz - FireBeetle Covers

Solder-Bridges on the Cover:

  • D2 to RESET
  • D3 to DIO0
  • D4 to CS
  • D5 to DIO1

Antennas and RF Connectors

The required antenna depends on the signal path between weather sensor and 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.

Software Build Tutorial

See BUILD

Source Documentation

https://matthias-bs.github.io/BresserWeatherSensorReceiver/

Legal

This project is in no way affiliated with, authorized, maintained, sponsored or endorsed by Bresser GmbH or any of its affiliates or subsidiaries.