Change State Without Triggering Rules

[Soloam]

Hello, I have a input select that is updated by a automation (mqtt trigger) also if I change the value of input select I send a mqtt message! The problem is that when I recive a mqtt message to update the input select option, that update triggeres the on change rule and sends a mqtt message! Can I update the input select state without triggering the other rules?

Thank you all

[123 (Taras)]

The solution is to use an input_boolean to serve as an “update-lock” flag.

Example:
Automation #1 is responsible for updating the input_select.
Automation #2 is responsible for monitoring input_select and publishing its state-changes.

• Automation #1 sets the input_boolean then updates the input_select.
• The update triggers automation #2. However, it has a condition that checks if the input_boolean is set. If it is set (meaning automation #1 is in the process of writing to input_select), then automation #2 does not execute its action (publishing the state-change).
• Automation #1 completes its action by resetting the input_boolean.

The following thread contains the complete solution. for an input_number, provided by AhmadK.

Prevent an input number changed by MQTT publish to run its action

i’m using and input number as a timer set for my boiler: input_number: boiler_timer_set: name: ‘Timer Set’ initial: 0 min: -240 max: 240 step: 15 unit_of_measurement: Minutes using the following automation: automation: move status ui slider when an mqtt update received - id: boiler_timerstatus_change alias: Boiler Timer Status Setter initial_state: 'on' trigger: platform: mqtt topic: 'home/boiler/timer' action: service: input_number.set_value data_temp…

Here’s essentially the same code, adapted for an input_select:

input_boolean:
  update_lock:
    initial: 'false'

Automation #1

-  alias: 'Update whatever'
   trigger:
     platform: mqtt
     topic: 'whatever'
   action:
    - service: input_boolean.turn_on
      entity_id: input_boolean.update_lock
    - service: input_select.select_option
      data_template:
        entity_id: input_select.whatever
        option: '{{trigger.payload}}'
    - service: input_boolean.turn_off
      entity_id: input_boolean.update_lock

Automation #2

-  alias: 'Monitor whatever'
   trigger:
     platform: state
     entity_id: input_select.whatever
   condition:
     condition: state
     entity_id: input_boolean.update_lock
     state: 'false'
   action:
     service: mqtt.publish
     data_template:
       topic: 'somewhere'
       payload: "{{states('input_select.whatever')}}"

[Soloam]

That worked 100%. Thank you

[gdrift (GD)]

Isn’t it a common enough pattern to justify support for it in core?

[Soloam]

In my opinion it should! It’s so annoying solution for something so simple and trivial!

[123 (Taras)]

@gdrift

justify support for it in core?

@Soloam

In my opinion it should!

Home Assistant is a community-based project therefore you have these options available to you:

1. If you have the required programming skills, you can create the new feature and submit a Pull Request in GitHub.
2. If you do not have the required skills, you can create a Feature Request (others can vote for it) and hope someone, who does have the required skills, likes the idea and implements it.

[SteveDinn]

How about a condition where the mqtt message is not published if the state change would set the input_select to the value it already holds?

[user512]

It’s an old thread, but I fall here searching to change the state of an input_boolean from another automation, without triggering the usual automation related with that boolean.

And did it this simple way: 1.- turning off the automation, 2.-toggle the boolean, 3.-reactivate the automation. It may be a simpler way to do it in some cases.

    - service: automation.turn_off
      entity_id: automation.piscina_newdepuradora_se_detiene
    - delay: 00:00:01
    - service: input_boolean.turn_off
      entity_id: input_boolean.piscina_modo_newdepuradora
    - delay: 00:00:01
    - service: automation.turn_on
      entity_id: automation.piscina_newdepuradora_se_detiene

…in case it helps someone in future searchs.

[123 (Taras)]

You should probably consider redesigning your automations.

Because to have one automation behave normally it first has to disable another automation is a helluva kludge; it points to a fundamental weakness in the overall design.

.