Obviously this trigger does not make a lot of sense logically, but I simplified it as much as possible while still reproducing the issue. I’m ending up with the following error:
[…] invalid template (TemplateSyntaxError: expected name or number) for dictionary value @ data[‘value_template’]. Got None
Note that if I change the yaml like follows, I do not end up with the error:
I’d beg to differ. I’m sure there are plenty of people more familiar with YAML and/or Jinja that could have seen that the excerpt shown appears to be correct and that the problem is likely to lie outside of the excerpt, which would have pointed me in the right direction (quite literally).
I’m sure it would have. It would also been very helpful if the Syntax Checker or error in the logs would flag such a “simple YAML error”.
Frankly, I’m not sure what I have done wrong to warrant such a snappy response. I don’t think my choice of editor (or lack thereof?) is what should warrant this kind of response. I reached out to this community nicely looking for some help. I didn’t get a response, which is fine. I spent another day this weekend and was able to figure it out without further help. I updated the thread to a) conclude the question and b) maybe help someone else who stumbles over this thread in the future. I’m not sure how I rubbed you wrong.
It passes Configuration > Server Controls > Check Configuration and, after executing Reload Automations, there are no errors in the Log.
I assume the error message you reported was visible in the Log? At what point did it appear during your testing?
[…] invalid template (TemplateSyntaxError: expected name or number) for dictionary value @ data[‘value_template’]. Got None
On a separate note, by indenting the line to that location, it becomes part of the template and is no longer treated as a YAML comment. You can see that in this screenshot from VS Code where the text # comment goes here is displayed in green as opposed to gray.
Compare that to when the text is vertically aligned with trigger. Now it’s understood to be a YAML comment.
Technically speaking, it doesn’t appear to be a true YAML error but merely an impactful typo that transformed the text’s meaning from a YAML comment to plain-text within a Jinja2 template.
Nevertheless, it would be interesting to know at which point the error message was produced (because my simple automation above failed to generate it).
Not really because using the exact code you posted didn’t fail as you described. Unless it can be replicated, it remains a mystery unique to your system.
I think I have isolated the problem now. But then again, I thought that several times over, so who knows.
Let me answer your follow-up questions first though:
Yes, in the logs. It appeared upon reload.
I got mislead several times on what the underlying issue appears to be. I appeared to me that adding or removing a specific line would make the error occur or not. I concluded that the line I was adding or removing was causing the error, which turned out to be incorrect. It’s still not entirely clear to me how the YAML, the Jinja and the comments interacted with each other in detail to cause this or not, but at this point that a (presumable) syntax error in my Jinja lead to the issue.
Note that there is a dot behind the 0 in that comment. That was a mistake in my Jinja template. The number was part of a more complex, larger Jinja template that I suspected to have an error, but due to lack of detailed information in the Home Assistant error logs, intended to “bisect” to the broken part. That’s why I added the comment markers to remove the presumably broken code. Turns out that even after “commenting out” all of the Jinja, I still ended up with the error. The Jinja clearly couldn’t be at fault then, right?
Now I know that these comments were incorrectly placed and presumably the Jinja template still got executed or at least parsed and presumably that syntax error still tripped the template engine and presumably would continue to cause no output for value_template.
At the time, I did not consider the possibility that my comments where somehow placed incorrectly or otherwise ineffective. Since “removing” all the complex Jinja continued to cause the issue I started looking at the notation I used and noticed that replacing the line-folding operator > with an inlined string template fixed the issue. The following will work:
In retrospect it’s easy to conclude that that indicates that the following code was harboring the problem, but at the time I thought maybe I’m doing something else wrong in my line-folding notation or just have some other clowny issue that, due to having very little YAML / Jinja experience, I fail to recognize as such – which turns out wasn’t that far off.
I thought I would be doing a useful and helpful thing by trying to isolate the issue as much as possible to the parts that seemed relevant. Obviously I ended up removing critical parts in the code I shared.
All in all the takeaways for me:
Provide the full code, especially if you are unfamiliar with the languages being used.
Actually create a minimal repro case in a separate blueprint/automation instead of trying to remove stuff from the full project/automation/blueprint.
Stay aware of where your YAML ends and your Jinja starts and make sure you’re not accidentally bleeding one into the other.
The one thing that could have really helped here however is more debugging information, especially insight into the Jinja output and result. I assume that the Jinja failed to parse / execute with the {{ 0. }} construct in the “comments”. But Home Assistant doesn’t tell you that. It only says that it got a None value in the YAML where it expected something else. If we would also get Jinja errors / outputs reported in the logs, then I would have probably been able to understand and fix this much quicker and without help.
I’ve also been noticing this when working with the recently added script/automation trace debugger. It would be really useful if you could inspect the end-state or even intermediate state of Jinja variables. It would make debugging of larger templates so much easier.
Or maybe at least a Jinja function to log into HA logs to aid with debugging.
Earlier you stated the following “will cause the syntax error” (and marked the post as the Solution and stated the mystery was solved):
value_template: >
{{false}}
# this is a comment
However, when tested, it did not produce an error message (for the reasons I explained above). Now you have revealed that this produces an error message:
value_template: >
{{ false }}
# {{ 0. }}
I can confirm that it logs the following error message after executing Configuration > Server Controls > Check Configuration:
Logger: homeassistant.config
Source: config.py:443
First occurred: 18:51:28 (1 occurrences)
Last logged: 18:51:28
Invalid config for [automation]: invalid template (TemplateSyntaxError: expected name or number) for dictionary value @ data[‘value_template’]. Got None. (See ?, line ?).
The template must evaluate to something meaningful but {{ 0. }} doesn’t produce either a “name or number” so it was flagged as an invalid template.
Like I said earlier, the issue here is that the second line’s indenting made it part of the template (meaning it became part of the template within the value_template option). That’s evident in the screenshots I posted above where the text is displayed in green (as opposed to gray and italicized when handled as a YAML comment). Even the forum’s editor shows the difference:
That’s why I said the first post was difficult for others to diagnose. The natural assumption is that you have provided a complete example and would not have withheld anything if there was more to show. It may have taken awhile for someone to conclude you left something out (i.e. you always had more information available to you than anyone else).
Your second post revealed there was in fact more to the template than originally shown. However, the example you provided, allegedly causing the syntax error, failed to produce the claimed error.
Why? Because yet again there was more to the story than had been initially revealed. The failure was caused by an invalid template, namely this {{ 0. }} You thought the leading hashtag would make the entire line a YAML comment but didn’t notice that its indentation transformed it into a legitimate part of the value_template.
I don’t know what editor you are using but, as shown in the screenshots above, VS Code makes it clear when the text is a comment and when it’s not.
It didn’t “only” say that. The error message is posted above and includes this important bit: TemplateSyntaxError: expected name or number
It’s saying the template contains a syntax error because it fails to generate either a name or number (what the template did produce is a null object which is, in Jinja2, called None). That’s what was perplexing to all who understood the error message’s meaning because your first post contains a valid template:
value_template: >
{{ false }}
and so does your second post:
value_template: >
{{ false }}
# this is a comment
The two aren’t useful templates but they don’t contain syntax errors and that’s why the error message was puzzling even for knowledgeable users. It’s only when you revealed the third example, containing an obviously invalid Jinja2 template, that justified the error message’s complaint.
