Prevent "double Toggle" Input Selector

Configuration
1

I have an input selector that changes the color of my pool light via MQTT message to my Raspberry Pi Pool Controller. Because the controller can also get inputs from other sources (Alexa), I set the default value via a MQTT status message.
Everything works great if I use HA, but when I use Alexa, the status message that resets the dropdown to a new value, triggers a new command, so the turn is called twice.
Is there a way to change my code so the status change of the selected value doesn’t trigger a new command?

Sorry about the formatting. Is there a way to enter code?

configuration.yaml:

input_select:
pool_light_color:
name: Pool Light Color
options:
- off
- cycle
- party
- romance
- caribbean
- american
- sunset
- royal
- blue
- green
- red
- white
- magenta
- hold
- recall
initial: off
icon: mdi:pool

automations.yaml:

  • alias: ‘Set Pool Light Color’
    trigger:
    platform: state
    entity_id: input_select.pool_light_color
    action:
    service: mqtt.publish
    data:
    topic: “pool/pool_light”
    payload_template: “{{ states(‘input_select.pool_light_color’) }}”

  • alias: ‘Get Pool Light Color’
    trigger:
    platform: mqtt
    topic: “pool/pool_light/status”
    #payload: “Color”
    action:
    service: input_select.select_option
    data_template:
    entity_id: input_select.pool_light_color
    option: “{{ trigger.payload }}”

2

Yes. At the very top of the page there are instructions.

Yes, I believe so. In your second automation, try adding a step before changing the input_select to temporarily turn off the other automation. Also add a step after changing the input_select to turn the other automation back on.

  action:
    - service: automation.turn_off
      entity_id: automation.set_pool_light_color
    - service: input_select.select_option
      data_template:
        entity_id: input_select.pool_light_color
        option: "{{ trigger.payload }}"
    - service: automation.turn_on
      entity_id: automation.set_pool_light_color
3

I found the error. I had my client subscribing to
pool/#
That of course meant that it would receive the status messages it sent itself.
The pool light function was called at the end of a “if then” that handles a lot of different functions, so every topic that wasn’t addressed earlier would be handled like a request to turn on the pool light.
After I changed that it works as advertised.
I guess there is some sense to the way Sonoff has there topic structure with the command or status as the top pier.

4

You were indeed correct. I had to change my yaml to your suggestions as well to make it work correctly.

Thank you!!!