transferring my automations/script from the old to the new possibilities we’re offered since Ha 113.+, I was wondering how this sensor/lights automation should be written, to make it use these optimally. thinking of mode (now chosen restart since the binary_sensor will trigger quite often, and 'default would cause errors and parallel or queue might complicate things unnecessarily ?), cool down (maybe, instead of the condition template?), and maybe other functionality now available. This is what I now have:
- alias: Driveway buiten motion
id: Driveway buiten motion
trigger:
platform: state
entity_id: binary_sensor.driveway_buiten_sensor_motion #Hue motion sensor
to: 'on'
condition:
- condition: state
entity_id: binary_sensor.outside_daylight_sensor
state: 'off'
# prevent triggering within a certain time frame
- condition: template
value_template: >
{{(now() - trigger.from_state.last_changed).total_seconds() >
states('input_number.presence_timer')|int}}
action:
- service: script.driveway_outdoors_light_on
- service: script.notify_driveway_outdoors_light_on
# use same timing as Hue sensor in the app
- wait_template: >
{{is_state('binary_sensor.driveway_buiten_motion_sensor_timed','off')}}
- service: script.driveway_outdoors_light_off
- service: script.notify_driveway_outdoors_light_off
the individual scripts are simple and don’t contain timing aspects other than a transition, like this:
If there’s a way to improve this, I’d like to see how.
After the first trigger, if this is re-triggered faster than what the conditions wants then nothing happens (the re-trigger is ignored).
If the re-trigger meets the conditions requirements, but the first instance of the action is still running (i.e. the wait_template is still waiting) then the default mode: single will ignore the re-trigger. Yes, it will log a message but it’s a warning not an error. I don’t think changing the mode (to avoid the warning message) will produce the kind of behavior you want (both queue and parallel will execute the entire action more than once).
thanks! I was thinking the same. I would love to be able to prevent the warning you mention. restart might do that, but, wouldn’t that also forgo the timing condition? since restart will effectively stop the automation where it is at the time of the re-trigger?
Exactly. It’s not the behavior you want for this application.
I believe that, early in the development of mode, pnbruckner had included another option like single but it did not report a warning. I believe there was some recent discussion that it may return in the future. Phil would know more about this than I do.
So you wouldn’t advice me to use other options in the scripting engine now available given the 2 timing lines in the automation? Of which the wait_template probably would be the most delicate?
I mean, if the trigger happens during the first condition it will simply not pass, and don’t throw an error. It might do so when the automation is waiting. I really don’t want it to restart, and cancel the running automation. Nor should it queue or run parallel.
in fact, it should really finish the full automation, and ignore another trigger, if the automation is still underway. As Taras suggested, the ‘former’ single would have been the choice to make here?
Suppressing warnings would be suboptimal, (since it would be more of a ‘hack’)? Expecting these kind of situations by providing a mode catered for that couldn’t be brought back (from the alpha testing phase…?)
I don’t have time right now to wrap my head around this. Suffice it to say, use the mode that makes the most sense to what you’re trying to do. Whether or not it might issue warnings sometimes is a separate issue.
I disagree. The situation is, the single mode is designed to ignore trigger events while the script/automation is running. The question is whether or not you want to know about trigger events that occur while it’s running. Today you have no choice - it will warn when this happens. Whether that warning is suppressed via another mode or an option of the existing mode is irrelevant, as long as you can choose for a particular automation/script in single mode whether or not you are informed about trigger events that happen while it’s running, what difference does it make? Also single mode is not the only mode where warnings can be issued. The same can happen for queued & parallel. So a new option can apply to all of the modes consistently, whereas creating new modes would mean creating three new modes, which to me is suboptimal & a hack.
