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.
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.
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.