How to save a value?

Hi all,

I’m sure I stumbled across this in another post here but can’t find it anymore:

How can I store a value (best would be even after reboot, but not mandatory)?

Use case: Want to store the thermostats actual temperature, door opens, temp goes down, door closes, temp goes up to the saved value.

I’m sure many people here did exactly that already :slight_smile:

Kind regards,

1 Like

HA’s “variables” are the input_xxx components. E.g., you can save a number in an input_number, or text in an input_text, etc., and then use their values later. Their values (i.e., states), by default, will even be saved across HA restarts.


Personally I use this:

Custom component to allow easy way to both set and retrieve variable values.


Given Horizon joined 20th September (12 days ago, though he has read 11hrs (20 was a mis-read, sorry, but it’s still impressive) + (impressive ! :+1: )) I think he should explore vanilla options as Phil has pointed out.
Once he finds they aren’t enough for him (I still use input_xxx for LOTS of stuff) than he can explain his problem and take it from there. I don’t think that, is yet the case.
Horizon, Please correct me if I’m wrong ???

1 Like

Just to be sure …
I’m sorry if you knew this already
If you have an initial: statement in the config to create your input_xxx, then that will overwrite on o reboot … so avoid initial if you need to leave last value in place.

1 Like

First thank you for your answers. Markus thanks for the tip but Mutt is right, first the basic way to do it, thats the best way to learn :slight_smile:

20 hours might be true, was building a lot of stuff and can control the whoole house through Snips…I’m in a rage :smiley:

The next question appeared right away:

Can I create those inputs dynamically somehow, i.e. for all thermostats or will I have to define each separately?

each separately

1 Like

As long as we’re discussing the custom variables component :wink:, I definitely looked at that early on. I have no problem with using custom components (especially since I created several myself), but I guess I don’t see how this one is any easier than the built-in input_xxx components. You set them the same way, and you retrieve their values the same way, right? What is easier about the variables custom component? (No, really, I’m interested in hearing. It’s been a while since I looked at it so maybe I’m missing something. :slight_smile:)

Allright, thank you!

Different data types under one component perhaps? You don’t need to use input_number, input_text, and input_datetime separately, you can just use variable if you have data among different types that you want stored.

Markus, I hope Im not putting words in your mouth but …
I think I’ve seen Markuss recommending this before as being easier to hide from users, who may try to mess with them.
If they can edit the yaml to show them, then I’ll let them.
I don’t have a 7 year old in the house (i.e. anyone smarter than me) so I’m happy :rofl:

Honestly. I think I did a search for variables months ago and that solution came up - so I started using it, been happy with it, built a bunch of stuff around it, and have been using it ever since. I was a relative NOOB at the time I implemented it, wasn’t aware of the input_xxxx method, so just stuck w/ what worked for me.

So, I’m basically following the if it’s not broke, don’t fix it model in my own implementation. I have nothing against input_xxxx and someday when I’m really bored and I’m sure I’ll remove and replace w/ input_xxxx :joy:

1 Like

Right now I only use it in one place on a “production” basis but I’ve used it before doing some testing.

The one place I use it is in an automation that maintains a history of motion detection data.

here is the automation:

  - alias: 'AS Update Last Motion'
    initial_state: 'on'
      - platform: state
          - binary_sensor.comp_rm_motion_template
        to: 'on'
      - platform: state
          - sensor.computer_room_camera_motion
          - sensor.livingroom_camera_motion
          - sensor.diningroom_camera_motion
          - sensor.garage_camera_motion
          - sensor.kitchen_camera_motion
          - sensor.deck_camera_motion
        to: 'Detected'
      service: variable.set_variable
        variable: last_motion
        attributes_template: >
            "history_1": "{{ variable.state }}",
            "history_2": "{{ variable.attributes.history_1 }}",
            "history_3": "{{ variable.attributes.history_2 }}",
            "history_4": "{{ variable.attributes.history_3 }}",
            "history_5": "{{ variable.attributes.history_4 }}",
            "history_6": "{{ variable.attributes.history_5 }}",
            "history_7": "{{ variable.attributes.history_6 }}",
            "history_8": "{{ variable.attributes.history_7 }}",
            "history_9": "{{ variable.attributes.history_8 }}",
            "history_10": "{{ variable.attributes.history_9 }}"
        value: >
          {{ trigger.to_state.attributes.friendly_name }} : 
          {{ as_timestamp(trigger.to_state.last_changed)| timestamp_custom('%X') }}

and here is the resulting entity:


I haven’t found any other use for it yet but I almost never use any of the input_xxx components either.

I use it like that now:


    name: Wohnzimmer Temperatur vor Aktion
    min: 4.5
    max: 35
    step: 0.5
    mode: slider


- alias: Fenster auf Wohnzimmer
    platform: state
    entity_id: binary_sensor.oeqblabla_state
    to: 'on' 
    - service: input_number.set_value
        entity_id: input_number.old_temp_wohnzimmer
        value: '{{ states.climate.wohnzimmer.attributes.temperature | float }}'
    - service: climate.set_temperature
        entity_id: climate.wohnzimmer
        temperature: '4.5'
- alias: Fenster zu Wohnzimmer
    platform: state
    entity_id: binary_sensor.oeqblabla_state
    to: 'off'
    service: climate.set_temperature
      entity_id: climate.wohnzimmer
      temperature: '{{ states.input_number.old_temp_wohnzimmer.state }}'

Just need to add the remaining sensors :slight_smile:


So it takes a parameter named attributes_template. Ok, that’s definitely something that the input_xxx components can’t do, AFAIK. Thanks! :slight_smile:

FWIW, my python_script can do this, too. And it does it in only 18 lines of code! :laughing: Except in this case you’d just use the standard data_template option of the service call.

      service: python_script.set_state
        entity_id: variable.last_motion
        state: >
          {{ trigger.to_state.attributes.friendly_name }} : 
          {{ as_timestamp(trigger.to_state.last_changed)| timestamp_custom('%X') }}
        history_1: "{{ states('variable.last_motion') }}"
        history_2: "{{ state_attr('variable.last_motion', 'history_1') }}"
        history_3: "{{ state_attr('variable.last_motion', 'history_2') }}"
        history_4: "{{ state_attr('variable.last_motion', 'history_3') }}"
        history_5: "{{ state_attr('variable.last_motion', 'history_4') }}"
        history_6: "{{ state_attr('variable.last_motion', 'history_5') }}"
        history_7: "{{ state_attr('variable.last_motion', 'history_6') }}"
        history_8: "{{ state_attr('variable.last_motion', 'history_7') }}"
        history_9: "{{ state_attr('variable.last_motion', 'history_8') }}"
        history_10: "{{ state_attr('variable.last_motion', 'history_9') }}"
1 Like