WTH are attributes such a pain to work with

So much helpful stuff are stored in entity attributes. Things that spring to mind are temperature, last changed and so on.

However, as far as I know, you basically need to use templates to access them or do logic or automations with them (apart from triggers).

There’s probably more than one solution, but this is one:

In general, attributes are something we nowadays try to avoid. Mostly you’ll see them from “older” or custom integration. For new integrations and in our review process, we generally don’t allow for attributes that have value/could have been their own entities.

This is a problem that thus will become less of an issue over time.

4 Likes

Sorry to go a bit off-topic, but can I ask why?

I can see that for some entities/attributes, it might make sense, but I find attributes very useful to avoid cluttering up the states with (what I would say is) entities that could just be an attribute.

E.g. the Nordpool sensor that shows 48 hours of (future) electricity prices in a couple of lists (today and tomorrow) in the attributes. I would find it extremely annoying to have 48 new entities instead. With the very similar names, it will also become very difficult to edit anything on mobile (Lovelace cards, automations, etc. via the UI). I know because the Eloverblik integration uses 24 entities instead of putting the 24h in attributes, and I need to use a computer to be able to do anything with them via UI.

The same for basically anything that has a lot of logically related data in the attributes. A good example is weather forecasts, having one sensor for wind speed tomorrow, one for temperature in 5 days, etc., would seem horrible to me: One sensor would become 42 new ones, in the case of my weather.open_meteo.

However, I do have a lot of faith in the devs, and I’m guessing you have a good reason for it that I am just not seeing (but would like to), so… Can I ask why :slight_smile:

2 Likes

Because attributes are a pain to work with. Attributes were overused in the begining with things that should be separate sensors. There are still uses for attributes in many places and they won’t be going away in those places. Like brightness for a light, or set point temperature on climate, etc. Attributes are being phased out on things that 100% should be it’s own sensor. Like the temperature on a switch or plug.

1 Like

well, start with the sun for example. very common to the core of HA. I like that plab of getting rid of attributes, so starting with the sun.sun would be a good first step

Well, that is now certainly possible. The Sun has been moved to the UI and now has access to provide devices/service with multiple entities. So yeah, agree, would be nice :+1:

Pretty sure @pnbruckner did this with Sun2 and it has more options in regards to timing.

1 Like

Good/interesting point:

  • @pnbruckner’s Sun2 integration is very useful and was one of the first custom integrations I installed at least 2 years ago.
  • The Sun2 integration is fairly old and could stand to be upgraded to take advantage of some of the modern elements of Home Assistant. For example, Sun2 adds a bunch of entities that don’t have any info available through the UI about what integration they belong to. i.e. Where did sensor.daylight come from?
  • Sun2 entities don’t have any consistent naming that can be used to search to see what might be related.
  • Since sun2 is a custom integration, there is no data on how many people use it in Integrations | Home Assistant Analytics
  • It would be nice to see some features of Sun2 make it into the sun integration so less people need to install a custom integration. (Of course data could help drive that decision.)
  • A number of the Sun2 entities actually make extensive use of attributes. For example sensor.daylight:

image

Actually the climate set point (to me) is a great example of an attribute that should be an entity. It is first data that to relate to and use in automation. When did it last change? How long did it take for the observed temperature to catch up? What’s the difference between specific rooms and the set point for the HVAC system.

So back to the topic at hand. Attributes are probably going to be around for a while. I have a lot of template sensors (many in legacy format that need to be converted so they can be used It in statistics. It would be help the UX if there were some tools to make the usage easier. I think there are some other WTHs that are related:

If there are going to be breaking changes (attributes → entities) then it would be good to have some assistance to deal with refactoring and merging history.

Also if the number entities is going to be increasing as attributes start to become somewhat deprecated:

Not sure if this helps, but I think it helps to take a little bit of a broader look at the implications of Home Assistant as a home data platform. I think these things will become more important over time as Home Assistant is used for managing costs, energy being the largest, and doing more to protect property (spot things that need attention because they are out of bounds, don’t follow trends, etc.)

2 Likes

why not modify the history graph card, so it can take attributes? seems simpler that wait for the attributes to go away and will really solve a problem that a lot of people have. that will really help

Unfortunately it looks like the entity from attribute idea is not going to happen. HA Devs seem to favour a slow phase-out of attributes over time.