Using Input Select as an Array (Global variables) in Automations

Configuration
1

Not sure if this has been documented anywhere, but I have been using Input select as Global variables lists (Arrays) in Automations.

Take the following input Select

Array:
    name : Array Test
    options:
      - Option A
      - Option B
      - Option C
      - Option D

You can convert this to a list in JInga2 with the following

{% set arraytest = state_attr("input_select.array","options") %}

You can extract an array element by using

`{% set obj = arraytest[1] %}` 
{{obj}}

This will return ‘Option B’ Jinga2 lists start at element 0

I use this to trigger actions from Alexa using a virtual bulb . The brightness level corresponds to an element in the item select.

see

Hope this is of some use

10 Likes
2

Just been trying to do exactly the same thing… stupidly useful hack this one! rather than creating groups of things and then expanding them and maping them to get entity name this is MUCH better - means the templates don’t listen to all the different array elements… Wish there was a specific helper to do this.

An example…

I’ve got a bunch of things that create ‘light.x’ entities (like the status light on a device for example) - I want to get a list of all the ‘real lights’ that are on so expanding the light domain and filtering for ‘state on’ works a treat - but there are these silly device lights in that list. I can filter against a static list of strings to just remove them every time but that means hard coding the entity names like light.router_status_light into an exception array - now I can put them in a helper and just expand that as detailed here… one place for all those odd global arrays I need to create.

3

That hasn’t been necessary for a while. I’d have to check the change logs to see when it was added, but for a while now both Helper groups and legacy style groups have an attribute entity_id which is an array of the entity IDs of the group members.

Since the addition of custom jinja files in 2023.4, it is also possible to use those to store arrays or mappings.

#constants.jinja

{% set not_lights = [ "light.tablet_screen",
"light.router_status", "light.example" ] %}

These can then be imported where ever they are needed.

{% from 'constants.jinja' import not_lights %}
{{ states.light | rejectattr('entity_id', 'in', not_lights)
| selectattr('state', 'eq', 'on') | list }}
1 Like
4

Very helpful! I’ve got it working custom_templates as suggested (and much better place to do it) - it may also help solve another problem I’ve hit with mapping colour names to HSV values - a large table seems to be the obvious solution as I can’t get to color.py in HA core it would appear which is actually where all the code I want to have access to is already lurking!

5

You may want to take a look at the Color-Multi-Tool custom macro set

6

Exactly what I was about to set out and write!

1 Like