If state of script.kodi_on has not turned to ‘on’ by the time wait_template evaluates, and is thus still ‘off’ it doesn’t have to wait for a state that is already ‘off’ to become 'off’at that time.
If you really want to debug you could add an event with Jinja template to log the value of "{{ is_state('script.kodi_on', 'off') }}" between the script.turn_on and wait_template. It should log a true value then.
Not in the recent post of it. I guess maybe that was a copy & paste error.
Regarding your second point, I guess I’m not really following completely. Let’s put it this way. The state of the script will change to on sometime after it starts a delay step. How much time elapses between the two, and what else can execute between them, is undefined. It’s very possible for a script to hit a delay step, which causes it to suspend, and then some other script runs and hits a wait_template that checks the state of the first script before the first script’s state changes in the state machine (which is what the wait_template checks.)
Ok, let’ use names.
I’m saying that if look at youtube_playlist_play script and first run a script by
- service: script.turn_on
entity_id: script.kodi_on
and then have
- delay: 00:00:01
- wait_template: "{{ is_state('script.kodi_on', 'off') }}"
timeout: '00:01:00'
That means that script.kodi_on has roughly a second before wait_template is reached.
If wait_template proceeds immediately (i.e not by timeout of 1 min) without waiting for script.kodi_on as the TS says, that means that either wait_template does not work correctly (a bit unlikely) or is_state('script.kodi_on', 'off') returns True.
is_state('script.kodi_on', 'off') returns True if script.kodi_on haven’t started yet, haven’t reached - delay: 00:00:03 or it’s already finished.
But we turned it on a second ago so I presume it should reach on state by then - it’s easy to check by increasing delay in youtube_playlist_play and I had an impression that didn’t change anything.
script.kodi_on couldn’t finis by then as it has delays of at least 18s (unless it stops by the very first condition, i.e the remote is already controlled Kodi - don’t know what that means to us).
We have a contradiction, which means either TS does not tell us how it really is or one of the premises (for example, about a script’s state is only changed (to on) once it executes a delay step or wait_template) is incorrect. Or I made a mistake 
I’m not following you either, apart from that it is unclear/unpredictable when -exactly- a scripts state is set to state ‘on’, I suggest you start testing and debugging yourself instead of reasoning by presumptions. Can’t make it much clearer than I have. I’m logging off from this discussion. Thanks for the input to my question!
Yes, there’s all sorts of possibilities. The problem is there are no guarantees, which is why code like this is at best unreliable and should be avoided (at least until things get better.)
For future reference, it’s possible to get more insight into what exactly is happening and in what order by enabling debug for homeassistant.core. With that setting all state changes are logged and therefore can be seen when they happen relative to other things (like executing steps in the scripts.) And if the default logging level is info, then you can see when steps execute, whether or not conditions in the sequence evaluate to true, etc.
agree. however, if you set log level to info it’s a lot of info so I never actually benefitted from it, just couldn’t find what I was looking for - room for improvement I think
grep is your friend!
And you don’t have to set info for everything. E.g.,:
logger:
default: error
logs:
homeassistant.core: debug
homeassistant.components.automation: debug
homeassistant.components.script: debug
That’s still a lot, but if you want to really know what’s going on…
looks like that
Since v 0.113 the python state setter is no longer required thanks to pnbruckners work on the Hass core