Deprecate air_quality entity

[ahayworth]

Context

The air_quality entity represents what is essentially a collection of 11 (actually, 12) different sensor values, yet it has a separate entity within home assistant core. This leads to subpar "out of the box" support:

• No built-in lovelace card that can represent this entity does it very well:
  • entities card: only represents the state attribute.
  • history graph card: does not graph the state attribute in a sensible way:
    Screenshot

    
  • glance card: only represents the state attribute
  • sensor, gauge cards: hard-coded to only support sensor entities
• No material design icon exists for the air_quality entity, and different integrations have each selected their own icons.
• Some logical "air quality" devices must be represented both as an air_quality entity + additional sensor entities, because they track values not in the 11 standard attributes of the air_quality entity. For example, Airly tracks humidity, pressure, and temperature which are represented as sensor entities in addition to the air_quality entity.
• We cannot rely on the air_quality unit of measurement, because units are not standardized; thus, there is not one unit of measurement. For example, the US EPA measures PM2.5 density in "µg/m3" but CO in "ppm".
• The air_quality entity essentially aliases PM2.5 to state, which may or may not make sense for a given air_quality device (for example, the first-generation Awair device uses a hybrid PM2.5/PM10 "dust" sensor). Further, if an integration does know something like the CAQI score, it may make more sense for the state to be that score, rather than the PM2.5 value.

I have been working on two things: updating the Awair integration to use the air_quality entity, and also creating a lovelace card that represents the air_quality entity in a reasonable and informative manner. However, the list of problems have made this task much more daunting than it needs to be.

Proposal

I propose that we deprecate the air_quality component and instead have integrations create a collection of sensor values. At its core, the air_quality component is a collection of sensor values - be they remotely measured at a central agency, or locally in your home.

Consequences

Pros:

• The sensor and gauge lovelace cards are immediately available for these devices, and I believe the history_graph card will graph things more sensibly.
• We do not need to deal with the differing units and standards between the US and EU (not to mention other parts of the world) at a high level: rather, integrations can set units appropriately for the individual sensors they create.
• We will not need a special lovelace card just for the air_quality entity, since the default cards we ship will allow users to visualize their device appropriately. (We may still wish to provide an "air quality" card or a "multi sensor" card that allows users to display these values succinctly, but it is no longer necessary for a good experience).
• We side-step issues of "which measurement should be the state for this entity?" because we will be creating multiple sensor entities, rather than a monolithic air_quality entity.

Cons:

• It is a major breaking change.
• It requires that 10 different integrations be converted from air_quality entities to sensor entities.
• It will require users to update their views.

Unknowns

• Will this require extensive work on the homekit integration? The Homekit Accessory Protocol defines a logical "air quality" device as a collection of sensors, exactly like the air_quality entity does today - and exactly the opposite of what I'm proposing.
• Is it instead worth our time to extend the overall entity model to support an entity that has multiple possible "states" and "unit of measurement" values? It's not clear to me that it provides any value to the rest of home-assistant core, but perhaps I've not considered something.

[Jc2k]

I am all for this.

I think this is somewhat related to https://github.com/home-assistant/architecture/issues/359. There instead of adding a attribute onto the battery sensor its proposed to break it out into 2 entities and use the device registry to express the relationship between the 2 entities.

It's also a good example of the HomeKit problem you mentioned - @bdraco is looking into using the device registry to merge 2 entities about the same battery into a single HAP 'service'. It looks like it is do-able from what i have seen, as long as the integrations use the device registry.

Support for the AirQuality entity in homekit stalled though so it's not an immediate worry (https://github.com/home-assistant/core/pull/30383)

Incidentally it is something of a PITA for homekit_controller, right now there is an annoying assumption that theres a 1-1 mapping between entities and services. But I will fix that in homekit_controller if we do break it out (somehow.)

[BradleyFord]

Just an additional note.

This also applies to the Xiaomi air purifiers; at the moment I am breaking out the PM2.5 attribute into a sensor so I display it on the UI alongside the AirVisual data.

[bramkragten]

The Xiaomi air purifier uses a fan entity with all the info in the attributes, that is not specifically related to this, but it should break all the info into separate sensor entities.

I think deprecating air_quality is a good idea.

[dgomes]

If we go this route, we might as well deprecate weather, it's also a collection of sensors (temperature, humidity, pressure, etc)

I'm not sure this is a good idea, it opens a precedent.

[Jc2k]

Maybe there is such a thing as going too far. But what is it and why? A bit of a strawman but if weather is reporting current values for those things as seperate sensors, what would be wrong with that? If the UI didn't change but it made it easier for users to do automations based off weather data or use the other graph panels wouldn't it be a good thing?

To make a decision about this, should we first come up with some guidelines about when things should be an all-in-one entity with lots of attributes and when they should be decomposed into multiple entities? Should that be a seperate ADR?

@frenck said in https://github.com/home-assistant/architecture/issues/359 that it was a good idea to split that sensor in 2 because (sorry if miss-paraphrasing!):

• There were definitely multiple seperate logical states
• Users might want to run automations based off both of those states

I'd definitely do an automation off CAQI score etc. But maybe not off some of the other values. But i'd like to do graphs of them. Is that enough of a reason?

Some other examples to consider to help better define such guidelines:

• Some oulets have a "in use" attribute that is True if something is pluggged in and False if not. I think some irrigation systems do too. Should they be seperate binary_sensors instead of attributes?

• Some outlets can report their electricity usage. Should that be a seperate sensor too?

What about these 2 attributes mean that they should or shouldn't be decomposed into seperate entities?

Traditionally the auto-UI would have been a concern, i guess, as you would have loads of potentially un-interesting entities pop up and crowd out the interesting stuff. Is that less of an issue now? Should we make these "sub-entities" not part of the auto-UI? In the HomeKit world there is the notion of a primary entity with related sub entities.

[dgomes]

My point is that this decision should not be about deprecating air_quality alone.

It should be about all entities that are bundle of multiple sensors/entities.

[bramkragten]

Ideally, we would break everything up in separate entities and allow to link those together, the same applies to climate, there is a target, current temperature and maybe humidity attribute.

[Jc2k]

@dgomes I read too much into what you meant be precedent then, sorry for that - i thought it implied that it was a bad thing that shouldn't happen, not that we should review everything and do it event more widely!

I think we should deprecate air quality. The air quality entity should really just be a "Device" (in the device registry sense) with a bunch of sensor entities. I think it should have been done this way originally, as it's what the device registry is meant to enable.

I think we should review the other entities too. And for that my point still stands then, we should define some criteria about when an attribute is actually a state that should be a seperate entity. I think the conversation in #359 has a start there.

[bachya]

Has anyone investigated the rationale behind creating air_quality in the first place?

[Jc2k]

https://github.com/home-assistant/architecture/issues/109

Does that help? My take is nothing in there invalidates this discussion. The intention was to group lots of different sensors together. But that’s what the device registry is for. And it does feel like if it were added today it would lean on the device registry and be multiple sensors.

[balloob]

One comment about original proposal:

No built-in lovelace card that can represent this entity does it very well

Frontend issues can never be used as a reason to change the backend.

@bramkragten for climate, I would consider HVAC mode + target range to be together (Google calls it "TemperatureSetting"). We should have pushed current temp/humid out of climate during our big refactor last year :(

I think that the future is that a device is represented by a set of entities with each entity identified by a device class.

Another one to extract is current power usage from switches that support it.

[ahayworth]

Frontend issues can never be used as a reason to change the backend.

Some of the work I initially began was essentially “change the cards hard-coded to only support sensors to also support air_quality” - but I began to worry that the complexity of the air_quality component couldn’t be represented in the sensor card without making that card much more complicated. In essence, I felt that the complexity of the backend would prohibit changes to the front end - I wasn’t sure that the front-end changes would be accepted.

That’s why I then began pursuing a separate card entirely, before finally deciding to propose this deprecation.

Otherwise, though - I understand what you’re saying and mostly agree. And decoupling the front end and backend allows for greater innovation and flexibility in the long run - it’s a smart move.

However: I think this issue should be framed a little differently. The backend in this instance (air_quality) forces additional complexity onto all frontends - not just Lovelace - and it’s unclear what value the additional complexity adds.

While I initially proposed this based on my experience trying to surface the component in Lovelace, after reflecting on it for a few days I think it should be considered in light of reducing complexity and driving uniformity across the entire backend. The fact that the Lovelace benefits is not what I would use to advocate for the deprecation.

With that in mind - and the issue linked that advocated for the air_quality component in the first place - is there any value the component provides on its own now that we have the device registry?

[fabaff]

air_quality, is like weather, a "meta-integration" that focused on gathering data from third-party web services and not local units. They were created to allow users to switch between different integrations back and forth without loosing their history. All platforms are limited to the most common values at the time of creating the integration. If you compare the sensors which are gathering and displaying weather or air quality data and the air_quality and the weather integrations you will see a huge different in the available data.

Nowadays, this concept is kind of obsolete. And I agree that this should be handled by device classes.