☔ DIY Zigbee rain gauge

Share your Projects!
,
359

After having referenced this thread (and numerous others) for rain gauge ideas for many months, I came up with the configurations shown here.

I initially had tried the door/window sensor / reed switch approach using a Z-wave door sensor. The problem I ran into was that the battery in it didn’t even last 6 months. It was sitting idle in the cold winter well below freezing temperatures and when spring arrived it was dead. The battery was fine before winter.

So I decided to go the ESPHome approach using a ESP32 GPIO input and reed switch. I do have it mostly working, or at least it was until a suspected relatively close lightning strike I think damaged the ESP32’s input pin a couple months ago. :unamused: I have not taken the time to troubleshoot it yet. I do plan to optocoupler isolate that ESP32 input just to make it more rugged.

This is the code in ESPHome for the ESP32. Since I started with a RainWise “Rainew” collector it was just a matter of adding my own, secondary reed switch. So the RainWise original display functionality is preserved.

Additionally the RainWise buck tips equal .01" of rain, which is exactly what I wanted it to be. So no conversion between mm or inches. I just needed to move the decimal point:

# Individual sensors
sensor:

# GPIO contact closure - rain gauge bucket into ESP32 GPIO
  - platform: pulse_counter
    pin:
      number: GPIO17
      mode: INPUT_PULLUP
    unit_of_measurement: 'inches'
    name: "Rain Gauge"
    filters:
      # Each 0.01" (0.254mm) of rain causes one momentary contact closure
      - multiply: 0.01
    accuracy_decimals: 2
    icon: 'mdi:weather-rainy'
    id: rain_gauge
    count_mode:
      rising_edge: DISABLE
      falling_edge: INCREMENT
    internal_filter: 13us
    update_interval: 60s

In the configuration.yaml I created some statistics sensors to provide me differing time spans of rain statistics looking back from the current point in time. I am not interested in using utility meter for near term rain amounts. To me it is far more useful to display how much rain there was looking back X hours from current time. That way if a rain event starts at 11PM and goes till 3AM my “6h Rain Statistics” sensor will capture the total amount and not be interrupted by midnight like utility meter does to you. For entire month periods utility meter’s time boundaries are fine.

The configuration.yaml entries:

# Various sensor types
sensor:

# Generates rain amount per last period of time - sliding window
# sensor.rain_gauge via ESP32
  - platform: statistics
    name: 1h Rain Statistics
    entity_id: sensor.rain_gauge
    state_characteristic: total
    sampling_size: 200
    max_age:
      hours: 1

  - platform: statistics
    name: 6h Rain Statistics
    entity_id: sensor.rain_gauge
    state_characteristic: total
    sampling_size: 500
    max_age:
      hours: 6

  - platform: statistics
    name: 12h Rain Statistics
    entity_id: sensor.rain_gauge
    state_characteristic: total
    sampling_size: 1000
    max_age:
      hours: 12

  - platform: statistics
    name: 24h Rain Statistics
    entity_id: sensor.rain_gauge
    state_characteristic: total
    sampling_size: 2000
    max_age:
      hours: 24
      
  - platform: statistics
    name: 48h Rain Statistics
    entity_id: sensor.rain_gauge
    state_characteristic: total
    sampling_size: 3000
    max_age:
      hours: 48

      
  - platform: statistics
    name: 72h Rain Statistics
    entity_id: sensor.rain_gauge
    state_characteristic: total
    sampling_size: 5000
    max_age:
      hours: 72
      
  - platform: statistics
    name: 7d Rain Statistics
    entity_id: sensor.rain_gauge
    state_characteristic: total
    sampling_size: 11000
    max_age:
      hours: 168
      
# Provides clock/day/calendar based tallies of rain
utility_meter:
  rain_month:
    source: sensor.rain_gauge 
    cycle: monthly
  rain_year:
    source: sensor.rain_gauge 
    cycle: yearly

And finally examples of displaying rain amounts using a History Graph card that plots amounts/hour for the last 3 days:

type: history-graph
entities:
  - entity: sensor.1h_rain_statistics
hours_to_show: 72

And also a Entities Card presentation:

type: entities
entities:
  - entity: sensor.1h_rain_statistics
    secondary_info: last-updated
    name: Rain Last Hour
    icon: mdi:weather-rainy
  - entity: sensor.6h_rain_statistics
    name: Rain Last 6 Hours
    icon: mdi:weather-rainy
  - entity: sensor.12h_rain_statistics
    secondary_info: none
    name: Rain Last 12 Hours
    icon: mdi:weather-rainy
  - entity: sensor.24h_rain_statistics
    secondary_info: none
    name: Rain Last 24 Hours
    icon: mdi:weather-rainy
  - entity: sensor.48h_rain_statistics
    secondary_info: none
    name: Rain Last 48 Hours
    icon: mdi:weather-rainy
  - entity: sensor.72h_rain_statistics
    name: Rain Last 72 Hours
    icon: mdi:weather-rainy
  - entity: sensor.7d_rain_statistics
    name: Rain Last 7 Days
    icon: mdi:weather-rainy
  - entity: sensor.rain_month
    name: Rain This Month
    icon: mdi:weather-rainy
    secondary_info: none
title: Rain

The key problem I was seeing prior to it getting zapped was that during heavy rains a significant number of pulses were being missed. I was not able to figure out why. And haven’t fixed the hardware yet to dig into it again. Perhaps someone here might have some insight to that issue.

Edit to add Dec 14 2022:

Just an update to the issues I had seen noted above. First the loss of all pulses failure turned out to be a bad reed switch, it just plain failed. Some of the reviews for the reed switch that I had purchased complained about them occasionally failing for no obvious reason. That appears to be what happened to me.

The inaccuracies (missed pulses) I was seeing I’m now convinced are due to the hyper fickleness of getting the reed switch positioned correctly. I have been trying to match (mirror) the location and orientation of the existing reed switch that the RainWise bucket uses. Something that has proven to be incredibly more difficult to actually do than one would have thought it should be. :scream:

ThisWayToo

2 Likes