@BigG@johannwilken
Do you both have the Retain option checked in zigbeemqtt? It stills a tip for every reboot for me.
This is my code:
# Garden Rain Sensor 1 Amount of Tips
- platform: history_stats
name: Garden Rain Sensor 1 Tips
entity_id: binary_sensor.garden_rain_sensor_1_contact
state: 'off'
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')) }}"
I can’t enter a availability template for the history_stats platform, and i have a feeling because of the aqara door sensor going from open - close or vice versa it increases tips, and as a result increases the daily rainfall/rainfall today sensor. Maybe setting that to retain will resolve it?
Hi atv,
No I don’t have Retain checked in zigbeemqtt.
I know when I first set this uo it took me a while to fix the reboot issue, from memory I checked the history of the sensor to see the exact state the it went through during reboot and I wasn’t testing for the correct state.
Hmm i see you created an inverted sensor. I’ll add that and see if that resolves it. I had the availability sensor already, thought that would suffice.
I get this error when using that code:
The system cannot restart because the configuration is not valid: Invalid config for [sensor.template]: expected SensorDeviceClass or one of 'apparent_power', 'aqi', 'battery', 'carbon_monoxide', 'carbon_dioxide', 'current', 'date', 'duration', 'energy', 'frequency', 'gas', 'humidity', 'illuminance', 'monetary', 'nitrogen_dioxide', 'nitrogen_monoxide', 'nitrous_oxide', 'ozone', 'pm1', 'pm10', 'pm25', 'power_factor', 'power', 'pressure', 'reactive_power', 'signal_strength', 'sulphur_dioxide', 'temperature', 'timestamp', 'volatile_organic_compounds', 'voltage' for dictionary value @ data['sensors']['garden_rain_sensor_1_inverted']['device_class']. Got 'door'. (See ?, line ?).
Update: NM i had to place the first part of that code in my binary_sensors.yaml file.
Everything is working now, thanks to that inverted sensor. I do still see after a restart, a marker in the graphs but the value does not change. Ideally that would also not be displayed but that’s an artefact of the history_stats platform i think.
UPDATE: Nope, i spoke too soon. Still get a tip per reboot, sigh. And these forecast trends don’t look right either. 46.555.9 ? The forecast trend also stays like that for a way to long time in my opinion.
Having built and calibrated my Raingauge 6 weeks ago, today was the first significant rain since I installed it. All I can say is its totting up the rainfall without issue. 15.4 mm so far today. Nice to see it finally working.
Thanks to all especially @parrel for keeping this active. I am having issues and very confused with the new template configuration vs the legacy. I had it working previously but mistakenly deleted that portion yaml.
My configuration.yaml has the file split as follows
group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
binary_sensor: !include binary_sensor.yaml
sensor: !include sensor.yaml
camera: !include cameras.yaml
Does anyone have @parrel configuration.yaml broken into the sensor.yaml?
The TFA 30.3161 is good available in the Netherlands for about 20 euros including shipping costs.
The advantage of this rain gauge is that there is more space for the Aqara sensor. I temporarily glued a magnet on the buckets. There is still room for a magnet on the side. I have ordered these small magnets. The magnet on the tray shows no measurable differences in the measurements.
I slid the sensor into the waterproof housing with some packing foam.
If you have found the right position, the sensor does not affect the operation of the buckets and indicates 100% reliable ticks!
There’s instructions in the first post where they already figured out the surface area and the math.
Then I just created a helper and set the step size to that value. So every tip, it increments by that amount.
But I figure if you are using a different style device with a different surface area a round about way to do it if you’re not a surface area physicist.
setup the smart device next to an old school rain gauge
Reset # of tips to 0
Wait for rain
Check old school rain gauge. Lets say it shows .1" of rain
Look at # of tips, lets say its 25
.1" of rain divided by 25 tips = .004"
Set the helper to increment by .004 for every tip
Thats kinda what I did to tweak my number. You can see the gauge showed more rain that what the sensor counted, so I just needed to tweak by number it increments by slightly. Now I am pretty much right on everytime (or close enough for my purposes)
To calibrate I worked out the surface area in mm2. this will give you milliliters per 1mm rain. Then worked out how many of those 1mm of rain were in 200 ml of water. Poured 200 ml of water through and counted the tips, repeated this 4 times and averaged the result.
For folks that have to suffer with imperial measurements, how do you handle this section of the template sensor?
- 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')) }}"
