Sub-devices: a first-class parent/child device relationship

[frenck]

Alright, before you dive into this I just wanted to say this similar topics have been discussed many times before. I've taken into account MANY of the historical architectural discussions, issues, historical PRs, meeting minutes, everything I could find.

I seek to provide a complete architectural change to help moving forward problems recently raised, and hopefully coming up with something that provides a meaningful path forward.

This is a long one, but please read it and hear me out.

../Frenck

Background

A lot of physical devices are really several logical devices in one box. A smart power strip is one product, but each outlet switches independently and often measures its own energy. A multi-gang wall switch is one product, but each channel can control lights in a different room. An ESP board or RF bridge can drive things spread across the whole house.

We already split these into sub-devices, and it's the documented, recommended approach. From the [developer documentation](https://developers.home-assistant.io/docs/device_registry_index#what-is-a-device):

A device that offers multiple endpoints, may be split into separate devices and refer back to a parent device with the via_device attribute. This allows the separate endpoints to be assigned to different areas in the building and it also allows logical grouping of entities. Typical examples of when a device should be split in a parent device and multiple child devices are smart power strips or smart multi-gang wall switches. The parent device will have entities representing the state of the power strip or multi-gang switch, for example network connection status and firmware update. The sub devices will group entities tied to one of the channels, for example a switch entity and energy consumption sensor per channel.

This is what [#1036](#1036) accepted in principle, and integrations already do it. ESPHome, for instance, ships sub-devices today.

The catch is the field we use to express it. via_device is doing double duty. Its original and primary job is connectivity (how does Home Assistant reach this device?) for hubs and radios; it literally started life as hub_device_id (ZHA sets it for everything behind the coordinator stick, for instance). We're now also using that exact same field for a parent/child relationship: "this device is a part of that physical device." One pointer, two unrelated meanings.

That overload is the actual problem this proposal fixes: give the parent/child relationship its own place in the device model, and let via_device go back to meaning only connectivity.

What a sub-device is (and isn't)

Let's be precise, because the whole proposal hinges on it.

A sub-device is a virtual device split out of a single physical device. One physical product, subdivided into logical parts. The power strip is the physical device; its outlets are sub-devices. The multi-gang switch is the physical device; its channels are sub-devices. There's usually no separate radio involved. The split is logical, so each part gets its own identity, area, name, and grouped entities.

That is not the same as via_device. via_device answers a different question: how does Home Assistant reach this device? It's connectivity. The two ends of a via_device link are separate physical products, one acting as a gateway for the other:

• A Zigbee bulb reached via the ZHA coordinator (the USB stick). ZHA already sets this for every device behind the coordinator.
• A Hue lamp via the Hue bridge, a Z-Wave node via the controller, an Ecowitt sensor via its Wi-Fi hub.
• A BLE sensor seen through a Bluetooth proxy. Notably, we deliberately don't set via_device here, because a device roams between proxies and the relationship isn't a stable parent at all.

So a hub is not a parent of the devices behind it. Those are independent products it provides connectivity to. A power strip is a parent of its outlets. These are two different relationships, and we've been overloading one field to mean both.

The cost of the overload is concrete: the frontend can't tell "connected via X (a gateway)" from "part of X (one physical device)", the existing copy ("Connected via" / "Connected devices") reads wrong for sub-devices, deletion semantics are ambiguous (orphaning a child makes sense for a gateway, not for a sub-device that can't exist without its physical parent), and there's no clean place to inherit an area, or to give a true child proper ownership and lifecycle.

Proposal

Give sub-devices their own dedicated place in the device registry, separate from via_device.

Data model

A sub-device is registered as a dedicated, lightweight sub-device object, not as a full device entry that happens to point at a parent. It carries only what a logical part actually needs: a link to its parent, a name, and an optional area override. It deliberately does not carry connectivity (via_device, connections), a MAC address, or firmware, because those belong to the physical parent, not to an abstraction.

This is the direction we landed on in the architecture meeting: a separate class, ChildDeviceInfo, reads cleaner for integrations and removes the need for merge checks and inapplicable fields during loading. It's still provided the normal way, through an entity's device_info, which accepts either a DeviceInfo or a ChildDeviceInfo. So integrations don't learn a new mechanism, they just use a lighter shape for the parts. Whether it ends up as a separate class or a flag on the existing DeviceInfo is still being finalized, but the shape is the same: a minimal sub-device that references one parent.

A few rules fall straight out of that:

• One parent, referenced by identifier. A child has at most one parent. On the input side, the integration sets parent_device on the ChildDeviceInfo: the parent's identifier. The registry resolves that into a stored parent_device_id on the device entry, exactly like via_device resolves to via_device_id today. Because a sub-device is always created by the same integration as its parent (one physical product split up, not two products linked), the reference only needs the identifier. It does not need the (domain, identifier) tuple that via_device uses to reach across integrations.
• The parent must already exist. The registry does not auto-create a parent from a child's reference. The integration is responsible for creating the parent first, then the sub-devices. This avoids the chicken-and-egg problem during device creation and prevents empty or half-formed parent entries.
• Tied to the parent's config entry. A sub-device lives on the same config entry as its parent and does not get its own. This also relates to the "single config entry per device" discussion ([#1226](Make device identifiers and connections unique per config entry instead of globally unique #1226)).
• No connectivity of its own. A sub-device has no via_device and no connections. It's an abstraction; the connectivity is the physical parent's. via_device stays for real connectivity between separate physical devices (hubs, radios, proxies) and never appears on a sub-device. This is what finally un-overloads via_device: the parent/child link lives in its own construct, so via_device goes back to meaning only "how do we reach this device."

Since almost no integrations read directly from the device registry, exposing this new relationship through the read and websocket APIs is acceptable; the main impact is on those APIs and on migration.

Terminology is still open. In the meeting "child device" came up as possibly more accurate than "sub-device," "device part," or "sibling," and there's a small naming question for the parent reference too (parent_device vs part_of). I use "sub-device" throughout this document for consistency, but I'm happy to settle the final term.

Depth and cardinality

Keep it to a single level: a device has at most one parent, and a sub-device cannot itself be a parent. No grandchildren, no arbitrary trees.

This isn't laziness, it's a deliberate constraint. Arbitrary nesting multiplies the entity-naming choices (see naming below; every level adds another "include the parent name?" decision), the UI rendering, and the lifecycle rules, for use cases we don't actually have. A power strip with outlets is one level. If a real two-level case shows up later, we can revisit, but we shouldn't pay for it now.

Lifecycle

A sub-device is owned by its physical parent. That ownership has consequences:

• Delete cascades. Deleting the parent deletes its sub-devices. This is the big difference from via_device, where deleting the parent only resets the children's pointer to None (orphaning them). A sub-device has no meaning without the physical device it was split from, so it goes with it.
• Disable cascades. Disabling the parent disables its sub-devices.
• Reparenting is strictly integration-managed. The integration that created the devices owns the structure. There is no core mechanism and no user-facing mechanism to change parent/child links: a user cannot drag a sub-device to a different parent in the UI. If the structure needs to change, the integration re-creates it. This is a firm boundary, not a "for now."

Inheritance

Sub-devices inherit exactly one thing from their parent: area. Everything else is set on the sub-device itself.

• Area is inherited, and overridable. A power strip in the garage puts all outlets in the garage by default; the one outlet feeding the garden lamp can be overridden to the garden. This mirrors how an entity inherits its area from its device today (inherited unless explicitly set), and it's the clean answer to the area-vs-device problem Modelling devices with sub-devices #1036 flagged.
• Labels are not inherited. Entities don't inherit labels from their device today either, and inherited labels are confusing to reason about: if a sub-device picked up a christmas label from its parent, how would you clear just that one on the child? Labels stay explicit per device.
• Name is not inherited. Each sub-device has its own name; that's the whole point. There is no name inheritance and no "inherit vs override" for the name. A sub-device is named individually, full stop. (Whether the display name shows the parent's name too is a separate, presentation-only choice, covered under entity naming.)

Disabled state isn't an inherited value either; it's a hard cascade (see lifecycle). And devices have no state or availability in Home Assistant, so there's nothing of that kind to inherit.

Entity naming

Sub-devices fix entity naming with zero changes to the naming rules, because the rules already key off the device. Initial entity_id generation is based on the area, device, and entity names, and once a channel is a sub-device, the device part is simply the sub-device's name. This is exactly why #1036 preferred real sub-devices over a "drop the prefix" opt-out, and it still holds.

The same applies to display names. Home Assistant is moving away from the pre-composed friendly_name toward composing the display name from structured parts (area, device, entity). A sub-device slots straight into that as the device-level part, so the displayed name comes out right without special-casing.

One thing sub-devices add here is purely a display choice: whether to include the parent device's name when showing the entity. For a "Server Rack PDU" with an "Outlet 3" sub-device, one user wants "Outlet 3 Power" and another wants "Server Rack PDU Outlet 3 Power". That's a per-context toggle in how the name is composed for display. It is not name inheritance in the registry: the sub-device's stored name stays "Outlet 3" either way. It's also a real reason to keep depth at one level, because every extra level multiplies these composition choices.

This couples the proposal to the entity-naming work ([roadmap #73](OpenHomeFoundation/roadmap#73)). For a sub-device rename to flow through to its entities correctly and locale-safely, we need the structured-name backend (its Phase 1) and a resolution to [#1185](#1185) (renaming an entity should set entity.name, not the old friendly_name). The sub-device model should be specified against that work, not assume it's already done.

Targeting in automations and actions

Because the parent/child link is now a real relationship, the parent device becomes a meaningful automation/action target. "Turn off the power strip" should expand the parent to its sub-devices' entities, slotting in as a natural level below the existing floor, area, device, entity hierarchy, and showing up in the target picker.

Today this does not happen: target expansion (homeassistant/helpers/target.py) maps a device_id only to entities directly on that device, and never follows via_device. The crucial design rule: cascade follows the parent/child edge, never via_device. You want "target the power strip, hit all outlets"; you absolutely do not want "target the Zigbee coordinator, actuate every Zigbee device" or "target the Bluetooth proxy, hit everything it can see." This is, on its own, one of the strongest reasons to keep the parent/child relationship separate from connectivity.

Frontend

Two distinct representations, because they're two distinct relationships:

• Parent/child: the parent device page shows its sub-devices and their key entities/state inline (this is what [frontend #52512](Show sub-devices and entity features on the parent device page frontend#52512) is asking for: with a Zigbee power strip you shouldn't have to open each plug's page to see its state). Render it as a nested/grouped view of "parts of this device."
• Connectivity: via_device keeps its existing "Connected via" / "Connected devices" treatment, ideally as a separate network/diagnostics view. Copy should clearly distinguish "part of X" from "connected via X."

The parent device page is just one surface. The devices overview page is another: the devices data table could, for example, show sub-devices nested under their parent rather than as loose rows. Exactly how to present that (here and elsewhere) is for the UX designers to work out; the point for this proposal is that a real parent/child relationship in the registry is what makes any of these views possible.

The frontend work is also the current practical blocker. Splitting has stalled before precisely because the UI needs to represent links between related devices cleanly, so this is a design challenge to take on, not a core-functionality gap.

Integrations that benefit today

This isn't theoretical. Concrete candidates that would benefit right away:

• Power strips with per-outlet switching and energy: TP-Link Kasa, Zooz ZEN, Shelly EM/Pro multi-channel, Zigbee strips via ZHA or Zigbee2MQTT.
• Multi-gang and multi-channel switches: Shelly 2/2.5, Sonoff 4CH, KNX.
• Devices already doing ad-hoc sub-devices: Reolink (NVR, camera, chime), ESPHome.
• Energy sub-metering: a single meter exposing multiple circuits or channels.

The already-split ones (ESPHome, Reolink, Shelly) are the lowest-risk early adopters, since they've already accepted separate devices for the parts. Whether their existing device_ids carry over unchanged depends on how we migrate them to the new sub-device object (see migration).

Migration: the part that actually decides whether this ships

The hard problem isn't the data model, it's that splitting a device into sub-devices moves entities onto new sub-device objects, which changes their device_id and breaks every automation and script that uses device triggers or device actions, most painfully device triggers for remotes. This is the blocker the OHF Protocols team flagged, and the proposal has to answer it head-on. In the meeting we agreed the direction (a dedicated sub-device class), but left the exact migration mechanism for further discussion; this section is where that work lands.

There are two very different cases:

• Already split (the minority). A handful of integrations already split into sub-devices using via_device: ESPHome, Shelly, Reolink, Zigbee2MQTT. Their sub-devices already exist as separate device entries, so they're the lowest-risk group. Whether we can preserve their existing device_ids when converting them to the new sub-device object is a key migration question; if we can, these integrations move over with no breakage and gain area inheritance for free.
• Not split yet (the common case). Most integrations have done no sub-device work at all, not even the documented via_device way. They're one flat device. When they split, entities move to new sub-device objects and their device_id changes. This is where automations break, and since it's the common case, the breakage is broad, not narrow.

The one thing that softens it: splitting is opt-in and gradual. It lands integration by integration, as each one chooses to adopt sub-devices, not in a single big migration.

The mechanism I'd lead with is a device_id redirect. When an integration splits, keep a mapping from the old (parent) device_id to the new sub-device, and resolve old device references in triggers and actions through it, so existing automations keep working without the user touching anything. Automatically rewriting hand-written configuration.yaml is not viable: we can't preserve comments and formatting, so a rewrite would mangle the user's file. UI-managed automations (stored in .storage) could in principle be migrated, but the redirect covers both cases and is far less risky.

One more migration task: some integrations that already split embed the parent name in the sub-device name (Reolink, for example). Those should drop the prefix, so the sub-device is named "Outlet 3", not "Power strip Outlet 3".

There are also sequencing dependencies. via_device itself is untouched: ZHA keeps using it for the coordinator link, exactly as today. The dependency only applies if we split a ZHA device such as a remote into sub-devices by endpoint, which interacts badly with ZHA still using device triggers rather than event entities. That kind of split wants the event-entities-for-remotes work ([#1377](#1377)) and the event.received trigger out of HA Labs first. And there's an agreed interim stop-gap: a number suffix for duplicated entities, like Matter already does ([core #168901](home-assistant/core#168901)), to improve the UX today while this lands and to be removed once it does.

Open questions

1. Terminology: "sub-device" vs "child device" vs "device part", and the parent-reference naming (parent_device vs part_of).
2. Class vs field: a dedicated sub-device class (ChildDeviceInfo) versus a flag on the existing DeviceInfo. Direction is the separate class; the exact form is being finalized.
3. Firmware and version on sub-devices: some devices (EV chargers, multi-chipset boards) have parts with distinct firmware. Today Shelly and ESPHome assign no firmware or MAC to sub-devices. Do we keep sub-devices firmware-free for now and add optional per-sub-device firmware later if a real need shows up?
4. Config entry: a sub-device is tied to its parent's config entry and gets none of its own. Confirm this against the single config entry per device discussion ([#1226](Make device identifiers and connections unique per config entry instead of globally unique #1226)).
5. Migration mechanism: the exact scope of the device_id redirect, whether already-split integrations keep their existing device_ids, and whether migration runs automatically when an integration opts in.

Why this is worth it

Sub-devices give us logical grouping, clean names, per-sub-device areas with sane inheritance, a parent that's a real automation target, and a frontend that finally shows a power strip as a power strip. Most of that is only cleanly achievable once the parent/child relationship exists in its own right. The overloaded via_device can't do inheritance or safe targeting without doing the wrong thing for hubs and radios. And it's a foundational piece of "devices in context": before Home Assistant can treat a bundle of entities as a fridge or a car, it needs to actually model what's part of what.

---

For whomever is interested, here is a full research done with AI, with tons of history and references that have really helped me land this proposal.

https://docs.google.com/document/d/14hnKDhOrOGddepo_pOatEo0XsWbuqevVJz-9RnUbf-U/edit?tab=t.0

---

Changelog

• 2026-06-17: initial proposal.
• 2026-06-18: revised after the first round of feedback on the discussion.
  • Data model: clarified that a parent device is also a connection, so via_device is auto-derived from parent_device. Corrected the earlier claim that the two fields are independent. (Superseded by the 2026-07-02 direction below.)
  • Inheritance: dropped label inheritance; sub-devices now inherit area only.
  • Migration: reframed around two cases (already split vs not split yet, the latter being the common case), committed to a device_id redirect as the viable mechanism, and ruled out rewriting hand-written YAML. Added a task to drop parent-name prefixes from sub-device names (for example, Reolink).
  • Added an "Integrations that benefit today" section.
  • Clarified that ZHA's via_device coordinator link is unaffected; the event-entity dependency only applies to devices we would split into sub-devices.
• 2026-07-02: revised after the 2026-06-25 architecture meeting.
  • Direction shift: a sub-device is now a dedicated, lightweight object (separate class leaning), not a normal device entry that carries a parent_device field. It has no connectivity, MAC, or firmware of its own. Removed the earlier auto-derived via_device framing: a sub-device is an abstraction, so it simply has no via_device, and that is what un-overloads the field. The exact class-vs-field form is deferred to a follow-up.
  • Made "the parent must already exist" explicit: integrations create the parent first, no auto-creation, parent referenced by identifier.
  • Strengthened reparenting: strictly integration-managed, with no core or user-facing mechanism.
  • Fixed the name-inheritance contradiction: only area is inherited; name is always set individually. Clarified that the "include the parent name" toggle is display-only, not name inheritance.
  • Tied a sub-device to its parent's config entry (no own config entry); linked the config entry open question to Make device identifiers and connections unique per config entry instead of globally unique #1226.
  • Reworked open questions: terminology, class vs field, per-sub-device firmware, config entry (Make device identifiers and connections unique per config entry instead of globally unique #1226), migration scope. Dropped the device-merge question.
• 2026-07-02: named the sub-device class ChildDeviceInfo, and noted it is still provided through an entity's device_info, which accepts either a DeviceInfo or a ChildDeviceInfo.

[balloob]

Yes, this is a good idea.

Some notes:

1. inherit labels: not sure if I would agree with that. Especially because how does one "clear labels of sub-device to restore inheritance". Like, I inherit "christmas" from parent, how do you clear it? confusing to reason about, probably shouldn't.
2. ZHA is given as example that still uses device trigger as a problem, however I expect ZHA to stick with via_device, as that's the new single purpose of why via_device exists (to track communicating via the ZHA stick)
3. Do we have a list of integrations we would consider migrating today and benefit from this?
4. I actually wonder how many device IDs are going to change. Today they use via_device, tomorrow parent_device. In both cases it is an independent device. The only big difference is area inheritance.

[BradleyFord]

Regarding item 3

Refoss is a good example.
For example their EM16 monitors the power for 16 breakers, but at the moment they are all situated in my "Electrical Room", but logically the device is in the electrical room, but the individual sensors are about specific rooms in my house.
(At the moment I use the function to assign the entity to a different area, which upon reflection looks like a temporary hack, compared to what Frenck is considering)

Shelly
I have many that control lights in 2 different rooms, for example my garage and my passage.

I have some others but they are non-core

[balloob]

So Refoss should today already have used via_device, as Shelly already does:

That solves your exact problem. And then migrate to this proposal once implemented.

The reason this proposal exists is that we currently allow devices like Shelly to "abuse" the via device system, and we want to formalize that it's an actual part of the Shelly device, not a paired device that communicates via something else.

[frenck]

Thanks for the feedback @balloob

inherit labels: not sure if I would agree with that. Especially because how does one "clear labels of sub-device to restore inheritance". Like, I inherit "christmas" from parent, how do you clear it? confusing to reason about, probably shouldn't.

Agreed! That is an honest mis from my end; especially considering I implemented the labels in the first place 🙈

ZHA is given as example that still uses device trigger as a problem, however I expect ZHA to stick with via_device, as that's the new single purpose of why via_device exists (to track communicating via the ZHA stick)

Yes, device trigger are separated from this. I agree. Maybe it was unclear from the proposal, but I expect it to implement both. The via_device shows connections (as today), e.g., radio connections and general graph of how everything is connected. I propose parent_device to make a relationship between a physical device (e.g., power strip) and its child devices (e.g., the sockets of the power strip). The first (via_device) is a huge graph across Home Assistant, the latter is a smaller physical scope.

Do we have a list of integrations we would consider migrating today and benefit from this?

Basically any integration. But this is aimed at all the open protocols (Zigbee, Matter, Z-Wave JS), also ESPHome, MQTT, Tuya, Shelly, Philips Hue, and any other integration provide power strips, wall modules with multiple outputs and a-like.

I actually wonder how many device IDs are going to change. Today they use via_device, tomorrow parent_device. In both cases it is an independent device. The only big difference is area inheritance.

I think a lot. ZHA, Matter & Z-Wave, currently all are not follow the original standards we set out (see background as we currently have in the developer docs), for a good reason. Introducing new subdevices and moving the data/control points (entities) around, will cause a change in device ID. This needs to be tracked and mapped in order to keep existing device-base-automations working (which is the biggest reason why they never improved/picked up in the first place).

A bigger driver here is entity naming though. Right now, we have to do "switch 1", "switch 2" or things like "socket 1", "socket 2" in all these platforms and it becomes even messier when energy monitoring is involved.

This proposal is aimed to help with all of that.

Today they use via_device, tomorrow parent_device.

This actually highlights the unclarity for me. It is not one or the other. It is both (in most cases) :)

../Frenck

[frenck]

Updated the proposal above based on the feedback; also added a changelog.

[Markus98]

Love it!

I notice that the proposal suggests that we do device naming as "Socket 1" rather than embedding the parent device name like "Power strip Socket 1". This is good, but there are integrations today that implement sub-devices that do not follow this naming scheme and add the parent device name to the sub-device name. This should likely be then tracked as one of the dev migration tasks for this proposal. One example that comes to mind that I worked on recently is the Reolink integration but I am sure that there are more.

Initial entity_id generation is based on the area, device, and entity names, and once a channel is a sub-device, the device part is simply the sub-device's name.

This also needs to be taken into account, since if we omit the parent device name from the entity_id generation, we might end up with conflicting entity ids for similar sub-devices from different manufacturers. For example, "Brand power strip" > "Socket 1" and "Second Brand power strip" > "Socket 1" will have overlapping entity ids for the "Socket 1" sub-device. Something like kitchen_socket_1_switch. One can argue that the area name might be enough of a differentiator, but we should consider whether we want to include the parent device name in the entity_id.

This also raises the question that if we use the new toggle to include the parent device name in the sub-device entity names, should that also affect the entity_id?

Migrate YAML automatically. Rewrite device references on migration. More invasive and riskier.

Have we ever done migrations on configuration.yaml directly (not the automations created via the UI)? If we were to do that, we would need to preserve formatting and comments, which I presume is not really possible with the current libraries we use (yamlrocks when? 👀). Doesn't this fact automatically rule out this option?

To contribute to the bikeshedding, I think parent_device is good and disambiguous.

[frenck]

I notice that the proposal suggests that we do device naming as "Socket 1" rather than embedding the parent device name like "Power strip Socket 1". This is good, but there are integrations today that implement sub-devices that do not follow this naming scheme and add the parent device name to the sub-device name.

Yeah because right now... that is the only solution to make them distint in a single device that actually has, for example, multiple sockets. This is where Entity Naming current has an issue, as this forces a users to rename all entities again, which is exactly what we aimed to solve with entity naming.

This also needs to be taken into account, since if we omit the parent device name from the entity_id generation, we might end up with conflicting entity ids for similar sub-devices from different manufacturers.

That has always been an risk from the day Home Assistant spawned. There is logic to guard that. Entity IDs will have collisions and they are already handled today.

This also raises the question that if we use the new toggle to include the parent device name in the sub-device entity names, should that also affect the entity_id?

I don't understand this relation ship. The whole point of the entity ID mention in the above text, is that nothing changes. The parent device has no part in the entity ID.

Have we ever done migrations on configuration.yaml directly (not the automations created via the UI)?

No we can't, because of many issues with it... and yes, it was one of the thoughts/reasons behind YAMLRocks indeed. Someday 😉

../Frenck

[Markus98]

I don't understand this relation ship. The whole point of the entity ID mention in the above text, is that nothing changes. The parent device has no part in the entity ID.

I mainly mentioned these things to make sure that they have been considered in the proposal, and based on your response they have been. It's a good point that entity ID conflicts will always happen anyways and there is already graceful handling for it.

One addition thing I noticed that might be useful to specify in the proposal:

One thing sub-devices add here: a user choice about whether to include the parent device's name. For a "Server Rack PDU" with an "Outlet 3" sub-device, one user wants "Outlet 3 Power" and another wants "Server Rack PDU Outlet 3 Power". That's a per-context toggle on top of the normal device-plus-entity name, and it's a real reason to keep depth at one level: every extra level multiplies these choices.

Is the naming toggle something that happens per-entity, per sub-device, or per parent device? Is this also something that we should always default to off or allow integrations to decide the default?

[thecode]

I think the suggestion in this proposal is very good and would answer the sub-device vs how is the device connected.

Since the proposal mention frontend changes that are part of this discussion frontend #52512 it would be nice to understand or have a sample picture of the final result of a device with sub-devices, mainly to understand if the user experience would be similar or better to the existing implementation (I have raised some concerns or clarifications at frontend #52512)

[arturpragacz]

I was actually working on a similar proposal, which I called "Device parts". So that would be my preference when it comes to naming, I never liked "sub-device" to begin with.

I would also suggest to make it a completely separate class, as the majority of DeviceEntry fields are not actually relevant to it. That way for example the discussion about defaulting via_device would not be needed, DevicePartEntry would simply not have a via_device field.

[parautenbach]

This reminds me of these concepts in UML modelling: aggregation (weak composition) vs composition (strong composition). Weak composition is where the parts can exist without the whole. In my view, what you say makes sense, but looking at all of this neither proposal captures both very well. To make this concrete: A weather station is a single device where the parts in themself can function separately (the anemometer, the temperature sensor, etc.). This would be device aggregation. In the case of a smart multiplug/strip, the individual sockets cannot be used without being part of the strip, so that's device composition. A Hue bulb that requires the hub is composition as well. This might seem like unnecessary pedantry, but I think it would be best to ensure that this proposal (which is about composition) wouldn't exclude possibilities regarding aggregation in future, or that cases where device aggregation makes most sense, that it's not abused as device composition.

[abmantis]

I agree with Artur about this being in a separate class (whatever the name is eheh DevicePartEntry or SubDeviceEntry are both fine for me). We should probably have a DeviceEntryBase with the common stuff and derive both DeviceEntry and DevicePartEntry from it.

[abmantis]

This makes a lot of sense.

I have only 2 comments/questions. The first is about having a new class instead of adding more attributes to DeviceEntry (and async_update_device, which is huge already), which I've commented on Artur's thread already.

The second is regarding migration: is it really a concern for this proposal? Because even if this proposal was rejected, the "not split yet" integrations would still have the same problem if they used via_device, right? Or did I miss something that makes this new approach different/more problematic in regards to migration?

[emontnemery]

Comments:

• Should we restrict the parent to the same config entry as the child?
• Since the proposal requires UI adjustments around how related devices are presented, I think we should do this together with Make device identifiers and connections unique per config entry instead of globally unique #1226 which will need exactly the same parts of the UI to be adjusted