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
Has anyone integrated this with InfluxDB? I’m wanting to just record the amount of rain per tip in IDB every time the sensor flips, but I’m not sure how to do this.
I think there is an InfluxDB integration for Home Assistant
It will allow you to add entities that you want to send to the influxdb database
You just configure the entities like in the original post and then add them to influxdb
I don’t think any of the original entities would work for this instance. I’m looking for something that simply triggers on every flip and enters a defined amount of rain (0.30303) in as a single entry in InfluxDB. As it is it’ll just record “1” and then “0” every time it flips, which is usable just not ideal.
Why don’t you then include the ‘rainfall today’ sensor?
You can also try to modify the history stats sensor in something that never resets so you get the all-time rain amount if that’s what you need
I appreciate this is slightly outside of the realm of the original post, but how would one… modify the yaml code if it’si just on-off ?
If you use an Aqara door sensor instead of the reed switch that came with the board placement seems to become more tricky, i can only achieve on-off it seems.
What does offset -29d do ?