or try something in the lines of:
- color: |
[[[ if (2 < entity.state && entity.state <= 20) return 'purple';]]]
of course replace the entity.state with the attributes of your liking, or even the external entity
note the
[[[ if (2 < entity.state <= 20) return 'purple';]]]
which would work in jinja templates doesn’t work in JS…
in your case:
[[[ var position = states[‘cover.pc_r’].attributes.current_position;
if ( 49 <= position && position <= 51) return '#008bef'; ]]]
Is it possible to use a template like this:
- type: custom:button-card
name: >
[[[
if is_state('sensor.moon', 'new_moon')
return 'Luna Nuova';
elif is_state('sensor.moon', 'waning_crescent')
return 'Gibbosa crescente';
elif is_state('sensor.moon', 'waxing_crescent')
return 'Mezzaluna crescente';
elif is_state('sensor.moon', 'first_quarter')
return 'Primo Quarto';
elif is_state('sensor.moon', 'waxing_gibbous')
return 'Gibbosa crescente';
elif is_state('sensor.moon', 'full_moon')
return 'Luna Piena';
elif is_state('sensor.moon', 'waning_gibbous')
return 'Gibbosa calante';
elif is_state('sensor.moon', 'last_quarter')
return 'Ultimo Quarto';
]]]
It is not working here… where is the culprit?
you’re trying to use Jinja templating in a Javascript setting…
Yes, you’re right, but my knowledge doesn’t allow me to make this right,
Can you give me the right template so i can learn ?
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
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.
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.
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