All time maximum value for a sensor

Configuration
1

Hello all!

I am wondering how to get a value for the all time maximum value seen on some specific sensor.

I have flashed Valetudo on my Roborock vacuum and I can track the area covered by the vacuum on each cleanup cycle. The value starts at zero when the vacuum starts. From there it grows to some number, depending how many doors are open and how much stuff I have lying on the floor it can get bigger or smaller.

I would like to have a value visible that tracks the maximum area it has ever cleaned. I would like it to remember the maximum value even if that value has already been purged from the recorder history.

Thanks already for your time!

2

I am doing something similar for the all-time minimum and maximum air pressure.
For that I created two Input Numbers in which I store these values.

1 Like
3

Here is what I use to find the highest daily temp (modified for your use):

  - alias: Env Set Highest Temp So Far
    trigger:
      - platform: state
        entity_id: sensor.openweathermap_temperature
    action:
      - service: input_number.set_value
        data:
          entity_id: input_number.highest_temp_so_far
          value: >
            {% if states('sensor.openweathermap_temperature') not in ['unavailable', 'unknown'] and (states('sensor.openweathermap_temperature') | float > states('input_number.highest_temp_so_far') | float) %}
              {{ states('sensor.openweathermap_temperature') | float }}
            {% else %}
              {{ states('input_number.highest_temp_so_far') }}
            {% endif %}

you need to replace my entities with yours but that should give you the gist of what you need to do.

1 Like
4

Thank you so much!

I did something like this, the value is only going to change on tuesday next time so I’ll see if it will work. Should post my version here as well eventually.

What I did was to add an input_number in configuration.yaml.

Then add an automation to modify that number, with code similar to what @finity posted, and after some fiddling I think I got it done right.

5

You might consider a trigger-based template sensor. It can’t have its value overwritten from the UI, and it combines an automation and an entity into one thing.

template:
  - trigger:
      - platform: state
        entity_id: sensor.openweathermap_temperature
        not_to:
          - unavailable
          - unknown
    sensor:
      - name: Highest Temp Ever
        unique_id: c6174f4d-0709-4e70-a675-5ba3f07c80a0
        state: >
          {{ max(trigger.to_state.state | float, this.state | float(-999)) }}
2 Likes
6

Thank you! This is very elegant.
Just missing one parenthesis in the end: should be ) }}.

I was getting frustrated by the input_number showing a slider when trying to see just the number on my dashboard.

I now implemented this and let’s see when the value changes after a couple of days…

I omitted the unique_id, is there maybe some way to generate those? I don’t have a unique_id for any of my template sensors, is it so they can be renamed later?

7

Good catch I’ve edited my code.

The unique_id is used so that you can edit the entity from the UI, for example if you want to change the icon or the name. It is also needed if you want to change the yaml code of that sensor without losing the history and having a duplicate sensor created. You can type anything you want there as long as it doesn’t match any other unique ID elsewhere in your configs. A good idea is to use a GUID, you can just Google that term and find a website that generates them.

I would recommend adding one to all your existing yaml-based sensors. If you go to developer tools → YAML and reload any of those configs, any sensors without a unique_id won’t be updated; instead new entities will be created. So if you update the yaml of the sensor you just made, and then reload TEMPLATE ENTITIES, you’ll still have the old unchanged sensor.highest_temp_ever and now a new sensor.highest_temp_ever_2 with the changes you made.

1 Like
8

Someone else had a similar request, to record the maximum daily outdoor temperature (can be any numeric parameter). In addition, they wanted to know the maximum weekly/monthly/yearly temperature.

The suggested solution was similar to what mekaneck proposed above (use a Trigger-based Template Sensor to report the maximum temperature), and then uses the Utility Meter integration to report long-term daily/weekly/monthly/yearly statistics (i.e. these values are stored in a table in the database that isn’t periodically purged).

The main difference between mekaneck’s example and the one in the following link is that (due to different requirements) it resets at the start of every day and records the time when the temperature value was updated. It’s the sensors created by the Utility Meter integration that are responsible for recording long-term daily/weekly/monthly/yearly statistics.

1 Like