Devices and Entities, What are they and how do they relate to each other

Configuration Frontend
,
1

There has been some major discussion and disagreement about a recent push to changing how entities are named in Home Assistant.

I have not been able to find a discussion thread that brings both sides of this argument together to try and find a solution or common ground.
It seems like the HA developers have decided to side with one group, and tensions are high.

The purpose of this thread:
This is not a place to paint each other as “wrong” or “stupid”. It is not a place to judge how one person sets up their home vs another. The spirit of Home Assistant has always been open source and open choice with the goal as to allowing people to setup their smart home how they seem fit.
This recent change or direction I feel limits that.

The discussion topic:
We are here to discuss “What is a device?”, “What is an entity?” and “How do they relate to one another?”
This is the point of contention, there are differing viewpoints on this. I feel like if we can agree on definitions for these things than we can possibly come to some kind of agreement.
The problem is, there is no “one size fits all” solution to this. Devices vary wildly, and I feel that trying to come up with a cookie cutter method is great for a “default” but not a “requirement”.

Lets get into it, here is how I answer those questions.

  1. What is a Device?
  • To me a device is the physical object that I installed or place in or on my home that interacts with Home Assistant.
  1. What is an entity?
  • An entity, is something created by a device for the purpose of giving me information about something around my home, or control over something in my home.
  • An entity falls into 3 major categories:
    1. Something that tells me about the device or environment around the device (sensor).
    2. Something that directly controls an aspect or function of the device itself. Such as a power button that turns the device that created it on or off.
    3. Something that controls an aspect or something other than the device that created it. Usually represents a part of the device designed to control or manipulate another object that is not part of the device itself.
  1. How do they relate to each other?
  • This depends on the purpose for the entity.
    • If the entity is there to tell me about the device that created it, or give information about the environment around the device. Then the entity belongs to that device. Such as a temperature reading.
    • If the entity is something that directly controls a part of the device itself, such as a “oscilation” setting on a smart fan which tells the smart fan to oscilate or not, then that entity belongs to the device.
    • If the entity is something that is designed to interact with another object or device, that is not a part of the device that created it, then that entity represents or belongs to the device it controls and not the device that created it.

Some Examples

  • A Physical Switch, that exists on the wall in the living room. When flipped it turns on the ceiling fan in the living room.

    • Device name: “Living Room Fan Switch”
      • Reasoning: I have 2 fans in my house. One in the living room, and one in the bedroom. Device names must be unique in Home Assistant. So, I can’t name both devices “Fan”. So I add the area name to the device name. (which is also as redundant of the device name showing up in the name of the sensor, yet this isn’t a point of contention, only the device name for some reason)
    • Area: “Living Room”
    • Entities:
      • Temperature sensor:
        • Entity Name: “Temperature”
          • Reasoning: This is the temperature of the physical switch.
        • Friendly Name: “Living Room Fan Switch Temperature”
        • Entity_id: sensor.living_room_fan_switch_temperature
        • Reasoning: The sensor gives data about the temperature of the physical switch device, so naming it after the device makes sense.
        • Switch Entity:
          • Entity Name/Friendly Name: “Living Room Fan”
          • Entity_id: switch.living_room_fan
          • Reasoning: The entity doesn’t control the switch itself, it controls the fan. (Setting the “Show as” setting to “Fan” simply creates another entity with the id of “fan.living_room_fan”.) If I name the entity this, then voice assistants already understand what I mean when I say “turn on the living room fan”. No alias is necessary. And if I set the “Show as” to fan, and allow the “fan.” entity to be created then “Turn on all living room fans” will also work. It just works, as is, by naming one entity. With the current plan, this entity would be forced to be called “Living Room Fan Switch” (if the entity_name was set to “none” and it adopted the name of the device that created it.) This… does not make sense when controlling devices with voice assitants. It also doesn’t make sense on dashboards. And if “Show as” is changed to “Fan” it would still be called “fan.living_room_fan_switch” which is also wrong since … I want it to be shown as a “Fan” not a switch. The argument could also be made that “Switch” in the name is redundant. “switch.living_room_fan_switch” could very easily be shortened to “switch.living_room_fan” so the name “Living Room Fam” makes perfect sense.

  • A contact sensor on the left window, in the living room.

    • Device Name: “Living Room Left Window”
      • Reasoning: This is what the device represents in my house. All the entities would automatically be named something that makes sense by the default naming convention. The argument could be made that this should be called “Living Room Left Window Sensor”. But again, “sensor.living_room_left_window_sensor” feels redundant. However, this point doesn’t really matter since this is the device name, and we are really discussing how the device name relates to the entity name, and what if any affect it should have on entities.
    • Area: Living Room
    • Entities:
      • Binary Sensor / Contact Sensor:
        • Entity Name: None integration doesn’t set one up.
          • Reasoning: This entity represents the core function of the device, and thus should get the same exact name of the device.
        • Friendly Name: Living Room Left Window
        • Entity ID: binary_sensor.living_room_left_window
      • Binary Sensor / Tamper Sensor:
        • Entity Name: “Tamper”
          • Reasoning: This entity represents another aspect of the device.
        • Friendly Name: Living Room Left Window Tamper
        • Entity ID: binary_sensor.living_room_left_window_tamper

Some points of commonality.
As you can see, because of each device/entity needing to have a unique name, the area ends up in the name already. So it makes sense that area be the first part of a name. (However “Left Living Room Window” seems just as valid as “Living Room Left Window”).
It makes more sense to describe an entity by it’s area rather than it’s device in some cases, especially cases where the entity is in a different area than the device that provides it.

For me an entity name is: “Area Name + Device the entity controls/gives info on + Entity Name”

So whether or not the name of the device providing the entity should be in the name of the entity entirely depends on the entity itself, and the purpose/function of the device.

Perhaps entities really need another attribute: “device_contained: True/False”.
A “Device contained” entity is an entity that controls or gives info about the device that provides it. An entity that is “Not device contained” controls another object or device.

Device Contained entities should have the device name, in their name. It makes sense because they are a part of the device. However a “not device contained” entity should be named after the Object/Device it actually controls.

A “Device Contained” or similar attribute solves the issue of entity naming without the complication of having to add “sub devices”.

2 Likes
2

Some helpful reading:

Personally, I think of entities as an abstraction of the thing I want to control or monitor, where as the device is more a container to group entities. I don’t want to turn on the device to do something, I want to turn on the thing the device controls. For me, there’s a weak bond between a device and an entity.

Devices can change.

It concerns me that the updates to the UI for building automations seemingly are adding device IDs as if they never change. That seems like building in future trouble.[1]

As I said in the beta thread, I think the name change is sound and makes sense, but there needs to be a better way to handle the impact of that change so there’s not a shitshow when the release finally happens.

[1] I rarely use the UI for building automations. I kind of assume (likely incorrectly) that as one’s automations and scripts become more complex that working in YAML is more likely.

3

Subdevices are already used since some time, and they are (also) a solution to the issue of one physical device controlling some devices that are in different areas.

For example a double light switch device controlling lights in 2 different rooms, or inside and outside.

See, this really isn’t as simple as “device is a physical object”, because the lightbulb is also a physical device, and on the other hand we have a lot of integrations providing virtual devices (called services, ok, but for the topic of making they are the same as devices, they are even called devices in the editing cards ui).

4

There are 2 problems with what is discussed by the July 2022 Naming Model “discussion”

  1. It isn’t a discussion. It is a “Here is how it is going to be from now on”. There is no discussion with the community.
  2. It assumes that the entity always controls the device that creates it. All the examples given are of entities that relate to the device they “belong” to.

Not a single example is given about a device that is designed to control something other than itself.

This is a direct quote from that post:

Entities in Home Assistant are the data points provided by a device and can represent specific controls (a switch of the device, a light of the device).

Right there… the “Of the device” is the problem. The assumption is made, that the switch “of the device” is controlling something about that device. When in reality 95% of switches are designed to control something other than the device.

The example of a “Switch” is perfect.
A “Switch” is not defined by what it is. They don’t sell “Light switches” at the store. They sell “Switches”. It becomes a light switch when it controls a light. It becomes a fan switch when it controls a fan.

Therefor it is defined by what it controls not what it is.

An entity is what we use to interact with the objects in our home. This is why in a lot of cases it should be named based on what it does not necessarily the device it is a part of.

It makes sense to name a device “what it is”. Because, that is the device. However, the entity is the interaction point. The entity is defined by what it does.

A smart fan that can itself interact with home assistant, it is an example where the device and the entities it creates are related. The entity, is controlling the device that created it. However, a “switch” that so happens to turn on a “dumb fan” is a different story. The entity created by that switch should be defined by what it is doing (that is the entire point of the “Show as fan” option).

A smart light bult, can itself interact with home assistant, it is another example where the device and the entities it creates (“light” entities) are related. The entity, is controlling the device that created it. However, a “Switch” that so happens to turn on a “dumb light bulb” is a different story. The entity created by that switch should be defined by what is is doing (that is the entire point of the “Show as light” option).

The fact that entities have a “Show as” option, proves that they are not always defined by their device. I would never set the “Power button/switch” of a smart fan to “Show as a light”. That makes no sense. Likewise I would never set the “light” entity of a smart bulb to show as a fan. However, a “Switch” entity is just a switch, if it controls a light I want it to “show as” a light. Clearly the entity is not a switch then, since it makes more sense to be seen as a “light”. In those cases, it shouldn’t be named after the entity that creates it, but rather the entity it controls.

1 Like
5

The problem is that is not the case.

I own an Aqara zigbee double pole light switch. The integration only brings in a single device that device has 2 switch entities.

The argument that “the lightbulb is also a physical device” is a great argument, and that is the very reason I rename the entity to match the device it actually controls.

So are you suggesting that we create the ability to add “Sub devices” to everything?

Now a new user has to create a “helper device” and assign it to their double pole light switch, and the ‘move’ the entity to the “helper device” (sub device), and then it will show up properly everywhere.

Or they can just rename the entity.

The “Top Switch” is physically attached to the “Double pole switch”, but it controls the “Lights” or the “Fan” or the “Space heater” or the “Enter whatever object I plug into the outlet the switch controls”.

The setup is much easier when these are the questions you are asking:
“What is this device” → " A switch".
“What is it controlling” → “The Lights”.

Done… simple, clean.

What is being suggested as the solution is this:
“What is the device” → “A switch”.
“What is the name of the device it controls” → “The lights”
But you now have to ask that question for every single entity the device provides. Rather than just defaulting it to the device, and allowing the user to rename only the ones they need too.

A “Service” is not the same thing as an entity.
I should not have to call a service to trigger a light switch, I tell the entity that represents the “Switch” to turn on.

There was a suggestion to add “Channels” to devices a while back, which is exactly what you are suggesting as “Sub devices” this was shot down by the devs. “Sub devices” as far as I know only exist within ESP devices, and are not a requirement for integrations.

Also, If I install a double pole light switch, should I expect 2 devices or 1?
Is each “Switch” on the double pole light switch a device? Then which of those devices does the “Temperature” sensor belong to?

6

Because this integration did not implement it. Others did, I know for sure Shelly did.

7

Then why is it not a requirement for them to be an integration?

Putting some of my non-helpful ranting in a spoiler to clean up the thread. This **forced** naming "convention" makes it so that my system doesn't work. And that is *not* my fault. However, because this is a *requirement* placed on the user now I can't make my system work without jumping through hoops.

Specifying on every single card how to display the name. Having to remember to setup an alias for my voice assistants. God forbid I move my smart surge protector that has 8 switch entities to a new room and have to rename them all.

8

I’m quite sure what Aron has is far more common.
All my double switching devices has one device with Multiple entities.
We have a one Zigbee double inwall switch, and the NS panel

9

Because it’s relatively new, but that I think it’s exactly the plan. I suspect now it will be more in focus to finish this before making them change.

10

My problem isn’t with Home Assistant automatically adding the device name.
My problem is that it is becoming a requirement. So in my case when it is not correct in the areas it doesn’t work I physically can not fix it.

Question or everyone:

If you have a smart switch in your living room.
And this smart switch controls the ceiling fan.
What do you name the smart switch “Device”?
Do you name it “Living Room Fan” (because we still have to add the area to the name since each name must be unique, I think solving that is far more of a problem solver than the device name).
Or do you name it “Living Room Switch 1” (hard to tell which switch i’m talking about)
Or do you name it “Living Room Fan Switch”?

What name do you give the switch?

1 Like
11

Yeah, sure, but we have a system that was designed for this specific use case. Instead of removing it before it was even adopted by everyone, and replacing it with something different, how about we try to finish the transition.

12

I get that sub devices would work, if every integration implemented them.

However I feel that they are entirely unnecessary and just add another “click” that I need to do in HA just to get to the entity.

If my double pole light switch adds 2 “Sub Devices” and the only entities on those sub devices are “switch” entities. THey might as well just be renamed switch entities on the main device.

Home assistant already has a “Show as” setting on the entities. So that I can “Show” the switch “as a light”. It actually creates another entity, with the “light” class and hides the original entity.

13

Ok, but you are reopening another topic, another decision that was already made and implemented, for the sake of what you think is a simpler solution. But how is it simpler? You would still need a way to assign entities of the same device to different areas.

I don’t want to be rude, but can you maybe try learning more before you make up your opinion? You are making wrong assumptions. My subdevice switch has 5 entities.

14

Let me add, that I get that “Friendly name” is not the same as “Entity Name”
And that I can still name my switch entity “Living Room Fan”.

And that the “Living Room Fan Switch Living Room Fan” is only a display name.
But that’s the problem. It is being said that I can still “name my entities whatever I want” however that is not what the system will show me.

I don’t change the name of something, to not see that name.

It’s also nice when what I see in google home “Living Room Fan” matches what I see in home assistant.

15

You can already do that with entities. Entities can be assigned to an area other than the area of their device.
I don’t need a sub device to assign the entity to a different area.

I get that your device has multiple entities for your sub devices that’s great. There are a lot of very simple smart switches out there that would not because they wouldn’t have a reason to assign multiple entities to the sub devices.

My aqara smart switch has a temperature sensor. Which would belong to the main device and a power sensor which belongs to the main device (it doesn’t show power for each switch individually) and it has a single “power outage recovery” mode, that again applies to both switches, not individualy.

So the only thing my smart switch would have on those sub devices would be the switch entities.

I get my frustration about having an “extra click” is a minor one, and who cares if the sub devices has 1 or 5 entities. Fine, but this is not yet in place, so the entity naming change can not happen yet.

Perhaps changing the “Show as” option on the entity to a “Make a sub device” feature. Where instead of changing the switch entity to a “fan” and it just makes a second entity, it could make the entity a sub devices with the “device class” of fan.

16

I really need to slow down and put everything in a single reply.
Sorry about that.

I would like to say. My Home Assistant setup has over 200 devices, and not a single one of them has a sub device.

I have aqara, third reality, shelly, esp and other devices.
Sub devices are rare.

In saying that, because none of my devices implement it, how do the sub devices work? I am genuinely curious as to what the setup is like.

For your double pole smart switch. When you setup the sub device for “Switch 1” do you get to tell it what device class to have? So can you say “this is a fan” and it properly makes the “switch” entity of that device a “fan” entity? Or do you still have to do the “Show as” feature?

17
Putting some of my non-helpful ranting in a spoiler to clean up the thread. Also, this was about the toggle that was removed from the roadmap.I have been digging into links provided on the github, where the discussions about roadmap and changes are happening.

Particularly this thread: Complete the entity naming migration · Issue #73 · home-assistant/roadmap

Under “Foreseen solution” Phase 1: Backend structured name API"
There is this comment:

This phase also includes adding the ability for users to edit the entity’s own name (entity.name ) through the entity registry, separate from the composed friendly_name . A flag (working name: “use as full name” or similar) allows entities whose names have been manually overridden to opt out of automatic device-name composition.

This right here, is the missing piece. When the developers kept saying “you will still be able to name it whatever you want” this flag was never mentioned.

If someone had told me “you can rename the entity and opt out of the automatic device-name composition” I probably would have been fine.

This flag isn’t mention on the blog post: Adopting a new way to name entities | Home Assistant Developer Docs

It wasn’t mentioned in the architecture discussion: Allow editing entity name instead of friendly name · home-assistant/architecture · Discussion #1185

and it wasn’t mentioned in the beta notes.

I think the problem was everyone kept telling us “you can still change the name” without telling us how that was being implemented. That is the break down in communication that has lead to this huge argument.

2 Likes
18

That was my first impression, too, but after reading things a few times more don’t think that’s the case.

Adding the flexible names really does give the freedom to format names in cards however you want – so you are not required to show the device names.

As a side note, I’m not so sure the flexible names on entities in cards is that necessary of a feature since you can just name it whatever in the card. Sure, it won’t automatically update if you change the name of the entity (or device/area), but how often does that really happen? Just go and update the name: on the card.

The big problem with the current 2026.4 beta was that at update time it was likely to change a lot of things and it’s a lot of work to go in an fix.

For some value of “community”, I’m sure that there was a lot of discussion. HA is open source but doesn’t mean every change need input from everyone, a consensus, or even any input since there’s a limited number of developers. I’m ok with that. As I mentioned, I have little interest in much of the focus lately on UI. I have my own list of things I think should be top priority!

I agree with your second point just in there’s a weak link between devices and entities for a number of reasons you point out. Conceptually, I think it’s best to think of controlling entities, not the devices that control those things. But, for some value of frequently, it’s probably a valid assumption.

Which makes it hard to pin down exactly what a device is.

19
Putting some of my non-helpful ranting in a spoiler to clean up the thread. This was talking about a toggle removed from the roadmap.I think that when this is finally implemented an entity who does not have the device name in them already, needs to automatically have the "flag" checked, and maybe be raised as an "Issue" to give us a checklist of things we may need to check on after the update.

I believe the notes were talking about checking to see if the device name existed so that it wouldn’t be duplicated when the name change was implemented:

A one-time automatic migration handles existing entities:

  • If your custom name already includes the device name as a prefix, the duplicate is stripped to avoid doubling.
  • If your custom name doesn’t match the device name, the previous full name is preserved as an Assist voice alias so your voice commands continue to work.

This right here.

I think instead of preserving the name as an Assist alias, it should just keep the name as is and check the “flag” to opt out of the automatic naming.

20

It will be interesting to see how that is handled. I think modifying user data is risky. Plus, it’s doing so by adding name_v2 into the registry which is messy. (Hey, look at the DB schema!)

The percentage of renamed entities that include the exact device name is probably not that large, so just make it a fix. And maybe strip the device name at runtime instead of stripping it in the registry.

1 Like