performing a major checkup of the setup, I was wondering if any preference exists for either of these condition template formats for scripts and automations, or even template binary_sensors :
{{not is_state('input_select.activity','Naar bed')}}
{{states('input_select.activity') != 'Naar bed'}}
same applies for the positive version of these of course…
thinking system reliability, speed, complexity for the backend etc etc
thanks for having a look
I prefer the not is_state version. Aside from it looking neater, in other languages it is discouraged to use operators to compare strings, java example…
… So I would expect to use the same ‘best practice’ for jinja / python too (albeit that I have no idea whether the situation is the same for those languages, just a best guess).
It’s definitely NOT that here! 
Sorry, couldn’t resist …
Templating in Home Assistant is steeped in string comparisons. Even time is often a string comparison (comparing sensor.time to an input_datetime).
The first example, employing not, appears to be more efficient because it employs logical comparisons using true/false booleans.
However, let’s not overlook the fact that is_state performs an internal string comparison when it compares the input_select’s state (a string) to Naar bed. Then the not inverts the result.
The second example does externally what is_state does internally, namely compare two strings. It has no need to invert the result.
thats a very noteworthy post, thanks Marc. need to checkup on those JS scripts too then…
thanks! given the fact I have quite a few of these, hope that this might ease up the processor usage for yet another fraction.
haven’t yet compared it to the HA source, but would this also come closest to
condition: state
entity_id: input_select.activity
state: Naar bed
?
I try to use this everywhere I can (had these written as template before too, but then Phil suggested this would probably be more efficient.
the negation of these state conditions is still very clumsy in the yaml config, so I write them as templates mostly, especially when more state are to be evaluated as in:
{{states('input_select.activity') not in ['Slapen', 'Naar bed']}}
this doesn’t have an is_state variant in the first place (I think)
not sure if I am overcomplicating things too much now but the above could lead to a lot of re-writing, given the fact I have a lot
of these too:
script.{% if is_state('input_boolean.notify_announcement','on') %}announce_presence
{% elif is_state('input_boolean.notify_presence','on') %}notify_presence
{% else %}dummy
{% endif %}
which for consistency and efficiency would all have to be rewritten as:
script.{% if states('input_boolean.notify_announcement') == 'on' %}announce_presence
{% elif states('input_boolean.notify_presence') == 'on' %}notify_presence
{% else %}dummy
{% endif %}
…
You misunderstood what I wrote.
I believe it only has the appearance of being more efficient. It’s performing a string comparison then inverting the result. The second example performs a string comparison, period. Therefore it’s the second example that is marginally more efficient.
Of course, that’s just a guess because it really all depends on how the python interpreter converts the python source code into object code. Without any deep insight into that process, the simplest way to determine which is more efficient is to create a timing test that, for example, iterates through a few thousand string comparisons.
ha, but that isn’t too simple is it? unless that could be done with a loop that repeats itself, using the first template only, and then repeat it using the second only.
I suggested thousands of iterations because the time difference between just one iteration of each technique will be varnishing small. It’s likely to be so small as to make this a purely academic discussion.