I have a water meter reader (via esphome) that gives a pulse every 0.5L. I’m looking for a way to sum this into total water usage. While there’s a lot of topics on this, I only found several half-solutions:
Integrate on esp home (here, here, here) → seems error prone, I prefer to keep my esphome devices simple
Sum sensor with sum or total statistics → this could work however these options require max_age or sampling_size, which makes me hesitant to use this and set max_age to 100 years because it seems to be tracking each data point internally, which could lead to some memory overflow.
Count sensor with count binary_sensor option → this seems to almost fit, except I would chain this to another helper sensor to convert it to water meter in liters
Given this problem is so common, I’m wondering if I’m missing something. Does somebody have an easy solution?
The pulse_counter platform has total: section you van configure. I use it with my electricity pulse meter. I have an unfinished water meter project that will use it too.
Thanks! I think you mean esphome’s pulse_counter, correct? That would work, but how do you handle esphome & counter restarts to get the total? The only thing I saw is adding extra logic to store this, reload it, etc., which sounds like too many moving parts…
It depends how you’ll be using it. It doesn’t bother me in my case, because I feed this into a utility meter on the HA side, which handles everything correctly.
Ok thanks, so your flow would be: pulse_counter → utility meter, correct?
I noticed that pulse_counter acts more like frequency_counter, so you’d need to convert pulse frequency to counts. I noticed there’s also pulse_meter which looks more suitable for low-frequency water meter pulse frequencies.
FWIW, this works for water meter counting rotating disk pulses:
sensor:
- platform: pulse_counter
pin:
number: GPIO14
mode: INPUT
unit_of_measurement: 'L'
name: 'Water sensor pulse'
# One rotation is 1 liter, count both edges to get 0.5 liter resolution
count_mode:
rising_edge: INCREMENT
falling_edge: INCREMENT
# Sometimes the sensor keeps triggering, so we debounce the binary sensor here
internal_filter: 50ms
update_interval: 30s
filters:
- multiply: 0.5 # (0.5L/1 pulse)
total:
unit_of_measurement: 'L'
name: 'Water sensor total'
filters:
- multiply: 0.5 # (0.5L/1 pulse)
Using esphome’s recommended pulse_meter I have the following working setup:
# Better sensor using pulse_meter which measures time between pulses rather than pulse frequency
sensor:
- platform: pulse_meter
pin:
number: GPIO14
mode: INPUT
name: 'Water sensor pulse'
# Sometimes the sensor keeps triggering, so we debounce the binary sensor here. Seems to be necessary to not get crazy values.
internal_filter: 100ms
# Not sure why/if this is needed --> seems not?
# internal_filter_mode: PULSE
# Flow lower than 0.5l/30s is zero
timeout: 30s
unit_of_measurement: 'L'
device_class: water
# state_class: measurement # --> `water` is not allowed to be measurement, must be total or total_increasing
filters:
- multiply: 0.5 # (0.5L/1 pulse)
accuracy_decimals: 1
total:
unit_of_measurement: 'L'
device_class: water
# state_class: measurement # --> `water` is not allowed to be measurement, must be total or total_increasing
name: 'Water sensor total'
filters:
- multiply: 0.5 # (0.5L/1 pulse)
accuracy_decimals: 1
internal_filter seems required, the default 13us leads to high strange values, I think the sensor might have some high-frequency noise when detecting edges.
This function also triggers on every count, which is nice for water meters as the count frequency can be quite low.
Finally, I then use a utility meter tagged to ‘Water sensor total’ in Home Assistant to correct for meter resets etc.
