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.
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 
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.
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 
Good/interesting point:
sensor.daylight come from?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:
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.)
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.
Whilst I appreciated and accepted your opinion that this would improve with time, 2 years later and I still battle with this issue. I have noticed little amelioration. Some examples of attributes that someone might want to turn into an entity in order to be able to record and view history, or expose to assist agents, on my system include, as of 2024.7.4:
states.
alarm_control_panel.alarmo.changed_by
automation.automation_51.last_triggered
binary_sensor.ping_google_co_uk.round_trip_time_avg
calendar.myemail_gmail_com.message
calendar.myemail_gmail_com.location
calendar.myemail_gmail_com.start_time
climate.radiator.temperature
climate.radiator.current_temperature
climate.radiator.hvac_action
climate.radiator.preset_mode
device_tracker.laptop.last_time_reachable
device_tracker.laptop.ip
light.zha_light.brightness
media_player.study_speaker.volume_level
media_player.study_speaker.media_conent_type
media_player.study_speaker.media_title
script.turn_off_house.last_triggered
sensor.zha_battery.battery_voltage
sensor.london_underground_central_line.description
update.addon.in_progress
update.addon.installed_version
weather.home.temperature
weather.home.dew_point
weather.home.pressure
weather.home.humidity
zone.home.persons
The process is going to take years. There’s 2000+ integrations and each one needs to be updated to get an attribute as a separate entity. You’ll have to exercise your patience for this.
I think, perhaps that is an argument for the prosecution, not the defence. If a solution will take a decade, why not implement a better solution (attribute as sensor) and allow it’s use to be faded it out with time?
There are plenty of good solutions but you haven’t described what you’re trying to do. If you just want history, you can make a template sensor in the UI in under 5 seconds for every one of those conditions. Here, I made all the templates for you.
{{ state_attr("alarm_control_panel.alarmo", "changed_by") }}
{{ state_attr("automation.automation_51", "last_triggered") }}
{{ state_attr("binary_sensor.ping_google_co_uk", "round_trip_time_avg") }}
{{ state_attr("calendar.myemail_gmail_com", "message") }}
{{ state_attr("calendar.myemail_gmail_com", "location") }}
{{ state_attr("calendar.myemail_gmail_com", "start_time") }}
{{ state_attr("climate.radiator", "temperature") }}
{{ state_attr("climate.radiator", "current_temperature") }}
{{ state_attr("climate.radiator", "hvac_action") }}
{{ state_attr("climate.radiator", "preset_mode") }}
{{ state_attr("device_tracker.laptop", "last_time_reachable") }}
{{ state_attr("device_tracker.laptop", "ip") }}
{{ state_attr("light.zha_light", "brightness") }}
{{ state_attr("media_player.study_speaker", "volume_level") }}
{{ state_attr("media_player.study_speaker", "media_conent_type") }}
{{ state_attr("media_player.study_speaker", "media_title") }}
{{ state_attr("script.turn_off_house", "last_triggered") }}
{{ state_attr("sensor.zha_battery", "battery_voltage") }}
{{ state_attr("sensor.london_underground_central_line", "description") }}
{{ state_attr("update.addon", "in_progress") }}
{{ state_attr("update.addon", "installed_version") }}
{{ state_attr("weather.home", "temperature") }}
{{ state_attr("weather.home", "dew_point") }}
{{ state_attr("weather.home", "pressure") }}
{{ state_attr("weather.home", "humidity") }}
{{ state_attr("zone.home", "persons") }}
The joys of text editors 
Nope, didn’t use a text editor. Anyways, my point is, there are easy ways to get what you want right this minute for just about everything. As for them automatically being turned into entities by the integration, you’ll have to wait.
For the UI, theres things called State Content, which will allow you to display attributes in the UI with the click of a button.
For history, you make a template sensor in the UI, or in yaml. Whatever floats your boat.
FYI this is what I used
{% set x = """alarm_control_panel.alarmo.changed_by
automation.automation_51.last_triggered
binary_sensor.ping_google_co_uk.round_trip_time_avg
calendar.myemail_gmail_com.message
calendar.myemail_gmail_com.location
calendar.myemail_gmail_com.start_time
climate.radiator.temperature
climate.radiator.current_temperature
climate.radiator.hvac_action
climate.radiator.preset_mode
device_tracker.laptop.last_time_reachable
device_tracker.laptop.ip
light.zha_light.brightness
media_player.study_speaker.volume_level
media_player.study_speaker.media_conent_type
media_player.study_speaker.media_title
script.turn_off_house.last_triggered
sensor.zha_battery.battery_voltage
sensor.london_underground_central_line.description
update.addon.in_progress
update.addon.installed_version
weather.home.temperature
weather.home.dew_point
weather.home.pressure
weather.home.humidity
zone.home.persons""" %}
{%- for line in x.split('\n') %}
{%- set a, b, c = line.strip().split('.') %}
{{ '{{ state_attr("%s.%s", "%s") }}'%(a,b,c) }}
{%- endfor %}
FYI, if you run this in the template editor, it will generate all available attributes and you can simply copy/paste the template of your choice.
Go Here
Clear the contents.
Paste this:
{%- for s in states %}
{%- for k in s.attributes.keys() %}
{{ '{{{{ state_attr("{0}", "{1}") }}}}'.format(s.entity_id, k) }}
{%- endfor %}
{%- endfor %}
Find your entity & attribute and copy the single line for it.
Go here
Make a new template helper using the copied template.