One automation, different actions (services) for same trigger (button press) based on condition

Configuration
1

I want to use a single automation with the single trigger (button press/MQTT message), then do one of two different actions depending on a condition.
This seems like it should be much easier…

I just want a simple if/else then two separate actions, but can’t figure out how.
The closest I got was with service_template but when the if is false, there’s no service so that’s invalid (non-canonical, complete example):

- alias: 'Watts Clever 4 ON'
  trigger:
    platform: mqtt
    topic: rtl_433/Smoke-GS558/1307
  condition: 
    condition: and
    conditions:
    - condition: template
      value_template: "{{ trigger.payload_json['code'] == 'f0a368' }}"
    - condition: template  # Don't respond to repeated signals (2 = seconds)
      value_template: "{{ (as_timestamp(now()) - as_timestamp(state_attr('automation.watts_clever_1_on', 'last_triggered') | default(0)) | int > 2)}}"
  action:
  - service_template: >
      {% if is_state('media_player.yamaha_zone_2', 'off') %}
        homeassistant.turn_on
      {% endif %}
    entity_id: script.listen_to_net_radio
  - service_template: >
      {% if not is_state('media_player.yamaha_zone_2', 'off') %}
        homeassistant.turn_off
      {% endif %}
    entity_id: media_player.yamaha_zone_2

I tried using conditions in the action block, but I want two separate actions, not one then conditionally the second one.

The following works, but seems so redundant:

- alias: 'Watts Clever 4 ON on'
  trigger:
    platform: mqtt
    topic: rtl_433/Smoke-GS558/1307
  condition: 
    condition: and
    conditions:
    - condition: template
      value_template: "{{ trigger.payload_json['code'] == 'f0a368' }}"
    - condition: template  # Don't respond to repeated signals (2 = seconds)
      value_template: "{{ (as_timestamp(now()) - as_timestamp(state_attr('automation.watts_clever_1_on', 'last_triggered') | default(0)) | int > 2)}}"
    - condition: state
      state: 'off'
      entity_id: media_player.yamaha_zone_2
  action:
    service: homeassistant.turn_on
    entity_id: script.listen_to_net_radio
- alias: 'Watts Clever 4 ON off'
  trigger:
    platform: mqtt
    topic: rtl_433/Smoke-GS558/1307
  condition: 
    condition: and
    conditions:
    - condition: template
      value_template: "{{ trigger.payload_json['code'] == 'f0a368' }}"
    - condition: template  # Don't respond to repeated signals (2 = seconds)
      value_template: "{{ (as_timestamp(now()) - as_timestamp(state_attr('automation.watts_clever_1_on', 'last_triggered') | default(0)) | int > 2)}}"
    - condition: not
      conditions:
      - condition: state
        state: 'off'
        entity_id: media_player.yamaha_zone_2
  action:
    service: homeassistant.turn_off
    entity_id: media_player.yamaha_zone_2

Any thoughts on how to do this nicely with no duplication would be appreciated, thanks!

2

I think you’re on the right lines with service_template. There may be a better solution, but you could write a “do nothing” script and call its script.turn_on service to get around your problem.

Creating and saving a script in the UI with just a name — no actions — appears to create a valid “no-op” script, and running script.turn_on effectively does nothing.

3

Thanks for the reply. I thought about that, a “pass” kind of script… still seems like a hack.
I just realised since I’m duplicating anyway, I could make a stop/off script such that the service is the same and the entity is the only difference:

- alias: 'Watts Clever 4 ON'
  trigger:
    platform: mqtt
    topic: rtl_433/Smoke-GS558/1307
  condition: 
    condition: and
    conditions:
    - condition: template
      value_template: "{{ trigger.payload_json['code'] == 'f0a368' }}"
    - condition: template  # Don't respond to repeated signals (2 = seconds)
      value_template: "{{ (as_timestamp(now()) - as_timestamp(state_attr('automation.watts_clever_1_on', 'last_triggered') | default(0)) | int > 2)}}"
  action:
  - service:
        homeassistant.turn_on
    data_template:
      entity_id: > 
        {% if is_state('media_player.yamaha_zone_2', 'off') %}
        script.listen_to_net_radio
        {% else %}
        script.stop_the_music
        {% endif %}

Again, still feels like it breaks the “DRY” principle to have a script that just does a simple turn_off, but better.
I’m still open to suggestions (learning), thanks.

4

I think you might be able to do it like this:

- service_template: >
    {% if is_state('media_player.yamaha_zone_2', 'off') %}
      homeassistant.turn_on
    {% elif not is_state('media_player.yamaha_zone_2', 'off') %}
      homeassistant.turn_off
    {% endif %}
  data_template:
    entity_id: >
      {% if is_state('media_player.yamaha_zone_2', 'off') %}
        script.listen_to_net_radio
      {% elif not is_state('media_player.yamaha_zone_2', 'off') %}
        media_player.yamaha_zone_2
      {% endif %}
1 Like
5

Even cleaner:

  action:
    - service_template: light.turn_{{ trigger.to_state.state }}
      data:
        entity_id: light.office_desk_lamp
6

Why elif 's.?
Besides not an else in sight tut tut !
:rofl:

7

Because I don’t know if ‘off’ & ‘on’ (or in the example above “not ‘off’”) are the only states for the media player entity.

It’s not required if the only possible states are ‘off’ or ‘not off’.

But even without the ‘else’ and in the event that those aren’t the only states then it will just write an error message into the log but still work so not a big deal to the non-ocd among us. :wink: If it does become an issue then just put an else clause and add a dummy service and/or a dummy entity in.

8

That will only work if the state of the trigger is ‘on’ or ‘off’.

it may very well be the case but without additional details on the trigger topic we can’t know if that will work.

9

Thanks for the thoughts/replies so far.
The trigger is just a simple MQTT message from a button - same every time.
The condition is just off or not off (not ‘on’, but ‘idle’, ‘playing’, etc.).

@finity - that’s a cool idea of using one service_template and data_template, but it duplicates the if/else.
@jwelter - that would only work if either the service or entity_id/data were the same; mine are different actions.

There appears to be no method that doesn’t violate DRY…

10

That’s probably true (but I’m not sure that having more than one of the same if/else in different sections violates it or there may even be other methods not previously thought of yet) but why is that such a problem?

If it works and gives you the result you want and you understand it enough to maintain it then I’d say use it. Or not and stay with your first iteration that worked. It’s not like you’re selling the code as a service to others and going thru a review process for it.

There are likely other methods of accomplishing this like creating binary sensors or even using other programming languages (python or node-red) but if you want to stay within HA and use yaml/jinja you are kind of stuck just making do and making it work even if it’s not “dry”.

11

You’re correct; it should be. And, coincidentally, based on some recent architecture discussion, and leveraging off work that I’ve recently completed on improving HA’s native scripting language (which should be in the 0.113 release), I’m just about to start implementing a new script action option, namely choose. This will make it possible to implement if-elif-else type statements. See the link for what it will look like. (I actually just sat down to start work on it, but thought I’d check recent posts, first. :wink:)

2 Likes
12

You’re right; the bottom line is getting it to work satisfactorily.
To answer your question… I teach computer programming with a focus on best practice.
Duplicating the basic service by using a script is just a bit of extra work for the programmer;
Duplicating the if-else is duplicating both work for the programmer AND work (and hence, execution time) for the computer.

@pnbruckner - awesome to hear that this is being addressed!
I read through most of that discussion you linked. I’m happy with the more generic approach of using multiple if/conditions compared with the template and switch-style labels.
I look forward to it! If there’s any chance you can reply here when it’s out, that would be super!

13

Well I think I just finished implementing it. Next comes some ad hoc testing, adding formal tests & updating the docs. It’s possible I’ll have PRs ready in time for the 0.113 beta cutoff (next Wednesday.) But, sure, I’ll keep you posted.

1 Like
14

All script/automation enhancements, including the choose action, are available in the 0.113 beta. Assuming all goes well, which it looks like it is, 0.113 should be released tomorrow.

2 Likes