I want to share some thoughts about how the relationship between attributes, entites and devices could be evolved further and especially hear from you if this is in-line with the Home Assistant roadmap.
The current Home Assistant structure often forces complex physical items (like robot vacuums, advanced climate systems, or irrigation controllers) into monolithic entity domains (vacuum, climate, etc). This conflation of physical device, specific capabilities, and transient state creates friction for developers and users alike.
The primary goal of this proposal is to enforce a stricter separation of concerns, improving automation reliability and standardization.
1. Defining Roles: Device Holds Capability, Entity Holds State
We need to formalize the distinction between a Device and its Entities.
A. The Device: Container for Capabilities (Traits)
The Device object should become the primary layer for defining the complex capabilities, or Traits, of a piece of hardware.
- Complex Traits are Appropriate for Devices: It is acceptable for a Device to identify itself using high-level concepts (e.g.,
Device Implements Trait: Lawn MowerorTrait: Zonal Vacuum). These terms provide semantic meaning for discovery, grouping, and high-level integrations (like Google Assistant or Amazon Alexa). - Trait as a Blueprint: A complex Trait acts as an interface that guarantees the presence of a standardized set of Atomic Entities and required Device Services.
B. The Entity: Constraint to Atomic State
The Entity layer must be aggressively streamlined to adhere to the Single Responsibility Principle. An Entity should represent one single, measurable, or controllable thing.
- Atomic State: Any value that is variable or represents transient status must be promoted to its own dedicated entity.
- Instead of:
vacuum.robotattributebattery_level: 15 - We should use:
sensor.robot_battery_level(state: 15) - Instead of:
climate.thermostatattributehvac_action: cooling - We should use:
select.hvac_action(state: cooling)
- Instead of:
- Attributes Must Be Static: For stability, Entity attributes should be strictly limited to non-variable, static metadata that rarely or never changes, such as
firmware_version, value range, constraints, or static configuration flags. Moving all variable state out of attributes dramatically simplifies automation triggers and templates. (This echoes long-standing concerns about breaking automations due to attribute changes—a common topic indevsdiscussions).
2. Improved UI & The Managed Dashboard Approach
This architectural separation is essential for creating robust, maintainable UIs that feel consistent across different vendors.
A. Managed Device UI Generation
The default view for a complex Device should be generated similarly to a Managed Dashboard.
- Platform Assembly: When a user adds a Device Card (or views the Device details), the platform looks up the Device’s Traits (e.g.,
Dockable,Battery Powered,Zonal Clean). - Atomic Component Mapping: The platform then automatically assembles a grouped card from the simple, atomic entities linked to those Traits (e.g., a standard
button-cardforbutton.robot_dock, a standardgauge-cardforsensor.robot_battery_level). - Standardized Elements: Because the UI is only dealing with simple entity types (sensor, switch, button), the visual components are standardized, ensuring consistency and ease of maintenance across the entire HA frontend.
B. User Control (Unmanaged Conversion)
To provide the flexibility of a customizable dashboard, the Device UI should allow the user to “Take Control” or “Convert to Custom Card.”
- Conversion: Clicking this option immediately converts the auto-generated, managed card layout into a static, user-controlled (unmanaged) YAML or Visual Editor layout.
- Customization: The user is then free to rearrange, hide, or replace the constituent atomic entities (
button.robot_dock,sensor.robot_battery_level, etc.) using any available standard HA card type.
This approach balances the need for zero-configuration, vendor-agnostic default UIs with the HA community’s strong desire for complete customization, addressing the complexity issues that have plagued large, custom domain cards (see discussions related to Managed Dashboard parity).
3. The Transition Strategy: Coexistence and Phased Deprecation
Implementing this change requires a deliberate and non-breaking transition phase to ensure compatibility with existing automations, dashboards, and custom cards. User-defined setups must not be broken during this migration.
Conditional Implementation Phase
Integrations implementing this new model will expose new Atomic Entities and define Device Traits alongside the existing monolithic entity for the duration of the transition.
- Existing Integrations: Integrations would continue to register the monolithic entity (e.g.,
vacuum.robot) but should simultaneously register all the new Atomic Entities (sensor.robot_battery,button.robot_dock, etc.) and define the Device Traits. The existing capabilities must remain functional throughout this period. - Core Platform Support: The core platform will maintain services and UI compatibility layers for existing monolithic entities, even as it starts prioritizing the new Device-centric APIs.
The Deprecation Path
The existing monolithic entities (e.g., vacuum.robot, climate.thermostat) should be immediately marked as deprecated once the Atomic Entities are available.
- Removal Timeline: The monolithic domains must not be removed until a clearly defined future major release (e.g., HA 2027.x.0), allowing a minimum of 12-18 months for the community and custom card developers to migrate their dependencies.
- User Notification: When a user interacts with a deprecated monolithic entity in the UI or automation editor, they should see clear warnings and guidance on migrating to the new Atomic Entities and Device Services.
4. Further Discussion Points
This shift provides clearer boundaries for integration development and greater stability for user automations. The key constraint is ensuring that all variable data is properly promoted to its own entity type.