Calculate rain volume in the last 1 hour and 24 hours, from a cumulative rain counter

Is there a simple way to calculate rain volume in the last 5 minutes, 1 hour and 24 hours from a cumulative rain counter, within the ESPHome device, so that it can display these values on its LCD?

A 433 MHz weather station sends data to an ESPHome device consisting of an M5Stack with slightly modified 433 MHz LoRa module. The components ‘sx127x’, ‘remote_receiver’ and ‘rtl_433’ successfully decode the data, with an ‘on_json_message’ automation to feed the data into a number of template sensors, one each for temperature, humidity, wind-speed, etc.

Each of these sensor values can then be displayed locally on the M5Stack LCD, and also fed to HA.

One of the values from the weather station is a cumulative rain counter: millimetres of rain since the outside device was turned on.

It is much more useful to know how much rain has fallen in the past (say) 5 minutes, 1 hour and 24 hour periods. There are a number of posts here about how to do this within HA; however, I want to display the values on the device locally, without a round-trip through HA.

My usual way of doing this is to create a timestamped history of cumulative readings. Then, to calculate rain over the last 1 hour, you subtract the most recent reading from the value 1 hour ago. You then get a continuous graph of rain over that time period.

This needs a custom filter in ESPHome.

It occurs to me that a simpler way would be to feed the data through a ‘heartbeat’ filter (so that values are presented at regular intervals), into a ‘delay_delta’, similar to the ‘sliding_window_moving_average’ filter, except that instead of calculating the average, it returns the difference between the newest value and the oldest value. The measurement period is then the product of heartbeat period and window size.

I have implemented this, with a few changes in sensor/init.py, sensor/filter.h and sensor/filter.cpp. The new code is simply a new SlidingWindowDeltaFilter, derived from SlidingWindowFilter, with a compute_result() function for this filter; the rest is housekeeping.

This works well. The changes are in my cloned copy of ESPHome; happy to share if anyone is interested.

However, this means that I have to

  • keep my modifications in sync with upstream myself
  • create a custom component (and keep that in sync with upstream)
  • add this new ‘delay_delta’ filter to upstream, if it is useful

Questions

  • Is there a way to do this in the ESPHome device (not in Home Assistant), without a custom filter?
  • Or perhaps just a better way of doing it?
  • Is this ‘delay_delta’ filter likely to have wider use? Is it worth creating a new filter type in ESPHome?
  • Or perhaps a ‘delay_line’ filter, where the output is taken from the oldest end of the sliding window directly, without the subtraction?

Stephen

Of course there is. Question is if it’s going to be better or worse than your actual one.
Like how much memory it uses? Resolution? Does it have to survive reboot? Does it have to output correctly before the window (like 24h) is filled first time?

I expect that you are looking for rolling 24h, not just from 0:00 to 24:00