o boy,o boy, o boy. We are having a typhoon today.
same day
1 Like
This rain gauge calculates the rainfall by filling a small bucket, and record it when that tips (the tip)
this sensor is a utility meter?
im little lost here about the rain sensor, since it does not decrease, is like an acumulated rain, does that make sense or im confusing here?
XD
I guess im confusing with the wind sensor, this one does not make sense to acumulate but shows the increase/decrease wind speed based on the rotation…
Just built mine… pretty excited to see the next rain storm… I used the AEOTEC ZWA012 door sensor that had built in dry contacts. It was too big for the case… so it got to cutting the board in half… not my best work… a bit of solder and some hot glue made sloppy work of it. but it works. Thanks for your very easy to follow post.
1 Like
That’s a lot of rain! A good test for the sensor 
Could someone verify if my code is correct. It’s currently very dry here and i want to be ready for the upcoming rain season
I still get the tips upon reboot, currently using a inverted sensor and retain option not currently set (using zigbee2mqtt)
sensors.yaml:
# Invert Rain Gauge
- platform: template
sensors:
garden_rain_sensor_1_inverted:
value_template: >-
{{ is_state('binary_sensor.garden_rain_sensor_1_contact', 'off') }}
device_class: door
# Rainfall trend forecast amount of mm/h
- platform: trend
sensors:
garden_rain_sensor_1_rainfall_trend:
entity_id: sensor.garden_rain_sensor_1_rainfall_today
max_samples: 2
binary_sensors.yaml:
# Garden Rain Sensor 1 Amount of Tips
- platform: history_stats
name: Garden Rain Sensor 1 Tips
entity_id: binary_sensor.garden_rain_sensor_1_inverted
state: 'on'
type: count
start: '{{ now().replace(hour=0, minute=0, second=0) }}'
end: '{{ now() }}'
# Garden Rain Sensor 1 Rainfall today
- platform: template
sensors:
garden_rain_sensor_1_rainfall_today:
friendly_name: Garden Rain Sensor 1 Rainfall Today
unit_of_measurement: mm
value_template: >-
{% set count = states('sensor.garden_rain_sensor_1_tips') | int(0) %}
{% set mm = count * 0.30303 %}
{% if count >= 0 %}
{{ mm|round(1, 'floor') }}
{% endif %}
# If you have issues with the history sensor doubling after restarting HA, add the line below (@BigG)
availability_template: "{{ (states('sensor.garden_rain_sensor_1_tips') not in ('unknown', 'unavailable')) }}"
#availability_template: "{{ (states('binary_sensor.garden_rain_sensor_1_contact') not in ('unknown', 'unavailable')) }}"
I think it’s pretty solid but probably still missing something. My rain sensor on reboot goes from unavailable to on to off.
Many thanks for reviewing.
What is the mqtt configuration for the binary sensor binary_sensor.garden_rain_sensor_1_contact?
That’s the aqara door sensor, not sure how to get the mqtt configuration for that. Do you mean the zigbeemqtt tab ? Apologies if i’m being thick.
And the Retain setting does not make a difference?
It could be because you added a template inverted sensor in between.
You could either try it without the inverted sensor, or add the availability line to the inverted template sensor as well. For both cases, enable the retain setting in the mqtt settings.
To really see what is causing the false tip, you can install phpMyAdmin and run an SQL query on the states of all sensors, starting with the mqtt binary sensor. Then you can see which sensor causes the wrong state.
Thanks parrell. I messed around with it a few times but didn’t see a difference, i saw a user saying they didn’t have to turn it on.
I have turned it on now, so let’s see if it works this time. If not, i’ll add the availability template to the inverted as well. I’ll let you know how it goes, we had a bit of rain today.
Because this template
{{ is_state('binary_sensor.garden_rain_sensor_1_contact', 'off') }}
Will be false (off) when the state of the binary sensor is unavailable or unknown
And shortly after the binary sensor real state is set, which is off and then the template will report true (on)
And that will cause the history sensor to count an extra tip (because the state went from off to on
So either remove this whole inverted sensor or add the availability line to the inverted sensor
1 Like
Love it, will try that.
I added the availability line to the inverted sensor, that seems to have done the trick. I added the inverted sensor as i thought someone here said that would fix the rain issues. I’ll turn of retain option and see if if still works.
I noticed btw that the forecast sometimes goes on all day after it rained. Is there a way of limiting that or is that’s how it is supposed to be?
1 Like
Why disable the retain option? Don’t change it if it works
I haven’t found an efficient way to reset the rain intensity. You don’t really know when the rain stops and to reset it…
That’s why I thought it is the best to just keep the last state, and when a new tip is registered, it will go down again.
Mine finally arrived too and as I like accuracy I did some extended testing and thought I would share the results here:
Area
For the area, I put it on my flat bed scanner along with a set square and measured it in AutoCAD:
(everything in mm)
Ml per tip
For this one, I just used more water in order to compensate half full buckets and other inconsistencies:
-
1500 ml = 794 tips
-
1 tip = 1,8892163530567520592458248318597 ml (Decide for your self how accurate you want it
)
Calculation
From the values above, we can calculate the following:
1 mm rain = 5569.5278 / 1000 = 5.5695278 ml
@ 1.8892163530567520592458248318597 ml per pulse
pulses / mm = 5.5695278 ml / 1.8892163530567520592458248318597 ml = 2.948062455096
mm / pulse = 1.8892163530567520592458248318597 ml / 5.5695278 ml = 0.33920583950703182758973298092878 mm
Didn’t test it yet, but I’m looking forward to the next rain.
2 Likes
Makes sense, thanks!
1 Like
Did you take the catchment area into account? I think the calculation should be like the following:
1500ml/55.695278cm2 = 26,93226524517931cm
26,93226524517931cm = 269,3226524517931mm
269,3226524517931mm / 794 tips = 0,339197295279336 mm/tip
Jep, those were the raw values.
I’ve added my calculation
1 Like
Also for the ESP folks here, I’ve created 3 sensors from this:
- mm of current day
- current downfall in mm per hour (calculated from tipping frequency)
- mm of the last rain (resets when the bucket tips and the last tip is more than 1 hour ago → daily reset save !!EDIT: something isn’t working right yet, will look at it when I have time!!)
globals:
- id: rain_meter_rainly_counter
type: int
initial_value: '0'
time:
- platform: homeassistant
on_time:
- seconds: 0
minutes: 0
hours: 0
then:
# reset daily rain meter counter
- pulse_meter.set_total_pulses:
id: rain_meter_daily
value: 0
script:
- id: rain_timeout_script
mode: restart
then:
- delay: 1 h #timeout for a rain to be considered ended
sensor:
# 1mm rain = 5.5695278 mL
# @ 1.8892163530567520592458248318597 mL per pulse
# pulses / mm = 5.5695278 / 1.8892163530567520592458248318597 = 2.948062455096
# mm / pulse = 1.8892163530567520592458248318597 / 5.5695278 = 0.33920583950703182758973298092878
- platform: pulse_meter
### Rain meter current ###
pin: D8
unit_of_measurement: 'mm/h'
name: 'Rain meter current'
accuracy_decimals: 2
id: rain_meter_daily
filters:
- multiply: 20.3523503704219096553839788557268 # pulse_meter outputs pulses/min => 60 minutes * 0.33920583950703182758973298092878 mm per pulse = 20.3523503704219096553839788557268 mm per hour
### Rain meter daily ###
total:
unit_of_measurement: 'mm'
name: 'Rain meter daily'
accuracy_decimals: 2
filters:
- multiply: 0.33920583950703182758973298092878
### Automation for rainly meter ###
on_value:
- lambda: |-
if (x != 0) { // don't count resets of daily meter
if (id(rain_timeout_script).is_running()) { // if currently in rain shower => count up
id(rain_meter_rainly_counter) += 1;
} else { // if previous rain shower is considered ended => reset counter to 1
id(rain_meter_rainly_counter) = 1;
}
id(rain_timeout_script).execute(); // start/restart rain timeout timer
id(rain_meter_rainly).publish_state(id(rain_meter_rainly_counter));
}
### Rain meter rainly ###
- platform: template
name: "Rain meter rainly"
id: "rain_meter_rainly"
accuracy_decimals: 2
lambda: 'return id(rain_meter_rainly_counter);'
update_interval: 600s
filters:
- multiply: 0.33920583950703182758973298092878
3 Likes
hi guys,
i’am in the process of building the Zigbee Raingauge, But having trouble implementing the template sensor.
I split my configuration.yaml according to Frenck’s. So resulting in:
in my configuration.yaml it says packages: !include_dir_named integrations
in my integrations directory there is a file called sensor.yaml with the content:
sensor: !include_dir_list …/entities/sensors
SOLVED:
Long story short, I didnt bother to read any further because I didnt get past step 2, implementing the rainfall today sensor bit.
But the solution for the new format is the answer from Parrel on the 25th of july…
create a template.yaml file,
for the ones with a configuration like Frenck, where the packages are used.
the solution is below.
sensor:
- name: Rainfall today
unit_of_measurement: mm
state_class: total_increasing
unique_id: rainfall_today
state: >-
{% set count = states('sensor.rainsensor_flips') | int(0) %}
{% set mm = count * 0.30303 %}
{% if count >= 0 %}
{{ mm|round(1, 'floor') }}
{% endif %}
# If you have issues with the history sensor doubling after restarting HA, add the line below (@BigG)
availability: "{{ (states('sensor.rainsensor_flips') not in ('unknown', 'unavailable')) }}"
all is working now,
oh, about the wiring, I removed the grey insulation, leaving just the red and green wire, so no need to expose the cable to the ‘outside’ it fits with the door sensor in total in the battery compartment.
Thanks for an awesome rain gauge solution…
Regards Frank
1 Like