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.
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
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.
@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.
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:
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:
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.)