State change trigger for a certain duration in an automation

Configuration
1

I should know the answer to this by now, but wanted to check.
What exactly makes a trigger like this fire:

platform: state
entity_id:
  - sensor.tuya_mmwave_office_illuminance
id: illuminance
for:
  hours: 0
  minutes: 0
  seconds: 30

In the above example, the sensor is a mains powered device that’s very chatty, sending illuminance updates every 2-3 seconds and the automation doesnt trigger (as often as I would expect)

My basic tests suggest that if the sensor keeps updating the illuminance values, its effectively resetting the 30 seconds.

With a binary sensor, its more straightforward… its either on or off for the duration. But for something like illuminance or active power, I’m not clear.

Is this how its supposed to work ?

2

The value of the state must remain the same for 30 seconds.

True, unless the updated value is the same as the previous value.

Yes. The state trigger is very literal. If you want something a little more binary for numeric states use a Numeric state trigger to set thresholds.

3

Thanks @Didgeridrew,

Thats what I suspected, but I just wanted to double check.
I’m trying to find a way to make the automation fire less often, which caused me to look at the above.

4

Also, keep in mind that a state trigger without at least one assigned to/from/not_to/not_from value will fire on all updates not only of the state of the entity, but also updates to any of its attributes. In some integrations sensors have tons of attributes which can update asynchronously from the state, so an open-ended State trigger with a for duration will almost never fire.

5

Thanks.
That final part I was aware of. In this case, the entity only has a single attribute so its fine.

I’ve tended to follow a pattern like so:-

Trigger looks something like this:

platform: state
entity_id:
  - sensor.tuya_mmwave_office_illuminance
id: illuminance

(no for duration)
And follow up with a condition like this:

condition: numeric_state
entity_id: sensor.tuya_mmwave_office_illuminance
below: input_number.office_illuminance_threshold

This way I dont have to rely on the trigger crossing a threshold to fire (which is often handy).

But this does mean with chatty devices the automation triggers alot, but the condition then aborts it.