How to save a value?

Configuration
1

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,
Thomas

1 Like
2

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.

3 Likes
3

Personally I use this: https://github.com/rogro82/hass-variables

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

2 Likes
4

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
5

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
6

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:

7

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?

8

each separately

1 Like
9

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:)

10

Allright, thank you!

11

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.

12

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:

13

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
14

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'
    trigger:
      - platform: state
        entity_id:
          - binary_sensor.comp_rm_motion_template
        to: 'on'
      - platform: state
        entity_id:
          - 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'
    action:
      service: variable.set_variable
      data:
        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 }}"
          }
      data_template:
        value: >
          {{ trigger.to_state.attributes.friendly_name }} : 
          {{ as_timestamp(trigger.to_state.last_changed)| timestamp_custom('%X') }}

and here is the resulting entity:

ex

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

15

I use it like that now:

configuration.yaml

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

automations.yaml

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

Just need to add the remaining sensors :slight_smile:

4 Likes
16

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 set_state.py 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
      data_template:
        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