There are new automation options available and I’m trying to combine multiple pre-0.113 automations, but can’t get them to work. I have three lights and the automation has to do this:
If one of the lights are turned on, the other two lights turn on.
If one of the lights are turned off, the other two lights turn off.
The configuration validation gives me a “Configuration valid!”, but the GUI automation editor gives me error "Unsupported action: " and displays the yaml. The automation doesn’t turn on or off any lights. What am I doing wrong here?
I can’t comment on the Automation Editor because I don’t use it.
As for the automation you created, take a second look at each condition you created. According to the documentation, the first condition expects the state of all three lights to be on before it calls the turn_on service. That’s probably not how you thought it works. You thought if any one light is on then turn them all on.
Even if you fix that there remains a little problem with this approach because the moment it turns on the other lights, their state-changes will trigger this automation again.
First, without using to in the state trigger your automation will probably trigger too often, because any attribute change (such as brightness) will cause it to trigger, too. I’d recommend:
trigger:
- platform: state
entity_id:
- light.kitchen_counter
- light.kitchen
- light.kitchen_extractor
to:
- 'on'
- 'off'
That way it will only trigger when one of the lights actually turns on or off.
Second, you need to use the trigger variable in your actions to determine what happened (i.e., if a light turned on or off.) Just looking at the current state of the lights can’t tell you that unambiguously.
Third, this is another case of using the choose action when a simple service_template will do.
As far as the automation getting re-triggered when the other lights get turned on (or off), that’s true. However, since the lights will already be on (or off) nothing will change so it will stop there. (And to avoid any “already running” warnings, I suggested using parallel mode here.)
I was thinking along the lines that if you leave it in the default mode (single) the subsequent call to execute the already-running script would simply be blocked (since there’s no real need to run the same script concurrently). The ‘little problem’ is just the warning message posted to the log each time this happens.
I guess I’m in the minority. Given a choice between warnings in the log or having the automation run three times instead of just once (3 lights x 1 execution per light), I’ll take the warnings.
I seem to recall that, when this was in beta, there was an option that provided single mode without warnings. Any chance of this feature re-appearing in a future release?
Yea it would be nice to be able to change that. Since the default execution mode is single I think having the default log level for the message be warning is useful. That way if people just didn’t pay attention to the new execution mode option and ended up confused and wondering what was going on later there would be a clear log message explaining it.
But when you design around this functionality like what’s being discussed here it would be great to be able to turn that logging off or set the log level of the message to debug. There’s no reason to warn in this case, you’re explicitly relying on that behavior in your logic.
Yes, it’s on my list of things to do. Hopefully I’ll come up with an acceptable way in the next few releases.
And, BTW, I’m in total agreement. I like the warning by default, but when you know you want an automation or script to work that way, then I hate a warning I can’t filter. (It wouldn’t be so bad if warnings could be filtered out via logger, but they can’t. And it’s even possible now to set a logger level per script or automation, since their log names now include their object_id’s. E.g., homeassistant.components.script.my_script.)
There were several approaches discussed before 0.113.0 was released, but no consensus, so it was decided to leave it as is for now.
My preferred choice is to be able to set the log level when the “max” is exceeded, which would apply to single, parallel & queued (where the “max” for single is effectively 1. It, of course, does not affect restart mode since it’s impossible to have more than one in that mode.) This would allow setting the log level on a per script/automation basis where the default is warning. I think besides the normal levels, another choice, such as none, would be good, too.
That’s the reason I asked in the .112 release thread for the ability to make both the entity_id and states of multiple conditions as either “and” or “or”.
like possibly:
condition:
platform: state
entity_id: or
entity_ids:
- device_tracker.frenck
- device_tracker.daphne
state: and
states:
- 'home'
- 'work'
But unfortunately Frenck completely shot that down immediately and wasn’t even interested in considering it…
I take that as a no for now…
will try to formulate a FR.
same would probably go for the use of {{trigger.to_state.state_with_unit}} ? I’ve recently found the need for that, tried it without getting errors logged, but in that field, simply nothing is displayed.
Would have hoped since even the developer-tools/template show this as example:
For loop example:
{% for state in states.sensor -%}
{%- if loop.first %}The {% elif loop.last %} and the {% else %}, the {% endif -%}
{{ state.name | lower }} is {{state.state_with_unit}}
{%- endfor %}.
it would have been an option for the trigger.states…
Hope it can be realized, would simplify things even more.
BTW, you can use YAML anchors to make this less error prone:
- alias: Sense Active change
id: Sense Active change
trigger:
- platform: state
entity_id: &sense_active_change_entities
- binary_sensor.espresso_keuken_active_threshold
- binary_sensor.quooker_keuken_active_threshold
- binary_sensor.koelkast_keuken_active_threshold
- binary_sensor.cv_garage_active_threshold
etc
to: 'on'
for:
seconds: 10
- platform: state
entity_id: *sense_active_change_entities
to: 'off'
Yes it is. I use it quite a bit but reading this has prompted me to think about it a bit more…
Is it possible to make it even more flexible with a syntax that makes something like this possible?
- alias: Sense Active change
id: Sense Active change
trigger:
- platform: state
entity_id: &sense_active_change_entities
- binary_sensor.espresso_keuken_active_threshold
- binary_sensor.quooker_keuken_active_threshold
- binary_sensor.koelkast_keuken_active_threshold
- binary_sensor.cv_garage_active_threshold
etc
to: 'on'
for:
seconds: 10
- platform: state
entity_id: *sense_active_change_entities
- another.entity_id # <<<---
to: 'off'
