Exclude/Include entity attributes from Recorder

[emandtf]

Describe your core improvement

Add the possibility to exclude/include Entity Attributes from Recorder like already we can do for Entitites/Domains.

Current limitations

Entity attributes are stored in a separated DB table and all USUALLY works fine.
In some cases it could be possibile that an Entity has a lot of Attributes and at least one of them changes very often like a Timestamp/Epoch float, currently Voltage with 2 decimals and which is sent every 1 second, etc...

It could be possible to exclude the main Entity from Recorder and create a new Template Sensor with just entities we need, but this double entities and became hard to manage if "for every little thing" we use this "trick" by doubleing/tripleing them.
As an example at this moment I have:

• 1 Main entity for Wattage (excluded from Recorder) that sends its value every second WITH its timestamp and Wattage with 2 decimals

• 1 entity (clone of the main one) that...:

  1. ...reduces the amount of stored values at only when the new value is different by X-Watts from the last one or has passed 15 minutes. This entity is used for charts because I need just an approssimate chart and not the precise one by using all 86400 records. Using a Filter Entity would shows same chart but really stored values would be 86400 per-day in any case and I don't want these. As you can see (sorry for the difference in scale between those two charts) points are very few but the final charts is quite good.
     
  2. ...has additional Custom Attributes for storing special Events/Peaks/etc.. without the need of create other Entities to store them and doubleing/tripleing entities. Unfortunately those values could be Timestamp/Epoch float, the precise Watt value, a combination of them, etc.... Due to this all stored records are "unique" and will not be re-used for other similar-but-not-equal future states. This generates a lot of not-needed records.

  Custom attributes:

  • last_peak_at: "2025-06-30T08:00:00Z"
  • last_peak_value: 248.37
  • ...others...

  Stored records in MySQL:

  • {"icon":"mdi:flash","friendly_name":"watt_studio", "last_peak_at": "2025-06-30T08:00:00Z", "last_peak_value": 248.37}
  • {"icon":"mdi:flash","friendly_name":"watt_studio", "last_peak_at": "2025-06-30T08:00:02Z", "last_peak_value": 248.39}
  • {"icon":"mdi:flash","friendly_name":"watt_studio", "last_peak_at": "2025-06-30T08:00:04Z", "last_peak_value": 248.44}

  The results are: N-records in "state_attributes" for the same "states" record which has always an approssimation to the closest Integer (248).

Current solution would be to have:

• (same as before) 1 Main entity excluded from Recorder as already I have
• 1 entity to reduce the amount of stored data (for charts) BUT without adding any Custom Attribute
• 1 entity (excluded from Recorder) for storing all those Custom Attributes

This procedure for ALL my 77 Wattage sensors...........

Same behaviour for other kind of entities where I store custom attributes base on other entities and that I would not be interested to store in the database but the main STATE of those entitites and not those custom attributes.
So for any entity of this kind it would be possibile to have double/triple/duadruple similar Entitites with similar friendly_names but that refers to slight different information from the Main one.

Excluding Attributes is available in Python development of Integrations/Core but not for HA as "normal-user".

Technical benefits

If it would possibile to Exclude "last_peak_at" and "last_peak_value" Attributes, it would be possibile to re-use same:

{"icon":"mdi:flash","friendly_name":"watt_studio"}

record without the "last_peak_at: 2025-06-30T08:00:00Z, last_peak_value: 248.37" dynamic and "unique" part.
Similar thing was done times ago directly in the Core by excluding Light attributes due to their nature to be "unique" when saved all together with temperature/mireds/kelvin, brightness, etc...

Additional context

No response