Max value of sensor value over a year

Configuration
1

Many threads on this subject, but I don’t find a satisfying answer.

For background; I have a ‘virtual’ battery to store access energy from the solar panels. I would like to find out what the maximum energy stored in that battery was for a calendar year.

I’m using the statistics - max_value for that now. But I noticed that the value dropped at some point. I believe this is because of the number of samples retained or something like that. But of course I do not need to keep all samples over the course of one year to determine the maximum value the way the statistics function works.

I just need to store the current max value and compare that to the current actual value to update the max value. For that I need the max value to be stored in a way that survives reboots. Many threads about that as well, but again I didn’t find a working solution.

Surely some-one has a good solution?

2
3

Maybe:

template:
  sensor:
    - name: "all time high"
      unit_of_measurement: "kWh"
      state: "{{ max(states('sensor.all_time_high') | float(0), states('sensor.your_battery') | float(0)) }}"

Just guessing, not tested.

4

Thank you. That would calculate the max value, but the value of the sensor.all_time_high would not survive a reboot.

5

Thank you. I have seen that suggested. Seemed more complicated than necessary.

Meanwhile I believe I have figured it out abusing an input_number, the documentation was not very useful, so when confirmed I will post that option.

6

Does it? Thought the the recorder: integration will restore state on reload, but obviously I am wrong.

7

input_number via automation/script/template?
Will be retained until reset (another automationscript)?
Best, JR

8

I think I have this working now. I abuse the ‘input_number’ variable and ‘set_value’ service.

It’s a three step setup.

  1. Define the ‘input_number’ variable

I have below code in my configuration.yaml file. The ‘min’, ‘max’, and ‘step’ parameters are mandatory and for the slider that will not be used. Just to make sure I set them to reasonable values for my use case. ‘input_number.battery_peak_energy’ will hold the maximum value I want to store to survive a reboot.

input_number:

    #Battery
    battery_peak_energy:
        name: "Battery Peak Energy"
        icon: mdi:battery
        unit_of_measurement: "kWh"
        min: 0
        max: 1000
        step: 0.001
  1. Define an automation to update the ‘input_number’ variable

I have created the automation below to update the ‘input_number’. It was counter intuitive that I had to create an automation, but it is pretty clean this way. The automation is triggered when the actual value exceeds the stored maximum value and then updates the stored maximum value with the actual value. Part of this automation could not be defined on the UI, I used fixed numbers for the ‘above’ value (input_number.battery_peak_energy) and the ‘set_value’ value ("{{ states(‘sensor.energy_stored_meter’) }}") and then edited the automations.yaml file.

- id: '1644321547640'
  alias: Store battery peak energy
  description: Calculate and store battery peak energy in input_value to survive a
    reboot
  trigger:
  - platform: numeric_state
    entity_id: sensor.energy_stored_meter
    above: input_number.battery_peak_energy
  condition: []
  action:
  - service: input_number.set_value
    data:
      value: "{{ states('sensor.energy_stored_meter') }}"
    target:
      entity_id: input_number.battery_peak_energy
  mode: single
  1. Define a sensor to display the ‘input_number’ variable

If you display the ‘input_number’ on the lovelace dashboard you get the slider to change the value. That’s not what I want here obviously. So I defined a sensor as below in the configuration.yaml file to create a ‘sensor.battery_peak_energy’ to display.

  - platform: template
    sensors:
        battery_peak_energy:
            value_template: "{{ states('input_number.battery_peak_energy') | float(0) }}"
            unit_of_measurement: "kWh"

Now I need a long sunny day to show that the automation works. But I’m confident.

I hope this helps others do a similar thing.

1 Like
9

Here’s how that Numeric State Trigger works:

  • It triggers the moment the value of sensor.energy_stored_meter increases above the threshold value of input_number.battery_peak_energy.
  • The trigger is now “set”. If the value of sensor.energy_stored_meter continues to increase, it will not trigger again.
  • To “reset” the trigger, the value of sensor.energy_stored_meter must first decrease below the value of input_number.battery_peak_energy. After that happens, it will trigger again whenever the value of sensor.energy_stored_meter is above the value of `input_number.battery_peak_energy

I don’t think this triggering behavior is suitable for your application.

I suggest you use a State Trigger with a Numeric State Condition that checks if the new value of sensor.energy_stored_meter exceeds the value of input_number.battery_peak_energy.

10

Thank you for the reply. I see what you mean.

However, is it enough that input_number.battery_peak_energy and sensor.energy_stored_meter are equal (they will be due to the action) to trigger again when sensor.energy_stored_meter keeps rising?

11

I now see what you are saying too; the threshold value is increased after each time the automation is triggered. It might still need the sensor’s value to be below the threshold for it to reset, not merely equal. You’ll need to test it.

12

Anyway, the trigger does not seem to work at all. So I will have to use what you suggest in your last paragraph. But I have no idea on how to do that …

13

I think it is the

    above: input_number.battery_peak_energy

statement that does not work.

I tried

    above: "{{ states('input_number.battery_peak_energy') }}"

but makes the whole automation invalid.

14

I believe you are trying to only find the max value for a single sensor over a year period, but I would be careful of causing HA to fire off a query against it’s state table and cause performance issues. At a base level success may depend on the database software you are using for HA recorder and your overall HA hardware platform. I don’t believe there is a way to force a query path for something like this in HA, and a result you might end up with a very slow and heavy on HA execution. At the core, I am not sure HA’s raw state and event storage model is well designed for ‘long term’ value storage and retrieval. I am thinking this is why the newer statistical summary work and tables are appearing.

Unfortunately, to get actionable predictive data for energy and environment, you need a couple years of historical data on your home.

I know you are looking for a easy way to accomplish your goal, but you might want to consider creating the sensor outside HA’s space and use one of the external tools, such as appdaemon.

15

According to the documentation, it is allowed:

Number helpers (input_number entities), number and sensor entities that contain a numeric value, can be used in the above and below thresholds, making the trigger more dynamic

It’s not working the way you expect probably because of the Numeric State Trigger’s behavior I explained above.

Try this:

- id: '1644321547640'
  alias: Store battery peak energy
  description: Calculate and store battery peak energy in input_value to survive a
    reboot
  trigger:
  - platform: state
    entity_id: sensor.energy_stored_meter
  condition:
  - condition: numeric_state
    entity_id: sensor.energy_stored_meter
    above: input_number.battery_peak_energy
  action:
  - service: input_number.set_value
    data:
      value: "{{ trigger.to_state.state | float(0) | round(3) }}"
    target:
      entity_id: input_number.battery_peak_energy
  mode: single
1 Like
16

I dont know if it would be too much work but I use IFTTT integration to log the level of my oil tank along with the date and outside temperature to a google sheets spread sheet. This updates once a day and allows me to look at the data long term in google sheets and manipulate the data as needed (through a graph etc)

17

Don’t get it. If he defines a trigger as above, which will trigger perhaps 1 to 2 times per month, where should be the problem? Every trigger in HA works this way: something happens (here x above y) and something will happen (here: store the new, higher value).

18

I was on the same track. I just changed to this:

- id: '1644321547640'
  alias: Store battery peak energy
  description: Calculate and store battery peak energy in input_value to survive a
    reboot
  trigger:
  - platform: state
    entity_id: sensor.energy_stored_meter
  condition: []
  action:
  - service: input_number.set_value
    data:
      value: "{{ [ states('sensor.energy_stored_meter') | float(0), states('input_number.battery_peak_energy') | float(0) ] | max }}"
    target:
      entity_id: input_number.battery_peak_energy
  mode: single

Of course the automation is now triggered much, much more often.

1 Like
19
  1. Your version executes its action every time the sensor’s value changes (increase or decrease).
  2. My version only executes its action if the sensor’s value exceeds the input_number’s value.

There’s also a difference concerning the automation’s last_triggered property (it’s updated when the action is executed).

20

Yes. Understand.

But the ‘max’ evaluation must be done either way. Does it make a big difference in resource usage if that is a condition rather than an action?