For days now I’ve been reading threads and the documentation and trying out code in the Developer Tools and VS editor.
I have a bunch of covers that I want to control with local wall switches which I have as binary sensors, doubled, since I have one binary sensor for the UP key and one for the DOWN key, for each local switch. I want the cover to open if it’s closed and up press UP, if you press UP again it should stop. Same for the closing action.
Using the assumed states for the covers should be enough to achieve this.
However, instead of writing 44 rules which are the same only changing the entities, I’d like to try and make one or two rules where it’s dynamic. When a bynary sensor is pressed, it would use a list to match the correspondent cover.
I’m in the early stages of trying to make this rule, and have already been stumped by not being able to make the trigger entity_id accept a list. From what I’ve seen and tested, this should work? I’ve tried using a single line with quotes, returning a comma separated line instead of a list, but VS always seems to give me “String does not match the pattern”.
What am I doing wrong? Any better suggestions on how to achieve this automation?
I am trying to understand the use case. But are you saying if any of the the binary_sensors marked with _up are ‘on’, then you want to trigger the automation?
Or are you trying to trigger a different entity open/stop/close based on the trigger entity?
The rule is posted is just a start, eventually I’d replace the static entity_ids in it with something that gets replaced with correct values.
So let’s say I’m in the kitchen and press the UP button on the wall for the kitchen rollershutter, this rule detects a binary sensor has changed to on, then it would check a list to match the correspondent cover and it’s state, it it’s already open, issue command stop, if it’s closed issue command open. Repeats for every other room in the house, both for outdoor and indoor covers.
The statement I used on the trigger entity_id returns all the up binary switches both for the outdoor covers and indoor covers. My idea was even to one set of static lists, use a loop to match the binary sensor then use the same index number to match the cover on a different list. Something like:
{% set localup = [
'binary_sensor.bl_up_cozinha_jardim',
'binary_sensor.bl_up_gabinete',
'binary_sensor.bl_up_garagem_1',
] %}
{% set localdown = [
'binary_sensor.bl_down_cozinha_jardim',
'binary_sensor.bl_down_gabinete',
'binary_sensor.bl_down_garagem_1',
] %}
{% set localrollers = [
"cover.cortina_cozinha_jardim",
"cover.cortina_gabinete",
"cover.cortina_garagem_1",
] %}
{% set trigger = 'binary_sensor.bl_up_gabinete' %}
{% set i = 0 %}
{% for i in range(2) %}
{% if trigger == localup[i] %}
{{ localrollers[i] }}
{% endif %}
{#{{ localrollers[i] }} {{ localdown[i] }} {{ localup[i] }}
#}
{% endfor %}
The actual lists are a lot longer I just cut them down to 3 elements to post here!
Thanks for the help!
Reading again… I think you want something like this.
trigger:
platform: event
event_type: state_changed
condition:
- condition: template
value_template: {{ trigger.event.data.new_state.domain == 'binary_sensor'
and trigger.event.data.entity_id.endswith('_up')
and trigger.event.data.old_state is not none
and trigger.event.data.old_state.state == 'off'
and trigger.event.data.new_state is not none
and trigger.event.data.new_state.state == 'on' }}
...
...
Probably an event trigger is your best bet for this. Listen for state_changed and then condition out what you need.
This won’t work. Not every field accepts templates and entity_id in trigger is one of those fields. You cannot use a template here, static values only.
This won’t really work either. The problem is that it will trigger only when the first binary sensor that matches that pattern turns on. If one is already on and another turns on then nothing will happen.
I did solve this in my own system but I almost hesitate to share it because its really complicated. What I did is this:
I have an automation that has a list of regex patterns its interested in (like for example with yours I’d probably have binary_sensor_up: '^binary_sensor.\w+_up$' in the variables section for your case)
Whenever HA starts or the entity registry changes it loops through all the regexes. For each one it builds a list of all the entities that match that ID
It then compares that list to what that list used to be. What the list used to be is stored in the attributes of an input_select (more on this in a second)
If that regex has changed it adds an item to the input_select’s list denoting the list of entities that match that regex have changed
At the end of the automation, for each regex that has changed it writes out a YAML file into a special folder. Each file is simply a list of entity IDs that matched that regex
It also writes out an index YAML file. This YAML file is a dictionatry with a field per regex and it !includes the corresponding list YAML file
It then reloads all scripts, template entities, groups, input selects and (lastly) automations since that’s all the places those lists may have been referenced. Automations must be last because the current automation will end when it is reloaded
How does this work you might wonder? Well then my automations look like this:
trigger:
platform: state
entity_id: !include /config/common/auto/binary_sensor_up.yaml
state: 'on'
You may not be able to use templates for entity IDs but you can use !include. So this effectively makes it dynamic. As for the index file, that is used in the special input_select I mentioned. I have this in my customize.yaml for it:
Which basically means the input select is huge. It has an attribute per regex with the value of the list of entities that matched that regex last time I calculated it. Which allows me to diff it with the current values to know when I need to write out the file. It also means I can easily reference the list of entities that matched a particular regex in templates.
I can try and put together a package if you want. I think its fairly reusable. But its seriously complex and there’s a lot of moving pieces with the files.
The other option I came up with is this:
Listen for the generic state_changed event
In the condition, filter out all events that don’t meet your criteria
This works but I really didn’t like it personally. The problem is you are listening for every state changed event. There’s so many! That’s why max has to be like 100. And I have no idea what the performance impact is of that.
It’s also completely untraceable for debugging. Every single state_changed event will generate a trace even though most will be filtered out by the condition. Which means you have like maybe a few seconds to get to your trace before its replaced with a new one.
This bothered me enough that I came up with the super complex file based one. But if works for you it is simpler, can be done all within one automation.
Anyway those are the only two solutions I was able to come up with. If you were hoping for a simple one then sorry, there isn’t. You might want to consider looking at Node RED for these cases. It’s equivalent of the state-type trigger, the events: state node supports this. It allows you to trigger off any entity if its ID matches a substring or regex. When I migrated my automations from Node RED to HA I was generally happier but that particular feature I really miss.
EDIT: Actually the state changed one could work a bit better in your case since you’re specifically looking for when these binary sensors turned on. This should allow you to move more of the condition into the trigger like this:
This makes it significantly more traceable since you will only get a trigger when something changes about an entity that has state on rather then every single state change.
Nope this doesn’t work.
This is all true. I am not sure about the performance impact though. you can literally put the listener in the developer tab and see just how many there are. Its going to fire a lot and be untraceable that is a fact. I’d guess though the performance impact isn’t much if any.
Testing this it didn’t work. I read a issue about why and I cant remember. But I think its a dictionary and can’t parse it.
EDIT: IF you use the event method, i’d disable tracing entirely. ITs just not going to help you. Might as well save the writing of the traces.
As an experiment, you might want to try the following technique I suggested to someone else in the same situation (it worked for them but YMMV).
It all hinges on the following Template Sensor:
template:
- sensor:
- name: Latest Binary Sensor On
state: >
{% set x = states.binary_sensor | selectattr('state', 'eq', 'on')
| selectattr('entity_id', 'search', '_up') | sort(attribute='last_changed', reverse=true) | list %}
{{ (x[0].entity_id if now() - x[0].last_changed < timedelta(seconds=2) else '') if x | count > 0 else '' }}
What it does is report the entity_id of whichever binary_sensor whose state recently changed to on (i.e. within the last 2 seconds). Otherwise it reports a blank string (for the case where the binary_sensor changed state to some value other than on).
The Template Sensor can be used in an automation using a State Trigger. It’s important that the automation contains a condition to reject when it receives a blank string (or use a not_to option).
Thanks everyone for the incredible input.
You’ve given me much to study up on and test! I’ll report back!
I’ve used OpenHAB for 6 years and at the time I just wrote these rules statically because I was in a rush to get it done and working as we were finishing the house and preparing to move in. And I never updated OpenHAB because I ran into breaking changes on 2.x, since my 1.x was (still is) working perfectly never touched it again. Then a friend pushed me to try HA and I must say I’m really impressed and loving it, since I’m no rush this time, I figured I’d try to get things right or as good as I can, mostly as an opprtunity to learn the platform.
So having read all your posts it’s pretty clear my initial idea isn’t possible, but how about I just use a static list for the trigger entity_id’s and the template code for the rest. Even if it’s not as dynamic, it still beats writing the same rule 44 times.
I’ve written this and VS isn’t complaining, config tests valid and automation shows on the UI list, but I’ll only be able to test it live later today or tomorrow.
In the meanwhile here’s the full rule, this one is just for the UP&STOP motion, I’d have another one similar to this with the DOWN binary sensor list and the closed state check for the DOWN&STOP motion.
Let me know what you think, if you think it’ll work or if it can be improved?
EDIT: After testing, I had to change some things around, corrected the code below and it’s working. Two rules (only posted one), albeit a bit long but for my knowledge level I think they are ok for now, maybe someday I’ll know enough to make these a bit cleaner or more streamlined.
Since what was causing the issue was the entity_id on the trigger and that’s just a static list of 22 sensors I just copied and pasted those so I could write and test the rest of the automation.
It’s working now as I posted above (edited my previous post), now I might try and make it better and replace the trigger static list with your statement.
I currently have 2 rules like the one posted above, one for the UP sensors and one for the DOWN sensors.
Thanks for all your help! What a great community!
FWIW, what I proposed wouldn’t require listing 22 binary_sensor entities twice (not even once). However if you don’t mind listing them individually then all’s well that ends well.
So, I ran into a similar issue and this is how I solved it.
My Hue dimmer switches and smart lights are all in Zigbee2MQTT.
My naming convention is as follows:
For the lights, I either use single lights or groups and the name is basically the basis. For instance, I have 2 lights in the upper hallway. They are named:
Upper Hallway 1 (entity_id in HA: light.upper_hallway_1)
Upper Hallway 2 (entity_id in HA: light.upper_hallway_2)
I combined them in Zigbee2MQTT in a group with the name (entity_id):
Upper Hallway (entity_id in HA: light.upper_hallway)
The switches follow the same name:
If there is only one switch for a group, it would be: Upper Hallway Switch
In HA, there will be a sensor with the name sensor.upper_hallway_switch_action
If there are more than one switches, it will be: Upper Hallway Switch 1 (or 2, etc.)
In HA, there will be a sensor with the name sensor.upper_hallway_switch_1_action
So, I created the following automation:
- alias: Generic Hue Dimmer Switch actions
trigger:
- platform: event
event_type: state_changed
condition: "{{ '_switch_' in trigger.event.data.entity_id and '_action' in trigger.event.data.entity_id and trigger.event.data.new_state.state.endswith('_release') }}"
action:
service: script.hue_dimmer_action
data:
source_entity: "{{ trigger.event.data.entity_id }}"
source_action: "{{ trigger.event.data.new_state.state }}"
Now, whenever I add a switch and lightbulbs/lightbulb groups, I have to ensure the naming convention and the switch works straight away with the intended lights without having to add new automations.
Might as well save the writing of the traces.