custom templates ARE yaml.
No, they are Jinja. The file does not accept YAML. It even makes this clear with the filename being xxx.jinja.
Jinja is the templating language. Yaml is a formatting language. They are not the same. Yaml accepts strings. Home assistant abuses this by allowing the JINJA to be added in Yaml as a string.
Does it make a huge difference?
The main thing that macros are managed - like yaml - not via UI.
What is a reason of disagreement?
Reloading macros - from the user’s PoV - same as reloading yaml.
Just rename “YAML reloading” view to “YAML & jinja reloading” (or whatever).
Because the page is listed as YAML… it’s not rocket science here. Not to mention, that page is auto generated based on the integrations that add a reload service. Which is not done by templates because there is no “Jinja” integration. Jinja is built into home assistant, it’s one of the few things that’s not an integration and built directly into core.
1 Like
I hope that technically you are 100% right.
But this is about usability.
It is more convenient for users to “reload macros”, then reload whatever he wants - from ONE page.
1 Like
Macros… am I doing something wrong or is there a bug?
I don’t seem to be able to get one to return a list.
{% macro return_list() %}
{% set item1 = 'foo' %}
{% set item2 = 'bar' %}
{{ [item1, item2] }}
{% endmacro %}
My money is on user error (i.e. me) but I can’t see where…
Yes sure, it’s a #feature-requests and the backbone does not exist to add it and it would need to be designed both in the frontend and backend. So please, make a #feature-requests but it’s not a simple “Oh just add it” kind of thing like you’re making it out to be.
1 Like
Macro’s return strings. You have to use from_json / to_json to convert to complex types like lists and dictionaries. boolean, floats, ints, just need to use the appropriate | filter
{% macro return_list() %}
{% set item1 = 'foo' %}
{% set item2 = 'bar' %}
{{ [item1, item2] | to_json }}
{% endmacro %}
{% from 'test_macros.jinja' import return_list }}
{% set mylist = return_list() | from_json %}
{{ mylist[0] }}
4 Likes
Let devs decide, no problem at all.
Once again, I am interested in usability only here.
Registered in Discussions.
Everyone is welcome to participate:
3 Likes
given the fact these new macro’s are (at least part of our set of) templates (they’re even saved in custom _templates), it would indeed be very logical (and expected tbh) to have them reload using the quickbar key C- templates. And yes, also via the Yaml button. During 2023.4 beta, several people already mentioned that.
whether these templates are Jinja, or written in yaml, or not is not really relevant, and should ideally be a black box for the user really.
The fact the button has a Label YAML on it should be no reason to not think about adding the custom_templates to the templates…
moreover, Quickbar C also offers:
the latter 2 are also services. not Yaml. Adding the new reload custom_templates seems not to impossible because of that…
4 Likes
I might chime in here, I just noticed my integration Switch Manager and Pyscript is also under the yaml reload section (I didn’t even realise till just now). The fact that my integration isn’t yaml (apart from blueprints but users config is different) and Pyscript is python, I think the naming might need a change considering the logic is looking for a reload service which might have nothing to do with yaml. Just a simple title like Configuration Reload would suffice.
1 Like
Didn’t mean to cause an argument, just though it made sense to reload it in the same place we reload templates as we are using as part of templates. No worries I’ll just use the service call…
If you’re interested in the code, it’s related to loading platforms which are yaml integrations for the most part. Seen here and below. The hurdles are that
- There is no custom_template domain, one would need to be decided if
homeassistantcannot be used. - The service is already in the home assistant domain, i’m not sure if you can register more than 1 reload service with a domain. I would assume you can but I’m not 100% familiar with how HA tells the frontend to add the reload service to the frontend.
- There is no platform or data to reload and the main conf_util class that’s called would do nothing because the macro reloading functionality is built outside of that entire object.
Something new would have to be designed, and that new thing would most likely need to be made (or approved by) by the core team.
Not impossible, but a ton of hurdles that make it unlikely.
No arguing here, just explaining why it wasn’t done initially and why it’s a Feature Requests.
EDIT: There is an All Yaml Configuration button, perhaps the system already exists to do this.
1 Like
OK fair enough, I’ve added a shortcut button to call the service, won’t need it that often anyway
Thank you for this. Did some selective deleting and re-adding of custom frontend modules and discovered it was lovelace-paper-buttons-row which was causing the issue for me.
Made sure I had the latest version (2.1.3), but the double scroll bars were still present.
Will open an issue.
1 Like
Yes I gave that a try, but it’s not the every day command you’d like to use apparently.
It took a very long time to complete and causes many integration warnings in the log .
It doesn’t only load ‘new’, it really reloads the whole config. And maybe not too elegant at that.
Hardly the way forward for the custom templates reload currently. If it works at all, because my macros couldn’t be successfully loaded afterwards…
2 Likes
Perhaps it’s time to get rid of the YAML menu/tab under the dev tools and just call it config, then the (hopefully to be implemented) reload Jinja/macros button can live there too.
You’re miss interpreting the function behind that specific button with the existence of the button. I’m simply pointing out that this service does not follow the same paradigm all the other buttons do. It’s a service that’s not tied to an integration and it exists in that list of buttons. So the building blocks for adding reload_custom_templates to that page may already exist. That’s all I was saying.
No, well maybe… for now, I was merely reporting my experience with it… (independently from any possible future use for a reload of these custom_templates)
Right, but your experience with that button has nothing to do with a new button that would just essentially call the reload custom templates service.