How is the then keyword not required? And which one? The one with “if” or the one with “elif” or both? How are the conditions differentiated/separated from the actions otherwise? YAML is still YAML.
In my proposal, “if” and “elif” are actions that each contain a list of conditions and a list of actions. The “if”/“elif” contains the conditions, and the “then” contains the actions. For the “else”, there are no conditions, so the “else” just contains the actions.
Not needed for choose.
Sorry, you’re wrong. choose uses conditions / sequence pairs, just like if / then or elif / then. No difference (other than the words themselves.)
Your existing implementation of choose doesn’t need an explicit then key word. I like how then is inferred (and not explicitly stated) in the current implementation. That’s what I’ve been describing as being the difference with the example you posted using if-then-elif-etc.
The key word then is also inferred in python.
if x > 50:
#do something
else:
#do something else
as opposed to VB where the key word then is required (plus a terminating end if).
If count = 0 Then
message = "There are no items."
ElseIf count = 1 Then
message = "There is 1 item."
Else
message = $"There are {count} items."
End If
Correct. But it does need an explicit sequence keyword. Why is that any different?
- if:
<conditions>
then:
<actions>
- elif:
<conditions>
then:
<actions>
- else:
<actions>
is the same as:
- choose: <== extra line that if doesn't need
- conditions: <== equivalent to if
<conditions>
sequence: <== equivalent to then
<actions>
- conditions: <== equivalent to elif
<conditions>
sequence: <== equivalent to then
<actions>
default: <== equivalent to else
<actions>
except that the “if” version uses smaller words and one less line / level of indentation.
Hmm, kind of see what you’re trying to say there but I never considered the word sequence to be the literal equivalent of then. It’s what Home Assistant has adopted to indicate the beginning of a (literal) sequence of script actions. In fact, it sits at the top of a script where it certainly has never meant then.
But, if all we’re doing is counting key words, I think it may be a tie. Looking at your annotated example, conditions substitutes for both if and elif but the choose version also needs the choose key word itself (i.e. like select, switch, and given, the word is used just once). Six of one, half a dozen of the other.
I still prefer the current implementation over if-then-elif-else.
That looks great imo. It is easier to read/understant. (at least for my brain 
)
In that case (no pun intended), you may want to head over to the Architecture repo and read the discussion that started this initiative back in May. Spoiler alert: the topic’s title is:
However if-then-else was almost immediately dropped in favor of branch with condition. It continued to evolve and eventually because what you see today (choose).
That is an unfair assessment. It was never seriously discussed or really even considered. It certainly wasn’t proposed as an option. The discussion started as a possible extension to the condition action, and quickly migrated towards a branch, and later choose, type of construct.
The conversation started May 3rd with the topic title ‘Else clause for automations’ and the very next day balloob suggested branch which quickly established itself. Subsequent posts that introduced if-then-else never gained traction (I believe ThomasLoven brought it up again and so did you when you joined the discussion). The thread has several dozen posts, made by about a half-dozen people, and runs to July. Whatever time or audience the concept needed to take root was available.
So me saying ‘almost immediately dropped in favor of branch’ is hardly an unfair assessment. But I respect your right to disagree.
It wasn’t “immediately dropped”, because it was never considered. What part of that do you not understand?
If you actually read the entire topic you will see that the only time if type statements were mentioned were as a way to explain a point. It was never proposed as an alternative solution.
But you can go on believing whatever you like if it makes you happy to disagree for the sake of disagreeing.
Within five posts else was dead. So you’re not wrong it was never considered because everyone already took the hint else was dead (and implicitly its cousins if and then) because branch had already been anointed. 
Let’s see, everybody thought that
- condition: ...
else:
- condition failed
- condition passed
wasn’t a great idea, so naturally, because it had the word “else” in it, they also thought (without it ever being mentioned explicitly as an alternative idea) that if-elif-else was also a bad idea. Yeah, that’s some stretch of the imagination.
I didn’t say it was bad idea just not an idea that progressed beyond the first few posts.
All the software developers in that discussion are certainly familiar with the concept of branching. They had every opportunity to promote the use of the traditional if-then-else nomenclature. Yet else was short-lived and never successfully revived.
I don’t why that is; often there’s a fairly robust back-and-forth but there’s no evidence of it in the discussion. Certainly one would expect seasoned developers to be more vocal about the rapid dismissal of else (and relatives). After all, if-then-else is fairly ubiquitous. Perhaps it had been hashed out on Discord and what’s seen in GitHub is the result of some common understanding that branch was in and if-then was out.
You did introduce if late in the discussion yet it wasn’t universally welcomed (and certainly had the opportunity to revive its usage). For some reason, the majority of participants leaned towards the concept of a switch/select.
This feels like the most elegant solution to me:
sequence to condition
exit:
Example:
turn_on_playstation_if_home:
alias: Turn On Playstation if Someone is Home
sequence:
- condition: state
entity_id: person.donka
state: 'away'
sequence:
- service: script.notify_me
message: "Tried to start PS4, but you are away"
- exit: true
- service: script.turn_on_receiver
- condition: state
entity_id: input_boolean.quiet_mode
state: 'off'
sequence:
- service: script.mute_receiver
- service: script.turn_on_ps4
For whatever reason, moving condition closer to an if statement feels better than adding if/else/elif constructs.