state_trigger triggering when it shouldn't?

[steverumsby]

I have a luminance sensor I want to use to control some lights - turn them on when it gets dark & off when it gets light. Here's my simple start to building this:

@state_trigger("float(sensor.luminance_sensor_illuminance) < 300", state_hold_false=0)
def lounge50():
    light.lounge_1.turn_on(brightness=127)
    light.lounge_2.turn_on(brightness=127)

This certainly works at the end of the day as light falls, the lights turn on. But I'm also noticing that the lights are on in the morning when I get up.

The history graph of the luminance sensor is this and clearly hasn't gone above 300 in order to allow the state_trigger to trigger again, which is what the state_hold_false=0 is supposed to do I thought:

Am I misunderstanding what state_hold_false=0 does, or is pyscript triggering this function when it shouldn't?

Thanks,
Steve.

[Wackoww]

You are correct about the state_hold_false.

Maybe it is in the compare float / int. You can try to compare to 300.0
Sometimes I also struggles with this and it didn't work as I aspected

[steverumsby]

Thanks. Good to know my understanding is correct.

I'm actually getting more anomalous behaviour from pyscript triggers, to the point where I'm not sure I trust it anymore and I'm starting to move automations back into homeassistant. At least, those that can be done natively. I've got one or two that are going to be difficult to move, but they seem to be OK for now thankfully. Shame, really. I much prefer writing automations in python rather than through the HA UI or in YAML.

[orbelico]

Just two hints, though I am not really sure if they are of any relevance to your case. I've seen a lot of erratic behavior, too, but at some point, things became stable. I could track down erratic behaviour to two main sources:

1. Editing and saving pyscript files a lot. Theoretically, old triggers should be cleaned up. Practically, I clearly have seen a lot of behavior that was only explainable, if several instances of the same trigger (possibly with different implementations / parametrizations) were running simultaneously. Only a HA restart would cleanly fix this.

2. I've made the experience that erratic behavior sometimes comes from non-valid intermediate sensor states, e.g. when a sensor temporarily loses its wireless connection to HA and the state becomes "unavailable". Carefully check your sensor history if that is the case, I had a lot of problems of that kind. In your example, if the state were "unavailable" for just one data point, the condition would become False, and again True after, which could explain the behavior.
   For this simple example, it might be fixable by using a value >0 (i.e. greater than the timespan in which the sensor is sometimes unavailable) with state_hold_false. For more complex cases, my learning was, if you want a really robust behavior with conditions that extend over a longer timespan (as the state_hold_false in your case does), you need to do some more elaborate programming of your own to catch such fringe cases inside the trigger function, before performing the actual action.