My - condition: template always seems to be false in the traces, but it’s true when I copy paste the same code in the Developer tools templating section. What gives?
alias: Start Roborock Cleaning if Away More Than 24h Ago
description: >-
Starts cleaning if person.george is not home and last clean was more than 24
hours ago
trigger:
- platform: state
entity_id: person.george
to: not_home
condition: []
action:
- wait_for_trigger:
- platform: state
entity_id:
- vacuum.unnamed_device
to: docked
from: unavailable
timeout: "00:30:00"
continue_on_timeout: false
- condition: template
value_template: >
{% set last_clean = states('sensor.roborock_vacuum_s6_last_clean_end') %}
{% set last_clean_time =
as_timestamp(strptime(last_clean,'%Y-%m-%dT%H:%M:%S+00:00')) %} {% set
current_time = as_timestamp(now())%} {{ (current_time - last_clean_time) >
86400 }} # 86400 seconds in 24 hours
- service: vacuum.start
data: {}
target:
entity_id: vacuum.unnamed_device
mode: restart
max_exceeded: silent
I’ve also tried value_template: >- (with a dash) which seems to show better syntax highlighting but still doesn’t work; it always resolves to false in the Traces.
Hmm ok - it would be cool if that wasn’t the case but either way, it should be noted in the docs, I think here (but maybe there’s a more relevant place): Template - Home Assistant. - Do you know where I could open a pull request for this?
The mistake you made was adding a YAML comment in Jinja code. Jinja doesn’t recognize it as a comment but as a literal string. Compare the appearance of the highlighted text below to the text shown above. It’s not recognized as a comment so it doesn’t appear as italicized gray text.
However I have my doubts your PR would be approved because Home Assistant’s documentation clearly states it doesn’t cover the basics of Jinja’s syntax because it’s already explained in Jinja’s own documentation.
If I use >- the syntax highlighting shows correctly it’s a comment, but the value_template still always returns false. Whether it’s a comment in YAML or Jinja, it should be ignored by the parser, no?
Either way it takes the block scalar content defined, looks for the Jinja content to evaluate it and return True or False (as booleans). I don’t see any benefit for it taking comments into account.
I can’t comment on why your text editor chooses to represent the string that way. The forum’s editor displays it as a literal string and so does the Automation Editor.
Look at the automation’s trace and you will see the result produced by that template.
I love the Traces feature, we didn’t have that when I started in 2020!
Here it is in the Forums syntax-highlighting, and you’re right here, it looks like a string:
alias: Start Roborock Cleaning if Away More Than 24h Ago
description: >-
Starts cleaning if person.george is not home and last clean was more than 24
hours ago
trigger:
- platform: state
entity_id: person.george
to: not_home
condition: []
action:
- wait_for_trigger:
- platform: state
entity_id:
- vacuum.unnamed_device
to: docked
from: unavailable
timeout: "00:30:00"
continue_on_timeout: false
- condition: template
value_template: >-
{% set last_clean = states('sensor.roborock_vacuum_s6_last_clean_end') %}
{% set last_clean_time =
as_timestamp(strptime(last_clean,'%Y-%m-%dT%H:%M:%S+00:00')) %} {% set
current_time = as_timestamp(now())%} {{ (current_time - last_clean_time) >
86400 }} # 86400 seconds in 24 hours
- service: vacuum.start
data: {}
target:
entity_id: vacuum.unnamed_device
mode: restart
max_exceeded: silent
What I am missing here is, you’re saying it’s represented as a string, but my understanding is that the condition looks for a boolean, so it logically can’t be a string as True !== “True”. Am I misunderstanding what you’re saying?
It seems like the Automation Editor is of two minds when it comes to displaying that string.
Anyway, this wouldn’t be the Automation Editor’s first glitch. Regardless of its shortcomings, the rule remains that you can’t mix the syntax of different languages.
I think I get what it does - it takes the whole block as a string and passes it to Jinja, where the comment fails as it’s, as you said, interpreted as a string there. Interesting. It should discard the YAML comment, which it could see, before passing the whole thing to Jinja for evaluation.
I’d have to look at the source code to be sure but maybe I could make a PR over the weekend
The YAML portion is processed first by the YAML processor. Then the Jinja portions are processed by the Jinja processor.
Everything to the right of the value_template key is its value and its value is a Jinja2 template. The YAML processor doesn’t inspect or interpret Jinja.
YAML and Jinja are open-source projects independent of Home Assistant.
Yeah exactly, and since # is a YAML comment, my first conclusion is that it should be discarded (just like the syntax highlighting shows with >-).
I’m thinking of it a little like so (using a different combo of languages for example, PHP and JS)
<?php
$jsVar = "alert('hello')"; # This comment doesn't matter - its actually invalid in JS;
?>
<script type="javascript">
<?php echo $jsVar; ?>
</script>
Are you saying that it is in fact intended in YAML that the comment is passed as part of the value? If not, I’d be happy to look at where I can help in the source of Home Assistant, otherwise, it would be fruitless
I don’t think you understood my explanation because you believe this behavior is controlled by Home Assistant.
You’re overlooking the fact that indentation plays a critical role in how YAML is interpreted. The YAML processor doesn’t interpret that so-called YAML comment as a YAML comment because it lacks proper indentation; it’s within the bounds of a Jinja template.
Review what I wrote above.
As mentioned previously, YAML and Jinja are separate from Home Assistant.
To be clear, what you just mentioned is different from what you had proposed earlier (YAML processor inspecting Jinja code for YAML comments and discarding them).
The “two minds” issue is a display glitch and probably due to whatever library they’re using to display the code. It’s worthy of being reported as a bug in the Frontend repo.
It could’ve been a miscommunication on my part - I never thought that YAML would read Jinja code, I just didn’t understand that once we define a block using > or >- YAML considers the whole thing as a value and thats that - I thought it would still see the YAML comment in that value. Its a bit like heredoc or nowdoc (<<<EOT) in PHP in that sense.
Funny, I’ve been writing Docker containers for a good 4-5 years now and I never really had to use the block syntax, so I never came across this before ! Live and learn
Will open a bug on the Frontend repo - thanks again!
