I'm having a hell of a time. I'd like to monitor a specific state.select on all of my switches. The select states currently consists of ['Switched' , 'Always On' , 'Always Off'].
I can template a list of all the entities I'm interested in with {{ states.select | selectattr('entity_id','match','.*relay_config') | map(attribute='entity_id') | list }}
However, I can't get the state automation trigger to take the list for it's entity_id.
#Templating automation triggers for state change of multiple entities
grim pebble
The intended goal for this automation is when the state of select.[devicename]_relay_config is changed, I want to create a group populated with {{ states.light | map(attribute='entity_id') | select('search', '.*[devicename]*.') | select('search', '.*bulb*.') | join(',') }}
weary sable
I'm having a hell of a time. I'd like to monitor a specific state.select on *all...
You can't template triggers like that
triggers are one of the few places where templates are not allowed
you can do limited templates but limited templates don't have access to the state machine
grim pebble
Okay, so what about a blueprint that uses the list as an input select?
weary sable
yep, as long as the list is static
grim pebble
Not a hardcoded list, but .. oh
weary sable
yep
your best option to have dynamic lists is to create an old school group
with an automation that builds the group entity_id's using group.set
then make a template sensor using that group and have it output a unique_string for each combination of lights on/off
then your automation that uses that template sensor changing states as the trigger
and you reperform the templates in the variables
to figure out what you're acting on
otherwise, you can just simply maintain the list in your automation
I know that's alot to take in, but I can help you build it all rather easily
I have to walk a way for a moment, but when I come back I'll write it out for you if you truely want dynamic lists of entities.
grim pebble
Take you time, let me describe the end goal of what I really want this for
grim pebble
All of my switches in my house are ESPhome smart switches. All the switches use the select I mentioned to active the relay to keep the bulbs powered.
For the switches set to 'Always On', I have to create the corresponding light group with all the light entities inside. I use one automation for all my switches, it just triggers a light.turn_on for the light group with the same name as the switch.
This works, but not well - some bulbs are brightness-only, some bulbs have color temp.
For a fix, I made a select for each bulb, with a bunch of 'presets'. The presets can be customized on the bulb itself so I now have a uniform method of activation for all my bulbs. But that won't work on the group level, I would have to expand the group and call select.[bulbname]_effect for all bulbs in the group
I was hoping for a way to cycle through the list for each button press event, starting with 'effect_bright', and after a timeout the position in the list gets reset, so say after 5 mins if I click the switch it goes back to the start of the list
weary sable
I guess I still don't follow your intentions. YOu want a button that cycles through groups of lights? What are you doing with the 'current active group'?
grim pebble
The button is referring to the wall switch button
weary sable
ok, so you click the button and it changes what group you're using?
grim pebble
so when I activate the livingroom switch, it triggers the livingroom lights
the light group will always be paired to it's corresponding switch
weary sable
ok, so you just want a switch that turns on and off your lights? That's it?
so why does the group have to be dynamic?
grim pebble
the group was just a way to make sure the bulb entities stay current. Since my current automation does not target the individual bulbs, but rather blindly activates the group
If the automation were to expand the group and target the bulbs instead, I would need an easy way to include the corresponding bulbs if I had to change any
weary sable
Yes, I get that but why does it need to be a dynamic group? can't you just maintain a list of bulbs that correspond to the switch?
grim pebble
That's what I"m currently doing. The dynamic group was an attempt to automate that, since I"m constantly modifying the firmware, the names vary slightly
weary sable
just add a unique_id to your entities, and change the entity_id once they are in HA
if the firmware changes the name, fix that
by not including the firmware in the name
grim pebble
I've went through a few iterations already, I started with names like 'livingroom1', then 'b_livingroom_1', and it turned into 'bulb_livingrom_shelf', using one bulb as an example
weary sable
yeah, sure whatever. Doesn't matter, just don't change the name on the ESPHome side. Only change it on the HA side. Once you have your naming convention, then create the groups
then when you add something, you keep that naming convention and add the device to your group
any changes on ESPhome side won't be seen on HA side
also, speaking from experience, keep the entity_id the same. Change the friendly name and you'll never run into renaming crap again
grim pebble
correct. That's the plan I've been trying to uphold. https://imgur.com/a/NMExKvZ
weary sable
i.e. my living room bulbs have generic entity_ids that don't associate with the room they are in. Only the final group of lights has the name in the end.
grim pebble
Honestly, that makes sense. I was considering for a while filtering the hostname, but I see what you mean
Looking at my dashboard, in practice, I don't have any individual bulb entities displayed at all. They're all groups, so the bulb's friendly_name doesn't matter.
My current automation for all switches```yaml
alias: Button Events
description: ""
trigger:
- platform: event
event_type: esphome.single
event_data:
action: single_press
condition: []
action: - if:
- condition: template
value_template: >-
{{ expand(target_light_group) | selectattr('state', '==', 'on') | list
| count > 0 }}
then: - service: light.turn_off
target:
entity_id: "{{target_light_group}}"
else: - service: light.turn_on
data:
kelvin: "{{color_temp}}"
brightness: 255
target:
entity_id: "{{target_light_group}}"
variables:
target_light_group: >-
{{ states.light | selectattr('entity_id','search','group_') |
selectattr('entity_id','search',trigger.event.data.device_id | slugify) |
map(attribute='entity_id') | list }}
min_color_temp: 4000
max_color_temp: 2200
color_temp: >-
{{ [([(((4791.67 - 3290.66/(1 + 0.222 * ([([0,state_attr('sun.sun',
'elevation')]|max),90]|min**0.81))))|int),max_color_temp]|max),min_color_temp]|min}}
mode: parallel
- condition: template
Instead of service: light.turn_on, I'd like to instead expand the group, and cycle through select.(bulbname)_effect (the select presented by esphome firmware) for all entities in the group
weary sable
If you do that, it's going to be much slower
grim pebble
hmm.
even with mode: parallel?
I'm honestly not sure why the existing automation is slow. But it is slow as well.
roughly 3 secs to turn on/off the fixture
Would it be beneficial to schedule something to perform the expands and searches into prepared lists of entities?
weary sable
mode parallel means the automation will run in parallel, not the actions
grim pebble
I'm just spitballing, I don't really know how it works or if it's even possible