States returns string not a state object, so you’d be overloading the str classes __int__ method, which is not straight forward and can cause other issues. Where this is all just built into jinja without needing to change everything.
Some really good arguments here (I’m cheering from the side lines)
I have a question for @roger2 .
How would you define your python segment ?
What is it to be passed to the sandbox ?
For a template the curly brackets sort of give you a clue, not so in your examples they just start
You might say that the *_template bit is the first indicator, but it’s not.
Messages for example don’t (and never have) cared.
Also Frenck has just submitted a PR to dispense with the _template bit (whilst making it backward compatible). A lot of the people involved in this thread up voted that PR.
In terms of passing data in/out, maybe the template defines the body of a function along with a return statement:
value_template: |
for state in states.sensor:
if 'blah' in state.name:
return state
return ''
or
value_template: |
return states('mysensor.val') + ' is too high'
The Mako folks probably already have an approach too.
I’m curious about that PR – link?
How would that separate from a non-templated form? All the | does is say “multi line”. It still wouldn’t know it’s a template. What happens if you want to add the word return to a field and it just be a string?
Have you considered that complex templates are probably an edge case and not the majority of templates?
Perhaps, but why not have something that scales to more complicated templates in a reasonable way (perhaps with a slight sacrifice to simpler one-liners)?
I’d say both of your examples are simpler/cleaner in pure Python:
trigger.to_entity.attributes.friendly_name + " is home!"
if is_state('person.a', 'home'):
# do stuff for home
else:
# do stuff for not home
With the added benefit that Python is the most popular programming language in the world while Jinja is fairly esoteric.
I assumed the _template part conveyed that, but I see that’s not the case.
Okay wrap it in <% and %> like Mako does.
So now that takes simple cases from this:
{{ states('x.y') }}
to this
<% return states('x.y') %>
or in the last example you gave:
<% return trigger.to_entity.attributes.friendly_name + " is home!" %>
opposed to this
{{ trigger.to_entity.attributes.friendly_name }} is home!
So, it seems the trend for the 99% use case just got harder to read and more verbose, where the ‘harder to do’ stuff stayed about the same.
For the record, my code looks like this, when I copy pasted it into the other topic, the forum software seriously screwed with the layout 
Seven characters is a small sacrifice compared to the syntactical benefits for anything that’s more substantial than a one liner.
(Of course can also just make the return statement optional for a one liner.)
Sorry I didn’t mean to critique your code specifically, I just find most non-trivial Jinja templates unnecessarily hard to grok!
What you found isn’t technically fair because the syntax you see is littered with raw characters added by the yaml parser.
One other key consideration here I forgot about in my first post:
This is a key point, rendering a template cannot have side effects. If you changed from Jinja to Python how would you enforce this? Python’s power works against it here, the fact that it can do so much would make it tough to ensure there cannot be side effects caused by rendering a template. By using a templating engine like Jinja this can be enforced since the utilities exposed ensure it is literally incapable of creating side effects.
I’m not familiar enough with the internals of Python to know how this could be done. I know there is a way to create a sandbox since the HA team has leveraged that capability in the python_script integration. But can that sandbox actually be tight enough to guarantee no side effects? And how much work would it take to do that?
Sorry, I have no idea what you mean by " when I copy pasted it into the other topic".
Did I miss something?
I think it’s a miss understanding. The forum didn’t screw up his format, he copied it from the UI, which screwed up the formatting.
2 Likes
I wasn’t aware you couldn’t search the forum.
But I do see that you have read a full 6 hrs
I would be happy if I could use the entity ‘customize’ feature in the UI to add a property that the influxdb component could act upon. Or likewise in the YAML confirmation for an MQTT sensor, for example.
I believe this sort of thing is (or used to be) supported to control what entities were exposed to Alexa.
So add syntax to tell HASS that the thing is code. YAML is extensible. You can easily mark a multi-line thing so that it ends up as a specific object.
Thus instead of having a separate value_template which may or may not override value, and/or adding a value_python which may or may not override one or both of the others, you might choose to mark your value so that it’s interpreted as a template. Adding yet another markup to tell HASS that it’s Python code then becomes trivial.
For the record, I really like Jinja, but there are plenty places where you need real code instead of a template. Sure, go through AppDaemon or pyscript, add another quarter second to your already-too-high latency … your users will love you. NOT.
I’ve already stated why I don’t think its a good idea. Further argument isn’t going to sway me. The juice isn’t worth the squeeze.
Have you used AppDaemon or pyscript? I’ve never experienced any additional latency using AppDaemon (if there is any, it’s imperceptible).
1 Like
I don’r know what you are taling about, I never noticed any delay or latency issues with AppDaemon. This sounds like misconfiguration or bad code to me.