I am trying to recopy the brightness level of a light group to an input number. Indeed, I can use the input number to change the brightness level, but when I use the light bulb app (Yeelight) to change the settings, this input number is not synchronised.
I have created a sensor which tracks the light group brigthness:
The sensor’s value changes slowly, taking a few seconds to go from value A to value B (with multiple intermediate values). Without a delay, the automation which copies the sensor value back to the input number is unstable. Therefore, I have this automation, but the delay is skipped:
- alias: copy light brightness to dimmer input number
hide_entity: true
initial_state: true
trigger:
platform: state
entity_id: sensor.luminosite_salon_sensor
action:
- delay: '00:00:30'
- service: input_number.set_value
data_template:
entity_id: input_number.luminosite_salon
value: "{{ trigger.to_state.state | int }}"
You’ve been bitten by this strange automation behavior. If an automation is triggered, and it reaches a delay step, and while it’s waiting for that delay to finish, it is triggered again, it doesn’t start the actions over from the beginning, but rather immediately finishes the delay and continues on to the next step. Not sure why it works that way, but it does.
What I suggest is moving the steps to a script, and then call the script from the automation, but only if the script is not already running. See this post where I explain this in a bit more detail.
It’s now working. Just had to replace the copied value from value: "{{ trigger.to_state.state | int }}"
to value: "{{ states('sensor.luminosite_chambre_sensor') | int }}"
Has this “bug” / weird automation behavior been reported or is there a way to do so ?
I guess that makes sense, because the second trigger doesn’t start the actions over, it just effectively cancels the delay. So the trigger isn’t changed and still has the value from the first time the sensor changed. So getting the current value directly from the sensor in this case does make sense.
And being “unstable” also makes sense. Because effectively the automation was only recording the values from the odd numbered triggers. So, let’s say the sensor updated three times. That would work because the first change would grab the right value, but the second would cause the problem, but then, when the third change came, the automation from the first two would be finished and therefore be able to start again. But if there were four changes, then you’d hit the problem again.
As far as reporting, I have no idea if anyone has created an Issue for this. You can if you like.