My point was that with “parse_result” to false, it explicitly disable type inferring, and revert to returning string only, at least theoritically.
I will try to debug what’s happening, here.
My point was that with “parse_result” to false, it explicitly disable type inferring, and revert to returning string only, at least theoritically.
I will try to debug what’s happening, here.
I carried out a simple experiment and escaped the meaning of the double-quotes. The following service call generates a notification without complaining that the result isn’t a string. In other words, it didn’t try to interpret the result as dict
.
Here’s the resulting notification:
Therefore, try this version:
sequence:
- service: notify.file1
data:
message: >
{% set temperature = states('input_number.temperature') %}
{% set humidity = states('input_number.humidity') %}
{\"temperature\": {{temperature}}, \"humidity\": {{humidity}}}
mode: single
Correction. Added missing %}
Oh the irony!
Tricky…
I also think it’s tricky.
Did you try the example I suggested above? I confirmed it works (i.e. doesn’t generate an error).
I tried but my output is not the same as yours. I get:
{ \"temperature\": 21.5, \"humidity\": 35.0 }
Well darn, I guess my use of notify.persistent_notification
to test it was a bad choice. I can confirm that if I test it with notify.file1
I get the same result you did:
{ \"temperature\": 21.0, \"humidity\": 13.6 }
No error message but the escape character is passed on literally in the output.
Yes that’s it.
In any case, this is only a way of learning what can be done, I’m not using in my configuration.
I made some progress. When I try this:
This is what gets written to file1.txt
{'temperature': 21.0, 'humidity': 13.6}
See what this does for you:
sequence:
- service: notify.file1
data:
message: >
{% set t = states('input_number.temperature') | float %}
{% set h = states('input_number.humidity') | float %}
{{ '{{{ "temperature": %f, "humidity": %f }}}' | format(t, h) }}
mode: single
The hurdle might be that some JSON interpreters insist upon the use of double, not single, quotes. So it will depend on whatever is consuming this data.
Yes, now the output is what you said.
What is the meaning of the three curly braces around the message?
Escapes the meaning of the brace for more than one level of processing.
If you use only two braces, the Jinja2 interpreter thinks they belong to it but will then complain because it finds two nested sets of double braces (which is invalid).
Glad to hear it.
Please consider marking my post above with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has been resolved. It will also place a link under your first post that leads to the solution. All of this helps users find answers to similar questions. For more information, refer to guideline 21 in the FAQ.
Of course. Done.
Thank you for your explanation.
Clever
I don’t understand why
{{ { "temperature": 23.780000, "humidity": 78.000000 } }}
renders as
{'temperature': 23.78, 'humidity': 78.0}
though. Why the double to single quote, and why the number formating?
And yeah, unfortunately, JSON mandates double-quotes for string, albeit some libraries might be lenient.
Because
renders a python dictionary, not JSON.
That’s just what python does
python doesn’t care if a string starts with a ’ or ", it uses them interchangeably wherever it see’s fit.