state_trigger with state_check_now=True and state_hold_false=0

[dlashua]

I use state_check_now on a @state_trigger to mean, I recently changed something or I just restarted Home Assistant and I want this trigger to be evaluated right now and to execute the method if it's true.

And state_hold_false just keeps the method from triggering again when it doesn't really have anything to do.

However, as indicated in the docs, using these two together, means that if the trigger evaluates to true at startup, it will NOT execute the method. I think that it should.

In other words, state_check_now should ignore state_hold_false when evaluating at startup. I can't think of a situation where the current mode of operation is useful: a scenario where I want it evaluated RIGHT NOW, but not EXECUTED if it's True.

This is easily worked around in code, so it isn't a problem if it gets left the way it is. I just haven't found a use for it yet, but I've several times written extra code to make it behave the way I expect it to (i.e. I don't use state_hold_false and instead implement that same functionality in the method or with state_active).

[dlashua]

a real world example:

@state_trigger((
        "input_boolean.living_occupied == 'on'"
        " or input_boolean.kitchen_occupied == 'on'"
        " or input_boolean.dining_occupied == 'on'"
        " or binary_sensor.entry_occupied == 'on'"
        " or input_boolean.hallup_occupied == 'on'"
        " or input_boolean.halldown_occupied == 'on'"
), state_hold_false=0, state_check_now=True)
def turn_on_holiday():
    switch.holiday_stair_rail.turn_on()
    switch.holiday_mantle.turn_on()

I don't need this to turn on those things again and again just because the kitchen is now occupied when the living was already previously occupied. Hence state_hold_false=0 handles this.

But, if the living turned "on" when Home Assistant was restarting (or if I just added that condition to the state trigger and reloaded pyscript), this isn't detected (because it starts up as "on"). So those switches don't turn on until something else happens. Hence state_check_now=True, so it'll look at those things immediately without getting a state_changed event first.

But using them together, means it still doesn't turn on.

[craigbarratt]

Yes, I struggled with picking which one would override the other if they were both specified. I decided on the current approach to use state_check_now to override the default of state_hold_false not requiring a False value prior to the first trigger.

You make a good case for changing that behavior. But then there's no way to specify the case where you want a False before the first trigger. I agree your use case is more common.

Let me think about this some more. Hopefully we can figure out a clever and intuitive way to support either way.

[craigbarratt]

Ok, here's how I plan to revise startup behavior. Without state_check_now, the new startup behavior requires an initial False period: the trigger expression is evaluated at startup; if False then the state_hold_false period begins. If True, we wait until the next False.

With state_check_now set, it does the usual thing - if True at startup, the trigger occurs, and we wait for the next False.

This seems much better - both parameters operate independently.

The original startup default of the first True triggering without requiring a False period doesn't seem useful, so that will be dropped.

[dlashua]

I think that seems perfect. To recap, I think this covers all of the possible startup scenarios:

At startup, with defaults, a True expression WILL NOT trigger. Any subsequent state change that results in a True expression WILL trigger.

At startup, with defaults, a False expression WILL NOT trigger. Any subsequent state change that results in a True expression WILL trigger

At startup, with state_check_now=True, a True expression WILL trigger. Any subsequent state change that results in a True expression WILL also trigger.

At startup, with state_check_now=True, a False expression WILL NOT trigger. Any subsequent state change that results in a True expression WILL also trigger.

At startup, with state_hold_false=0, a True expression WILL NOT trigger. Any subsequent state change that results in a True expression also WILL NOT trigger. Once the expression is False, the next True WILL trigger. Then another False is required. Then the next true WILL trigger again. And so on.

At startup, with state_hold_false=0, a False expression WILL NOT trigger. Any subsequent state change that results in a True expression WILL trigger. Once the expression is False, the next True WILL trigger. Then another False is required. Then the next true WILL trigger again. And so on.

At startup, with state_hold_false=0 AND state_check_now=True, a True expression WILL trigger. Any subsequent change that results in a True expression WILL NOT trigger. Once the expression is False, the next True WILL trigger. Then another False is required. Then the next true WILL trigger again. And so on.

At startup, with state_hold_false=0 AND state_check_now=True, a False expression WILL NOT trigger. Any subsequent change that results in a True expression WILL trigger. Once the expression is False, the next True WILL trigger. Then another False is required. Then the next true WILL trigger again. And so on.