Native Entity Aliasing for Home Assistant — Hardware-independent logical entities for the entire smart home

[Popoboxxo]

Describe your idea

The Core Idea

Every device in a smart home has two identities: its physical identity (the hardware, the integration, the entity ID that HA assigns) and its logical identity (what it means in your home — the kitchen fridge, the living room light, the front door).

Today, Home Assistant only knows the physical identity. The moment you swap hardware, rename an integration, or migrate from one protocol to another, every automation, dashboard, utility meter, and the Energy Dashboard that referenced that entity breaks. Years of configuration need to be manually updated.

My proposal: Native Entity Aliasing — a first-class concept in Home Assistant where you define a stable logical entity that sits in front of any hardware entity. The logical entity never changes. The hardware behind it can change freely.

---

The Problem, Illustrated

You set up your living room light:

light.hue_color_candle_1  ← HA assigns this

You build 12 automations, 3 dashboard cards, 2 scenes around it. Two years later you migrate from Hue to WLED. HA assigns:

light.wled_living_room_strip_1

Everything breaks. Not because your home changed — the light is still in the same corner of the same room. But because Home Assistant has no concept of "the living room main light" as a stable identity separate from the hardware that implements it.

This problem exists across every domain:

Domain	Today (hardware-coupled)	What it should be
Light	light.hue_color_candle_1	light.living_room_main
Climate	climate.myVAILLANT_zone_1	climate.bedroom
Switch	switch.shelly_plus_plug_s_5a3c2b	switch.kitchen_fridge
Sensor	sensor.shelly_plus_plug_s_5a3c2b_energy	sensor.kitchen_fridge_total_energy
Binary Sensor	binary_sensor.zigbee_door_contact_3a2f	binary_sensor.front_door
Cover	cover.somfy_rts_1	cover.living_room_blinds

The logical entity is what your home means. The hardware entity is just the current implementation.

---

My Current Solution — Proof of Concept for Energy Sensors

I've been solving this manually for energy and power monitoring for over a year. I built a full Energy & Power Abstraction Layer in YAML that proves the concept works — but also shows exactly why it needs to be native.

Every physical smart plug in my setup gets exactly two template sensors that act as its stable logical interface. Nothing downstream — no dashboard, no utility meter, no automation, no Energy Dashboard entry — ever sees the raw hardware entity.

# packages/abstraction/energy_power.yaml

# YAML anchors for shared config — defined once, reused across all devices
sensor_defaults: &energy_style
  unit_of_measurement: kWh
  device_class: energy
  state_class: total_increasing
  icon: mdi:lightning-bolt

power_defaults: &power_style
  unit_of_measurement: W
  device_class: power
  state_class: measurement
  icon: mdi:flash

template:
  - sensor:
      - name: "Kitchen Fridge Total Energy"
        unique_id: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
        state: >
          {{ states('sensor.shelly_plus_plug_s_5a3c2b_energy') | float(0) }}
        availability: >
          {{ has_value('sensor.shelly_plus_plug_s_5a3c2b_energy') }}
        <<: *energy_style

      - name: "Kitchen Fridge Current Power"
        unique_id: "b2c3d4e5-f6a7-8901-bcde-f12345678901"
        state: >
          {{ states('sensor.shelly_plus_plug_s_5a3c2b_power') | float(0) }}
        availability: >
          {{ has_value('sensor.shelly_plus_plug_s_5a3c2b_power') }}
        <<: *power_style

utility_meter:
  kitchen_fridge_energy_count:
    source: sensor.kitchen_fridge_total_energy  # ← always the logical entity
    name: "Kitchen Fridge Energy Counter"
    unique_id: "c3d4e5f6-a7b8-9012-cdef-123456789012"

When I replace the Shelly with a Zigbee plug, I change one line. Every utility meter, Energy Dashboard entry, automation, and dashboard card continues to work without any modification.

---

The Bonus Problem: Spike-Proof Energy Monitoring

While running this pattern I discovered a second problem that the abstraction layer elegantly solves: some hardware energy sensors report wrong values.

Certain Zigbee and Tasmota plugs occasionally send a cumulative kWh value lower than the previous reading — a hardware glitch or reset. utility_meter has no defense: it counts every upward jump as real consumption and ignores downward corrections. Over time, phantom energy accumulates silently.

The physical reality: a cumulative energy counter can only increase. So I built a monotonic guard into the template sensor using this.state — the sensor's own previous rendered value:

state: >
  {% set new_val = states('sensor.shelly_plus_plug_s_5a3c2b_energy') | float(0) %}
  {% set old_val = this.state | float(0) %}
  {# Energy physically can only go up — downward jumps are hardware glitches #}
  {% if new_val >= old_val %}
    {{ new_val }}
  {% else %}
    {{ old_val }}
  {% endif %}

It works perfectly. But this is complex Jinja2 that encodes a simple physical law — it should never need to exist in user config.

---

The Vision — What Native Entity Aliasing Could Look Like

Taking the energy pattern and generalizing it to all of Home Assistant:

# Hypothetical native syntax — logical entity definitions
alias:
  light.living_room_main:
    source: light.hue_color_candle_1
    name: "Living Room Main Light"

  climate.bedroom:
    source: climate.myVAILLANT_zone_1
    name: "Bedroom Thermostat"

  binary_sensor.front_door:
    source: binary_sensor.zigbee_door_contact_3a2f
    name: "Front Door"

  sensor.kitchen_fridge_total_energy:
    source: sensor.shelly_plus_plug_s_5a3c2b_energy
    name: "Kitchen Fridge Total Energy"
    monotonic: true   # for total_increasing sensors: refuse downward jumps

Or even better — directly in the Entity Registry UI:

• Open any entity
• Click "Create logical alias"
• Assign a stable ID and name
• All existing references to the alias survive any hardware change

The source changes. The alias stays. Everything downstream is unaffected.

Why is this exciting?

Hardware independence is one of HA's core promises — but right now, the moment you swap a device, you're manually hunting through automations, dashboards, utility meters, and the Energy Dashboard to update references. The more mature your setup, the more painful every hardware migration becomes. Power users with hundreds of entities are essentially locked into their hardware choices.

The Adapter Pattern — putting a stable interface in front of an unstable implementation — is one of the most proven concepts in software engineering. Industrial automation systems call this a "virtual sensor" or "process data object": the control logic never talks to physical hardware directly, always through a normalized data layer. Home Assistant users are rebuilding this manually, in Jinja2 and template sensors, in every installation. That's a signal it belongs in the core.

The monotonic guard for energy sensors is particularly exciting because it encodes physical reality into the data pipeline. Electricity consumption is monotonically increasing by definition. Building that constraint natively into utility_meter or an alias platform would silently fix a class of phantom consumption bugs that many users don't even know they have.

And beyond the technical: a logical entity layer makes Home Assistant dramatically more approachable for new users. Instead of sensor.shelly_plus_plug_s_5a3c2b_energy appearing in automations and dashboards, they see sensor.kitchen_fridge_total_energy. The configuration becomes readable. The home becomes self-documenting.

Potential use cases

• Hardware migration without data loss: Replace any device, keep all Energy Dashboard history, automations, utility meters, and dashboards intact — change one config line
• Integration renames: When a major HA release renames integration entity IDs (it happens), re-point one alias instead of hunting through everything
• Protocol migrations: Zigbee → Z-Wave → WiFi → Matter — the logical layer absorbs the change
• Blueprint portability: Blueprints that reference logical aliases instead of hardware IDs become truly hardware-agnostic and shareable across installations
• Phantom energy prevention: The monotonic guard on total_increasing sensors silently protects against a widespread hardware bug class
• Self-documenting configs: Semantic entity IDs everywhere — automations, logs, and dashboards become readable without knowing your hardware topology
• Multi-device aggregation: A logical entity can represent a sum or average of multiple hardware sources — swap any source without touching downstream config
• Cleaner Entity Registry: Group, alias, and organize your entity namespace to reflect your home's layout, not your hardware's naming conventions

Anything else?

I've been running the energy abstraction pattern across ~100 devices for over 2 years.

The this.state monotonic trick is, as far as I know, largely undocumented in official HA docs. It exploits the fact that Jinja2 template sensors can reference their own last rendered state — enabling stateful filtering without helpers or automations. It works, but it's the kind of clever hack that signals a missing native feature.

Note: I used AI (Claude) to help structure and articulate this discussion post. The underlying concept, the YAML implementation, and the year of real-world experience running it are entirely my own — the AI helped me turn a complex personal architecture decision into a readable proposal.