Skip to content

Home

Jump to bottom
Matthias Prinke edited this page Sep 8, 2022 · 56 revisions

Welcome to the BresserWeatherSensorReceiver wiki!

Adding Support of multiple Sensors

e.g. Weather Sensor and Soil Moisture Sensor

Option for skipping unwanted sensors (e.g. neighbours') - currently messages are received and decoded regardless of type or ID of sensor!

3 Different solutions have been considered:

Solution 1

  • decode radio messages in order as received
  • save decoded data into temporary buffer
  • copy data into final structure

Pros:

  • easy to implement
  • clean code structure

Cons:

  • memory wasted for temporary buffer
  • time for copying data

Solution 2

  • handle radio messages in predefined order
  • save decoded data into final structure

Pros:

  • easy to implement
  • clean code structure
  • efficient memory utilization

Cons:

  • inefficient usage of CPU time waiting for desired message

Solution 3

  • decode radio messages in order as received
  • save decoded data into final buffer in reception order; check for data already received (either complete or incomplete)
  • map data buffer (order of reception) to predefined order or search for desired sensor ID/type for presentation

Pros:

  • efficient memory utilization
  • efficient usage of CPU time

Cons:

  • somewhat difficult to implement
  • potentially fuzzy code structure

Implemented: Solution #3

Solution #3 has been implemented and the code does not look too bad, IMHO!

Implementing Rain Gauge Statistics

Currently, the rain gauge value is provided as-is, 0...99.9 mm for the "5-in-1" protocol, 0...19999.9 for the "6-in-1" protocol. When an overflow occurred in the former, my main and only customer (Dad!) thought that he had found a bug in my code! (Whaaat? 😮) After some explanation, he stated that it would be nice to have the same kind of data on the smartphone's MQTT Panel as on the Bresser weather station display. Here comes the feature request...

The following problems have to be addressed:

  • Which values are needed?

    • Rate - Current rainfall rate (base on 10 min rain data)

    • Hourly - the total rainfall in the past hour

    • Daily - the total rainfall from midnight (default)

    • Weekly - the total rainfall of the current week

    • Monthly - the total rainfall of the current calendar month

    • Total - the total rainfall since the last reset

  • Which range can be expected from those values?

    see Wikipedia's list of weather records - Section "Rain"

  • Which algorithms are needed? Which data has to be accumulated in nonvolatile memory? ⏳

    • Daily/weekly/monthly rainfall Pseudocode:
    foreach x in {day, week, month} {
    if (tsPrev.<x> != tsNow.<x>) {
        // day/week/month has changed
        // save timestamp at begin of new interval 
        tsBegin_<x> = tsNow;
        // save rain gauge value at begin of new interval
        rainBegin_<x> = rainNow;
    }
    rain_<x> = rainNow - rainBegin_<x>;
}

    Note:

    The begin of an accumulation interval (daily/weekly/monthly) is not detected exactly if the algorithm is executed at an interval (e.g. 10 minutes). In this case, the maximum deviation of the actual (timestamp;value)-pair from the ideal (timestamp;value)-pair is the length of the execution interval and the maximum possible change of value in this interval, respectively.

    • Total rainfall in the past hour

      To determine the rainfall in the past hour, timestamps and rain gauge values are stored in a circular buffer:

           ---------------     -----------
  .-> |   |   |   |   |...|   |   |   |--. 
  |    ---------------     -----------   |
  |     ^                   ^            |
  |    tail                head          |
  `--------------------------------------'
    • new value: increment(head); rain[head] = rainNow; ts[head] = tsNow;
    • remove stale entries: if ((ts[head]-ts[tail]) > 1hour) { increment(tail); }
    • calculate hourly rate: rain_hour = rain[head] - rain[tail];

    ts: timestamp

    The required size of the circular buffer is determined by dividing one hour by the minimum sensor data reception interval, e.g. for 1 hour at an interval of 6 minutes, 10 entries are needed. For https://github.com/matthias-bs/BresserWeatherSensorTTN, only the sleep interval is fixed, the sensor reception interval and the LoRaWAN transmission interval are variable (but limited):

    t_sleep t_rx_sensor ... t_LoRaWAN ...
    SLEEP_INTERVAL < WEATHERSENSOR_TIMEOUT < SLEEP_TIMEOUT_JOINED (min.)
    or
    < SLEEP_TIMEOUT_INITIAL + SLEEP_TIMEOUT_JOINED + SLEEP_TIMEOUT_EXTRA (max.)
    • Result
    Value NV data
    Hourly ts[BUF_SIZE], rain[BUF_SIZE], head, tail
    Daily tsBegin_day, rainBegin_day
    Weekly tsBegin_week, rainBegin_week
    Monthly tsBegin_month, rainBegin_month
    ts_prev

  • How does this data fit into the limited LoRaWAN payload?

  • How to get the date and time of day (e.g. from the LoRaWAN network)?

  • Which re-syncing interval of the RTC to the network time is reasonable?)

    Assuming 24 hours, can be configured with CLOCK_SYNC_INTERVAL in BresserWartherSensorTTN.cfg.

  • Do we have to consider daylight saving time?

    Yes, if we want to calculate daily (and monthly) rainfall correctly.

  • Implement reset of total rainfall by LoRaWAN dwonlink message?

Lightning sensor

In need of a lightning sensor? Stay tuned: https://github.com/merbanan/rtl_433/issues/2140

Resources

Löffler, Hans: Meteorologische Bodenmesstechnik (vormals: Instrumentenkunde). Offenbach am Main: Leitfaden für die Ausbildung im Deutschen Wetterdienst Nr. 6, Selbstverlag des Deutschen Wetterdienstes, 2012 (Link)

(Everything you ever wanted to know about ground-based weather sensors - and much more! - in German)

Clone this wiki locally