I’ve added the trend binary sensor (which for some reason stays on when it starts to rain, but never goes to off, only at midnight). I’ve added the rain rate sensor, but that stays at the last calculated rate even though it stopped raining. What am I doing wrong? 
1 Like
I decided to keep it that way, because you can’t really figure out when it stops raining, and when to reset it. And to reset it you’d have to do some hacky things in yaml, so I prefer it this way.
When there is a heavy rain storm I use it to see the intensity but nothing more to be honest, I don’t mind it keeping the same value if the rain stops.
If you have a suggestion to solve this let me know 
2 Likes
We finally had a bit of rain to test this properly. The values seem reasonable for the amount of rain we had but I don’t know of a site in the UK to check rainfall historically, so I can’t be sure.
1 Like
I have made the Rain Gauge with an Aqara Door sensor, but I experience that I miss a lot of tip count.
The link quality is LQI 47 which I think should be fine.
Is there a setting in Aqara that could cause the sensor to not report all detections? (like; stop report if too frequent etc)
No settings as far as I know. Do you have a existing zigbee network and does it work? In my experience if a zigbee sensor or switch is not working or sometimes not reporting state even though it is connected OK, it is down to interference with wifi networks.
1 Like
It could be interference like the previous post, but did you also make sure that the reed sensor is working as it should, and not too far away from the magnet?
Is it possible to reset the numbers for week, month and year?
See the services of the utility meter
I would also be interested in a solution for the hourly rainfall.
However, I have another “blemish” in my dashboard.
The bar chart over the last few days visually shows everything correctly.
But when I move the mouse over a day with zero rain, I get incorrect data.
All days with zero rain have the value of the current day.
Here the card configuration
type: custom:mini-graph-card
aggregate_func: max
line_color: '#039BE5'
icon: mdi:weather-rainy
color_thresholds_transition: hard
entities:
- sensor.rain_today
group_by: date
hour24: true
hours_to_show: 360
name: Regenmenge
show:
fill: fade
graph: bar
labels: false
smoothing: false
I had some strange behavior with mini-graph-card as well, and decided to use apexcharts. It’s more clear as well.
type: custom:apexcharts-card
graph_span: 30d
header:
show: true
title: Rainfall
show_states: true
span:
start: day
offset: '-29d'
series:
- entity: sensor.rainfall_today
color: aqua
type: column
group_by:
func: max
duration: 1d
2 Likes
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. 
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: 60sIn 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: yearlyAnd 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: 72And 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: RainThe 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. 
ThisWayToo
2 Likes
I’m not sure what’s wrong with the ESP or ESPHome part
But if you’re having poor performance because of the cold temperatures, you could try the BR2032 battery for the zigbee/z-wave sensor. They say it has better cold temperature performances.
Or you could use another 3v battery
The door sensor I had tried uses a CR123A, so I thought I was going to be good for battery life.
I’m using another one of those exact same type door sensors as a gateway device for my mailbox sensor, though it is indoors but that one is holding up nicely over a year now. Seems Zigbee / Z-Wave devices are hit and miss for battery life. 
Bigger battery can also mean less efficient of course
To be honest I would give the Zigbee ecosystem a try. I’m very satisfied with the Aqara sensor. It had been running on the same battery since I created this thread.
1 Like
So where exactly does one place the aqara? And does the reed sensor face the tipping bucket or away? I can get one tip, but i find it hard to get both tips from both sides.
hi @parrel Should i be getting one tip from each side of the tip ? So it goes down on left, one tip. Goes down on right, one tip ?
With my code, for it to work correctly, the reed sensor should be in the middle, so when it tips, the state will go from open->closed->open. It will be closed for a few milliseconds, and that’s what’s counted
So if it is down on the left and press it down so it move to the right and down, one tip. Then if i move it back to the left, i get no tip. Is that correct?
Sorry if i’m being thick. Just trying to figure out what constitutes a tip. I’m putting it exactly in the middle but i only get one tip, but i have a feeling that’s how it’s supposed to be?
Yes it will be open all the time and closed for a few milliseconds when it tips to another side