Boolean set not working

Configuration
1

I was creating a very test for something else and it seems that setting a boolean input to off as the first action is not working:

alias: TEST
description: “”
triggers:

  • trigger: state
    entity_id:
    • input_boolean.simple_test
      to:
    • “on”
      conditions:
      actions:
  • action: input_boolean.turn_off
    metadata: {}
    target:
    entity_id: input_boolean.simple_test
    data: {}
    mode: single
2

https://community.home-assistant.io/t/how-to-help-us-help-you-or-how-to-ask-a-good-question/114371#oneone-format-it-properly-16

3

I tested the following automation and it works properly. When the Input Boolean is turned on, the automation turns it off.

alias: Simple Test
description: ""
triggers:
  - trigger: state
    entity_id:
      - input_boolean.test
    to:
      - "on"
conditions: []
actions:
  - action: input_boolean.turn_off
    metadata: {}
    target:
      entity_id: input_boolean.test
    data: {}
mode: single

I believe what you are witnessing is a bug in the UI and not a problem with your automation.

If you display the Input Boolean’s onscreen switch, after sliding it to on you would expect it to instantly slide back to off but it doesn’t do that; it remains on.

However, if you exit the onscreen switch then re-display it, the switch is now in the off position. This seems like a possible bug in the UI because it requires exiting/re-displaying the Input Boolean in order for its true state to be displayed.

So it’s a problem with the UI, not the automation.

1 Like
4

I’ve ran into this before, though with MQTT switches and not input_booleans. But my observation is that switches in the UI are operated optimistically to allow the UI to appear responsive to user’s input. So the switch visually toggles regardless if the state of the switch in HA actually ends up changing.

Based on my observations (I have not looked at the code), the process appears to be:

  1. User displays the switch in the UI
  2. UI listens for state changes and will change the displayed position of the switch if a state change occurs
  3. User commands the switch to be toggled in the UI
  4. State changes are ignored for a fraction of a second while switch begins to move
  5. UI listens for state changes again. Switch position can now be in opposite position of HA’s known state, it doesn’t matter. It will remain this way until UI is refreshed or another state change is received.

Some switches in some integrations take multiple seconds to update state after the command is received, so the UI has to be set up to handle this. It makes sense to me that the design decision in the UI was to allow the switch to visually change state immediately and hope the real state ends up changing later. This way the UI appears responsive and users don’t click on a switch multiple times because it isn’t doing anything.

For this input boolean automation, the problem looks to be that the HA state reverts back to OFF so quickly that the UI never sees it ever being ON. And so the UI keeps the switch in the ON position waiting patiently, hoping that the backend state eventually changes to ON, just like it would for a slowly-updating switch. Inserting a delay of even 1 millisecond into the automation prior to the action is long enough for the UI to just start moving the switch a tiny amount and then it will see the state change and move the representation of the switch back to the OFF position. So, with a 1ms delay, the switch jitters just a tad and stays OFF. 100ms is a long enough delay for the switch to move all the way to the full ON position before going back to OFF.

In summary I guess this could be considered a bug but I’d be surprised if there’s any magic that could be implemented to make the UI respond in sub-1-millisecond. Instead, this seems like a natural limitation of the design decisions that were needed to be made to make the UI still appear responsive for slow-updating switches.

But this is all conjecture based on my observations. Take it for what it’s worth.