I just cant find the right formatting for hs_color to make a working script and I don´t know if this is a user error or a lack of functionality. If i instead use color_name instead of hs_color and use for instance “red” as a color, then it works fine.
You’re making an assumption that the template will produce a list like this:
hs_color:
- 44.793
- 85.098
which is the same as this:
hs_color: [ 44.793, 85.098 ]
However, a Jinja2 template can only produces strings. So your template produces what appears to be a list but it’s actually just a string that looks like a list. In other words, your template produces a string like this which is unacceptable to the hs_color option.
hs_color: "[ 44.793, 85.098 ]"
The solution is for hs_color to accept a list or a string containing comma-delimited items. There’s a precedent for this behavior elsewhere in Home Assistant. If you want to turn on some lights, you can specify them like this:
Okay, now I understand the real problem here. string vs list.
So how would one solve this issue then? I read somewhere that color_name is being deprecated and that´s where I began to look into using hs_color instead.
If I´m wrong about this deprecation or that is is only valid for scenes, then please correct me. Then I could spend some time finding the right CSS color name to use for my script instead.
I haven’t heard that rumor so use color_name because it’s far easier to template.
If you really want to use hs_color you have to template the two variables (hue and saturation) separately. It’s clumsy and repetitive (more so if you use rgb_color) but it works.
data_template:
entity_id: light.ikeatradfricolor1
hs_color:
- "{{ 0 if now().hour >= 23 else 44.793 if now().hour >= 21 else 44.69 if now().hour >= 18 else 44.69 if now().hour < 10 else 0 }}"
- "{{ 100 if now().hour >= 23 else 85.098 if now().hour >= 21 else 65 if now().hour >= 18 else 56.863 if now().hour < 10 else 0.392 }}"
transition: 1
Thank you @123 for the clarification of splitting up the list into two variables. Very helpful!
I´m happy to be able to say that I now have one problem less to think about. Either way it would have been nice if there was a way to use lists even in templates.
Yes, when scenes were revised a few months ago, they limited their control to setting an entity’s state and not all its attributes. For lights, there was pushback from the community and and control was extended to include transition.
Glad hear the template works for you. Please consider marking my previous post with the Solution tag. This will automatically place a check-mark next the topic’s title which signals to other users that this topic has an accepted solution. It will also automatically place a link under your first post that leads to the Solution post. All of this helps other users find answers to similar questions.
Yes, it just sat in the queue and never piqued anyone’s interest enough to review it, so I finally gave up and closed it. I suppose I could try reviving it, but it’s so old it would probably be more work to rebase, etc. than to start over. But without any indication that it will go anywhere this time, it’s kind of hard to start that process…
Is that appropriate for a WTH topic? Doesn’t it need to stay open so people can vote on it and hopefully make it to the point where something will actually be done?
You got a point there. The use of color_name is my solution but the initial problematic insight to templating in jinja is still frustrating. I will unmark the reply as a solution until further notice but want to express my gratitude in the help i have gotten here.
It’s not really a solution to the WTH topic. It’s a workaround. I think that’s the main point. As I see it, these WTH topics are not supposed to be treated like typical request for help topics. Or maybe I’m missing something.
I have seen WTH topics with solutions. Sometimes the question does have an answer even though it might not be the answer the user was expecting. So the notion of ‘workaround’ depends on the individual’s frame of mind.
Currently, if you want to template hs_color, that’s the way it’s done. If the user wants a Jinja2 template to crank out lists, that’s a fine wish, but good luck ever seeing it come true. Effectively, they will never get their desired ‘solution’.
Regardless, if euf0ria doesn’t think it’s a solution, then it’s not a solution … but it does work.
That’s not the only solution. And, yes, if someone has wished for something that already exists, then I can see marking the topic as solved. But, again, I think you’re thinking about the Month of “What the heck?!” category incorrectly. But that’s just my opinion.
This is another attempt, but one on a bigger scale.
It is really tricky, so not really sure if this one is going to be the solution. However, it would solve the issue presented in this topic, as it adds support for all native types, including tuples like hs_color.
