The Jinja2 parser under “Developer Tools” → “Template” is already a handy tool for developing templated automations. However it today lacks the capability of really simulating a “live automation” scenario, when it comes to filling dynamic data variables (e.g. the “trigger” variable, when used in an automation). With a separate data text box like it is realized under https://j2live.ttl255.com/ an option would be provided for “statically” filling e.g. a trigger variable. The “static” input could be even copied from traces of already run automations. I have begun using the parser under https://j2live.ttl255.com/, but it would give a real additional benefit, when having such a parser integrated in the “Developer Tools” Home Assistant interface, as we would then have additional access to live Home Assistant sensor data, which we obviously don’t have, when using the parser under https://j2live.ttl255.com/
I don’t believe that I understand the ask here.
Isn’t that box just a place to set variables? You can do that above the template you are testing.
Well, I would say: Yes and no. “Yes”, because you are right, it’s just about setting variables. But setting variables can be quite cumbersome. I have attached a screenshot, which hopefully shows the benefit/use case. Look at the “Jinja2 Data” box there. I have just copied the yaml from the live trace of the automation! This is a very handy way of setting variables with no risk to get the variable setting wrong in the code, because I just copied it over from the live trace. However, what in an external parser like this one still does not work, is the usage of sensor data, if e.g. the automation accesses a sensor value. Hence my idea to have a similar parser functionality built into Home Assistant developer tools.
I believe the advantage of the online tool is that it has a separate window for accepting a variable defined in YAML. That makes it convenient to copy-paste trigger
variables from an automation’s trace.
Currently, you first need to convert from YAML to JSON either by hand or using an online tool like YAML to JSON Converter Online. The JSON can then be assigned to a Jinja variable for use in the Template Editor. The FR wants a similar capability to be included in the Template Editor.
EDIT
It would also make it easier to test a template that uses the value of a response_variable which is typically displayed as a dictionary in YAML format.
Here’s an example from the documentation for the value of a response_variable produced by weather.get_forecasts
weather.tomorrow_io_home_nowcast:
forecast:
- datetime: "2023-12-07T13:00:00+00:00"
condition: cloudy
precipitation_probability: 0
wind_bearing: 241.19
temperature: 0.1
dew_point: -1.9
wind_speed: 16.88
precipitation: 0
humidity: 86
- datetime: "2023-12-07T14:00:00+00:00"
condition: cloudy
precipitation_probability: 0
wind_bearing: 232.41
temperature: 0.8
dew_point: -2.8
wind_speed: 17.82
precipitation: 0
humidity: 77
- datetime: "2023-12-07T15:00:00+00:00"
condition: cloudy
precipitation_probability: 0
wind_bearing: 236.09
temperature: 1.1
dew_point: -2.6
wind_speed: 17.89
precipitation: 0
humidity: 77
Look also at the sentence in the “Jinja2 Template” box in the above screenshot, which says: “Der Batterieladezustand des Nuki-Schlosses beträgt 54%.” Here the limitation of an external parser comes into play: I had to replace the “{{states(‘sensor.smartlock’)}}” with a statical value of “54” because obviously in an external parser I do not have access to HA sensor data.
Absolutely. You nailed it!
Ah, gotcha. Thanks to both for the explanation.
Maybe a button to turn on ‘advanced’ and you get this, so the less advanced templeteers don’t go into shock when they see this.