Problem statement
Home Assistant currently models the smart home through a four-layer architecture. At the top sits the integration, which is the way a device is connected to Home Assistant like Philips Hue, Sonos, SwitchBot, Matter, and so on. An integration can expose one or many devices, each representing a distinct physical thing in the home. Each device in turn exposes one or many entities, which each carry a domain that defines what kind of thing the entity is, like light, climate, sensor, cover, and so on. Finally, some entities in more complex domains carry a device class that differentiates them further within that domain. A cover entity, for example, uses device class to distinguish between a shutter and a curtain.
To make this concrete: the SwitchBot integration (layer 1) exposes a device called "My Office Curtain" (layer 2), which has a cover entity with device class curtain (layer 3) and a sensor entity with device class battery (layer 4).
This model has served Home Assistant well for years and enabled enormous flexibility across thousands of integrations and device brands. However, as Home Assistant grows in ambition toward proactive automation suggestions, context-aware voice, auto-generated dashboards, and collective intelligence through the OHF Device Database, a gap becomes increasingly apparent: none of these four layers captures what a physical device actually is.
With this opportunity we want to revisit the topic of potentially introducing device types once more, both from a product but of course also from a technical perspective, weighting impact and trying to achieve a common ground to proceed in a consecutive step.
Please refer to this document for further discussion and feedback https://docs.google.com/document/d/1uYXLealUYy1IImR6N7l7EqyNzOMi0synqn3lpyYf9ng/edit?tab=t.0
Community signals
The case for device types is not only product reasoning. It is echoed in signals from the Home Assistant community itself.
-
Making Home Assistant more approachable is a stated core goal for 2026, framing it at the State of the Open Home as "lowering the floor without lowering the ceiling." Device types are a direct enabler of that goal: a platform that understands what a device is can guide new users through setup, surface relevant automations, and present a coherent interface without requiring expertise in domains and device classes.
Openhomefoundation
-
The 2025 Home Assistant roadmap named device understanding as a core architectural change, stating that knowing what devices are and how they are used is the foundational prerequisite for collective intelligence features including proactive automations, smarter dashboards, and improved voice.
-
Recurring forum activity around post-setup cleanup, including entity naming confusion, incorrect area assignments, and ambiguous entity lists, points consistently to the same root cause: the platform makes no meaningful first decisions at setup because it does not know what kind of device it is dealing with.
-
The "add device classes to lights" proposal in June 2025 was closed by explicitly deferring it to the device types work planned for later that year, acknowledging the team had discussed the problem multiple times without resolution because device classes alone are the wrong tool.
-
The architecture team declined the "add device class: heater to binary_sensor" proposal on the grounds that the problem it was trying to solve sits above the entity level, reinforcing the pattern that entity-level additions cannot substitute for a device-level identity concept.
-
A community member proposed a "traits" system in November 2025 to make the device object the primary layer for defining device identity, independently arriving at the same structural conclusion as the device types proposal and attracting immediate community support before being redirected to the architecture repository.
Scope & Boundaries
In scope
- Proposal to spark discussions and align views from a product/UX and technical perspective
Not in scope
Foreseen solution
- Written outcome documenting the agreed baseline to iterate on
- Ideally, already have a sliced down implementation roadmap in case we come to a conclusion
Risks & open questions
Risks
- Moderation efforts, we want to include as many people as possible in the discussions
Open questions
- How to best manage the moderation aspect
Appetite
Big - 2 cycles
Execution issues
- Mainly related to having streamlined discussions as we don't aim to start any development right now but align on the potential once more first
Decision log
Problem statement
Home Assistant currently models the smart home through a four-layer architecture. At the top sits the integration, which is the way a device is connected to Home Assistant like Philips Hue, Sonos, SwitchBot, Matter, and so on. An integration can expose one or many devices, each representing a distinct physical thing in the home. Each device in turn exposes one or many entities, which each carry a domain that defines what kind of thing the entity is, like light, climate, sensor, cover, and so on. Finally, some entities in more complex domains carry a device class that differentiates them further within that domain. A cover entity, for example, uses device class to distinguish between a shutter and a curtain.
To make this concrete: the SwitchBot integration (layer 1) exposes a device called "My Office Curtain" (layer 2), which has a cover entity with device class curtain (layer 3) and a sensor entity with device class battery (layer 4).
This model has served Home Assistant well for years and enabled enormous flexibility across thousands of integrations and device brands. However, as Home Assistant grows in ambition toward proactive automation suggestions, context-aware voice, auto-generated dashboards, and collective intelligence through the OHF Device Database, a gap becomes increasingly apparent: none of these four layers captures what a physical device actually is.
With this opportunity we want to revisit the topic of potentially introducing device types once more, both from a product but of course also from a technical perspective, weighting impact and trying to achieve a common ground to proceed in a consecutive step.
Please refer to this document for further discussion and feedback https://docs.google.com/document/d/1uYXLealUYy1IImR6N7l7EqyNzOMi0synqn3lpyYf9ng/edit?tab=t.0
Community signals
The case for device types is not only product reasoning. It is echoed in signals from the Home Assistant community itself.
Making Home Assistant more approachable is a stated core goal for 2026, framing it at the State of the Open Home as "lowering the floor without lowering the ceiling." Device types are a direct enabler of that goal: a platform that understands what a device is can guide new users through setup, surface relevant automations, and present a coherent interface without requiring expertise in domains and device classes.
Openhomefoundation
The 2025 Home Assistant roadmap named device understanding as a core architectural change, stating that knowing what devices are and how they are used is the foundational prerequisite for collective intelligence features including proactive automations, smarter dashboards, and improved voice.
Recurring forum activity around post-setup cleanup, including entity naming confusion, incorrect area assignments, and ambiguous entity lists, points consistently to the same root cause: the platform makes no meaningful first decisions at setup because it does not know what kind of device it is dealing with.
The "add device classes to lights" proposal in June 2025 was closed by explicitly deferring it to the device types work planned for later that year, acknowledging the team had discussed the problem multiple times without resolution because device classes alone are the wrong tool.
The architecture team declined the "add device class: heater to binary_sensor" proposal on the grounds that the problem it was trying to solve sits above the entity level, reinforcing the pattern that entity-level additions cannot substitute for a device-level identity concept.
A community member proposed a "traits" system in November 2025 to make the device object the primary layer for defining device identity, independently arriving at the same structural conclusion as the device types proposal and attracting immediate community support before being redirected to the architecture repository.
Scope & Boundaries
In scope
Not in scope
Foreseen solution
Risks & open questions
Risks
Open questions
Appetite
Big - 2 cycles
Execution issues
Decision log