Sorry, at least can you give me some hints where to learn more about it?
I am following the docs in the button-card repository, but cannot find more infos about my problem.
sure, in this case itās not so difficult though:
[[[ var moon = states['sensor.moon'].state;
if (moon == 'new_moon') return 'Luna Nuova';
if (moon == 'waning_crescent') return 'Gibbosa crescente';
if (moon == 'waxing_crescent') return 'Mezzaluna crescente';
if (moon == 'first_quarter') return 'Primo Quarto';
if (moon == 'waxing_gibbous') return 'Gibbosa crescente';
if (moon == 'full_moon') return 'Luna Piena';
if (moon == 'waning_gibbous') return 'Gibbosa calante';
return 'Ultimo Quarto';]]]
note that Iāve set variable moon to not have to use the states[āsensor.moonā] constantly
note2 that Iāve replaced the final if and only use return there. That is the else clause, needed to guard you dont have a template without state if the entity wouldnāt have a state somehow. Now, it wont create an error. Always use an else clause.
I would advise you to read a bit more, and start creating these configs yourself. Only copying and asking configs will get you started, but you wonāt learn and create your own setup.
Test jinja templates in the templates developer tools, test js templates in the webbrowser inspector.
hope this helps
ps, note 3
I prefer using templates in the backend and not let the Lovelace frontend do all the arithmetic. See the template for the entity_picture:
- type: custom:button-card
template: button_body
entity: sensor.mooon
size: 70%
show_name: true
show_entity_picture: true
name: >
[[[var moon = states['sensor.moon'].state;
if (moon == 'new_moon') return 'Luna Nuova';
if (moon == 'waning_crescent') return 'Gibbosa crescente';
if (moon == 'waxing_crescent') return 'Mezzaluna crescente';
if (moon == 'first_quarter') return 'Primo Quarto';
if (moon == 'waxing_gibbous') return 'Gibbosa crescente';
if (moon == 'full_moon') return 'Luna Piena';
if (moon == 'waning_gibbous') return 'Gibbosa calante';
return 'Ultimo Quarto';]]]
entity_picture: >
[[[ return states['sensor.moon_phases'].attributes.entity_picture;]]]
dont pay attention to the formatting, this is only an example of how to use an existing (if not, create it firstā¦) template sensor in your backend in the Lovelace cards
2 Likes
Thanks a lotā¦ finally i can have under my fingers to begin to understand how tempaltes are working.
admittedly, it is a bit taunting for beginnersā¦
You should try to understand that native Ha templates use jinja
but most of the Lovelace custom cards use javascript. Added to that, many cards use their own specific ādialectāā¦ Iāve asked many a times to streamline that, but since there is no native HA Lovelace templating default, this is an unanswered question unfortunately.
Also, (most of) the native Lovelace cards donāt use templating at all, besides the new Markdown card. Luckily the custom cards by @thomasloven now use Jinja, so you can simply copy paste your native HA templates in his cards. which is an enormous step forward.
the main difference between the 2 (jinja and Javascript (JS)) is Jinja templates are evaluated in the HA backend (processor side) and JS is evaluated in the frontend (browser side). Depending on your setup either will perform better. It is my experience that Lovelace is rather heavy on the system, and that relieving the frontend (read Lovelace cards) as much as possible from complex templates works best.
a fine source to read is @andrey 's Custom-ui doc on templating: home-assistant-custom-ui/docs/templates.md at 5274c9b1e51d8a4ba409cbf510d286472d42c328 Ā· andrey-git/home-assistant-custom-ui Ā· GitHub
Note that this is pre Lovelace, but it explains some of the system intricacies rather well, and has some fine examples.
Of course, the examples in Button-card and the ThomasLoven cards are very enlightening too.
2 Likes
I can second this, having stuff loaded in the backend will severely improve the frontend loading times. This is true for almost everything you do in the frontend. My setup is pretty large and loading it on older devices take forever. I recently started to move things I have in the frontend. Not everything is possible but at least the stuff that can be done through the backend. For example, you shouldnāt define icons on entities within lovelace, a better way is to define this in customize.yaml (or the customization panel within the UI).
defining your icons in customize vs a card is not going to give you performance increases
Both jinja2 and javascript have their benefits. There is a lot you can do in javascript that wouldnāt be possible with jinja2; look at my weather button example, I donāt believe that would be possible with jinja2 (Iām admittedly a coder though and not a jinja2 expert so I may be wrong).
Regardless, the templating system is not going to change. That would be a huge breaking change. Offering jinja2 support does sound feasible though.
I donāt see myself getting around to adding it anytime soon, been pretty busy working on HA core and I know @RomRider is pretty busy himself; if someone were to add a PR for it though, I would not want to see card-tools added as a dependency to be manually installed. Instead the functionality for template evaluation should be extracted to the custom-card-helpers module.
1 Like
Hm ok, my bad then. I thought defining them in the backend would save resources on the frontend.
Discard what I have said before in this case. My apologies.
itās just a static string either way. there might be some performance gains using the backend to evaluate a template, but I really doubt it would make that much of a difference. Someone could probably do some semi-good testing now using the config-template-card (js) vs the lovelace-template-card (jinja2)
@RomRider I have another question for you. Would it be possible to template the icon spin? Just like an icon or color template would? That would be amazing.
Btw, I have opened a feature request for the dropdown menu. Thanks again.
Most of the people are running HA on raspberry PIs, and running that on the backend through jinja2 is only going to increase the load instead of reducing it.
Your phone, iPad, tablet, computer where your browser is displayed they are all fast (and JS is super fast on all the devices). Your backend is slow unless you have a high end server and this is far from being the case for everyone.
Evaluating a template in the frontend is not taking time, what is taking time is all the JS around it (a template is what, 10 lines?), the whole code for button-card is 120kB !!
Iām not going to add jinja2 through the backend support to the card, but PRs are welcome 
No need, I was wrong as @iantrich pointed out. Though I still wonder if a spinning icon would be possible to template
Feature requests on github is the way to go so that I can track that down. Iāll take some time to deliver them in the future but I have so much work right now itās just not possible. Iām almost never at home and traveling all the time for work. Right now Iām in Austin, TX for example 
Donāt worry, no hurries. I will open another feature request for it. Take your time, you have already put in so much time for us. I can hardly complain!
Thanks again @RomRider
Guess this is what itās all about, and I agree with your remarks on frontend vs backend. Still, although using js templates in customize is fast and trouble free as one could wish, using js in custom Lovelace cards can bog the system significantly. Canāt explain it, it simply does.
I wonder if you can explain what you say here: āwhat is taking time is all the JS aroundā
(must stress that on my new RPi4, this is much less obvious, and my Hue config stays online much of the time, which is something to hurray about. Before, even reloading Lovelace would make the Hue lights of unavailable signaling capacity issues on the system)
Using the states of backend jinja template sensor can relieve that, let alone make the configs of these Lovelace cards much simpler, which is a feat on its own.
Now this sounds like music to my ears. Though I am far from capable to create a PR as such, I would gladly offer my time and assistance in testing and aiding such a development.
Since it apparently is feasible, looking at ThomasLovens cards, why wouldnāt it be for the other cards I wonder.
This might depend on the technique used though. Using Customizing entities - Home Assistant isnāt the same as using the custom-ui js templates, which would be done in the frontend, or as people sometimes say, on the fly, in browser. Which is rather fast with modern day devices.
And, of course, its is not only icons we can customizeā¦
All in all, your mileage may vary 
might I ask you to hop over here, and see if you can help me out with some niftier nested JS templates then Ive been able to come up withā¦
apreciated if you would
Can someone tell me why this configuration template is not working?
ciabatte_1:
entity: '[[entity]]'
icon: >
[[[
if (entity.state === 'on')
return "mdi:power-socket-eu";
else
return "mdi:power-socket-eu";
]]]
tap_action:
action: call-service
service: switch.toggle
service_data:
entity_id: '[[entity_id]]'
styles:
card:
- font-weight: bold
- font-size: 13px
- font-family: 'Times New Roman'
icon:
- color: >
[[[
if (entity.state === 'on')
return "red";
else
return "green";
]]]
It gives me error about data [entity_id]ā¦
well, we cant cause we dont know what youāre feeding itā¦or what the template config looks like
btw, youāve got [[entity]] and [[entity_id]] in this config, are they pointing to the same entity_id?
also your template for the icon seems unnecessary since in all cases you want the same icon ? no need for a template then 
You should share the decluttering-card that you use with this that gives this error. A logical thing to me would be that you have set the entity in your variables, but not set the entity_id. If you want them to be the same you wonāt need a service-call. A tap_action toggle would do exactly that.
Edit: and @Mariusthvdb is correct, you seem to use the exact same icon in both the āonā state and any other state. Again if you want them to be the same just put the icon instead of a template. So icon: mdi:power-socket-eu.
Ok, about the icon youāre right, itās my fault.
About the decluttering-card (if with this you mean the original card without configuration template), itās this:
- type: custom:button-card
name: Ciabatta 1
entity: switch.ciabatta1
icon: mdi:power-socket-eu
tap_action:
action: call-service
service: switch.toggle
service_data:
entity_id: switch.ciabatta1
styles:
card:
- font-weight: bold
- font-size: 13px
- font-family: 'Times New Roman'
icon:
- color: >
[[[
if (states['switch.ciabatta1'].state == 'on')
return "red";
else
return "green";
]]]
The entity and the entity_id point to the same entity, but i think the entity: switch.ciabatta1 is not so necessary as the entity_id: switch.ciabatta1 in the toggle action.