Simple UI to create temperature entity from climate attribute

Templating is a pain to us non-programmers. Why not have a simple UI to create an entity from ANY object attribute? In particular it seems all thermostats have lots of object attributes we would want to see or change. I know templating is powerful and you can do a lot with them, but why not make it easy to simply expose an attribute like “temperature”? The helper template is a good start, but just add a drop-down menu to select an attribute from an entity?

Probably because the template to report the value of an entity’s attribute is so trivial compared to the time and effort to build a UI to do it.

Put this into a Template Sensor helper.

{{ state_attr('climate.bedroom', 'temperature') }}

Reference

Templating - States

if that really is all you want, you want to have a look at type: attribute option of the entities card

no need to template anything. (though, in all honesty, it is not the same as a dedicated templated entity… click the attribute, and you are presented with the more-info of the main entity)

1 Like

I don’t see a “type: attribute” option in my entities card. Do you mean go into yaml and add that?

yes, as is shown in the link I attached

That’s exactly my point that you missed. You have to use jinja. For those who want to stick to the UI, and don’t want to mess with jinja trial and error, why not simply drop down a selection menu for attributes. It’s trivial for YOU, not the majority of users. HA is changing its user base, you know.
And yes I use exactly that solution. I’m suggesting an simpler easier approach.

Youve completely lost me there…

why do you HAVE to use Jinja? My point is, you dont need that at all, as the core Frontend options for the entities card provide you with exactly what you say you need

Again you miss my point of not using coding (jinja nor yaml). My title says “simple UI”.

yaml is not coding…

type: entities
title: Entities card sample
entities:
  - type: attribute
    entity: sun.sun
    attribute: elevation
    name: Sun elevation
    prefix: "~"
    suffix: Units

and this can be done in the UI too

they might be able to add a dropdown for the attributes in the row editor. that would be nice indeed

Actually, I didn’t “miss your point”. If you or anyone else finds that simple template to be too challenging, then you picked the wrong home automation product.

Jinja2 is an integral part of Home Assistant. Attempting to avoid learning it, or asking for special-purpose UI screens to avoid it, is a non-starter.

  • If you simply want to display an attribute’s value in a card then Marius has explained how easy it is to do that.

  • If you want to create a virtual entity, then a Template Sensor is the way to do it.

Creating a single-purpose UI to merely extract an attribute value is far too niche of an application. More often than not there’s a requirement to also process the attribute’s value (such as changing watts to kilowatts). So, once again, a template is required because that’s Home Assistant’s primary tool for data-processing.

It’s obviously non-trivial for you but that’s true for anyone unfamiliar with a given tool.

I agree the userbase now includes people who aren’t willing to learn anything beyond what is displayed in the UI. Unfortunately for them, not all of Home Assistant’s functionality translates easily to a graphical UI and so the development in that area has traditionally been very slow.

According to Home Assistant’s analytics, 23% of confirmed installations use the Template integration. That’s approximately 85 thousand users. Learning how to create a template isn’t all that onerous or uncommon.

Speak for yourself…

When I started using Home Assistant, the most recent “programming” I had been taught was in middle school and involved a “turtle” drawing shapes. Learning about templating really opened up the power and flexibility of HA for me, a non-programmer.

Hello starmanj,

If you still think this is something you want to pursue (personally I do not recommend it, but you be you), this appears to be a Frontend Related Feature Request as it is asking for changes to Frontend Menus, Dashboards, or Sections.

These Feature Requests are handled in a different system, and will not be seen by the right people if posted in the HA forums.

Please add your Feature Request into GitHub here:
home-assistant/frontend Other Feature Requests · Discussions · GitHub.

See more info about Feature Requests HERE

1 Like

I’m actually surprised it’s only 23%.
But then again this only counts templates as sensors, not in automations I guess.
Although I’m not sure which is more common

There is no need to change anything in the frontend.
There is already a card that can display the attributes.
And actually, in this case perhaps the climate card is even better.

That is using the template integration is reported at 23%. However inline jinja templates are not counted in that.

Okay. So the UI is for light weights, shouldn’t even have it. YAML and Jinjs is the only true way.

Voice assistant is coming on strong, and it seems to me an obvious use case is asking it : What’s the temperature in a certain room. The only way to do that is through creating a template using jinja. That’s what I’m trying to do. As well as expose many more attributes than that. The whole idea of the UI is to make things faster and easier for the end-user. This forum is always reactionary saying here’s the complex way to do it, I’m suggesting a simpler route. That’s all.

You and @Hellis81 are correct, templates are employed in more than just the Template integration. However, how much more is unclear so the point was that at least as the number of installations using the Template integration (85K).

No one suggested that; if that’s your conclusion, I suggest you review the comments.

The fact you characterize opposing views as “always reactionary” and that all counter-proposals are necessarily “complex” suggests you’re unwilling to having your proposal challenged.

Everyone is free to propose new features and, equally,
everyone is free to comment on the proposals. The majority of FRs are never implemented so counter-proposals frequently explain how the task can be performed today. A volunteer developer will examine both and decide if it’s worth their time and effort to implement the proposal.


BTW, I agree with Sir_Goodenough; your Feature Request involves Home Assistant’s Frontend and that kind of FR is submitted in Home Assistant’s Github Frontend repository.

2 Likes