Store list/dictionary ?!

Configuration
1

i’m practing with HA and jinja… i can built a list this way in a script

- variables:

  mylist: "[
       JINJA CODE HERE
  ]"

and use it with jinja filter or whatever. as it won’t be updated often i’d like to store anywhere…
is it possible?! i think not, right?! python script (i have to study python yet)?!

thanks

2

There are no global variables in Home Assistant that allow you to store and update data as a list. The closest thing is an input_select (which stores its data in an attribute as a list) but any changes you make to it are lost after a restart.

You may need to investigate custom integrations that provide the functionality of global variables. Here are two:

3

i’m already using the first one, it stores strings only… going to try the second and search github next time, thanks

4

Because it (and the other one) store data in an entity’s state which can only be type string.

The answer to your original question remains the same: what you want to do cannot be done (currently).

5

I know this is an old thread, but I found it while having the exact same problem. So how about storing the dictionary as a string in an input_text

service: input_text.set_value
data_template:
  value: >
        {% set dict = { 'key1':'value1', 'key2':'value2', 'key3':'value2' } %}
        {{ dict }}
target:
  entity_id: input_text.my_dict

You can then restore it like this:

{% set dictstr = states('input_text.my_dict').replace("{","").replace("}","").replace("'","").split(", ") %}
{% set n = namespace(dict=[]) %}
{% for i in dictstr %}
{% set pair = i.split(":") %}
  {% set n.dict = n.dict + [(pair[0], pair[1])] %}
{% endfor %}
{% set dictrestored = dict.from_keys(n.dict) %}

Not a very nice solution but at least it is working without custom integrations.

2 Likes
6

now you can use this

7

I don’t actually understand how you can use Templating to store a dictionary? Could you explain a bit more please?

8

You can use a Trigger-based Template Sensor to store data as a dictionary, list, boolean, etc.

Here are two examples:

  1. A separate entity for each variable. The entity’s state is limited to storing a string (like all entities) but its attributes can store other data types.
  1. A single entity for multiple variables. Each variable is stored as a separate attribute (therefore its type can be dictionary, list, etc). Variables can be defined dynamically.
1 Like
9

Thank you so much, that looks really interesting. Still a workaround though.
I need this in just one automation, so I will stick to the input_text parsing for now. An input_dictionary would be nice eventually.

10

It’s a native capability.

A State Object has a state value, constrained to storing a string limited to 255 characters, and an attributes value which is a dictionary, able to store key-value pairs of any type.

All entities store their information, in the state machine, as a State Object. It’s just a matter of choosing something that allows you to easily modify/update its attributes (because that’s the only place able to store a dictionary). The two (sensor) integrations that allow for that are MQTT and Template which has the advantage of not requiring additional infrastructure (like an MQTT broker).

It would still have to store its information as a State Object so the only place it could put a dictionary is in attributes, same as the Trigger-based Template Sensor mentioned previously.

11

Defining a dictionary for value mapping:
I used following template sensor:

    - name: "My Map"'
      unique_id: my_map
      state: ''
      attributes: !include my_map.yaml

and the file my_map.yaml contains a dictionary-object:

  { 
    '1041': 'OvExt',
    '1042': 'UnExt',
    '1069': 'VArCtlVol',
  }

to get result of the map:

    {{ state_attr("sensor.my_map","1042") }}

result: UnExt

In my usecase, the dictionary has about 130 items. (It is better to store it in own file)

6 Likes