core icon indicating copy to clipboard operation
core copied to clipboard

Add Computer Name to config entry and as device name prefix

Open Sab44 opened this issue 2 months ago • 5 comments

Proposed change

When a user has multiple config entries (= multiple PCs monitored) and those PCs have the same hardware, then HA will resolve entity ID collisions by suffixing entity IDs with _2, _3, … As a result, it’s unclear which entities belong to which config entry/host.

This PR resolves this by also fetching the computer name as provided by the Libre Hardware Monitor API (via the library) and prefixing device names (and subsequently, the derived entity IDs) with it.

Previously, device names were not clearly assigned to a specific PC (= config entry). For example:

AMD Ryzen 7 7800X3D
NVIDIA GeForce RTX 4080 SUPER
Samsung SSD 990 EVO Plus 2TB

Now they will have a square bracket prefix with the computer name e.g. "GAMING-PC"

[GAMING-PC] AMD Ryzen 7 7800X3D
[GAMING-PC] NVIDIA GeForce RTX 4080 SUPER
[GAMING-PC] Samsung SSD 990 EVO Plus 2TB

This will also impact the entity IDs that are derived partially from the device name they belong to. Previous entity IDs looked something like this

CPU:
sensor.12th_gen_intel_core_i3_12100_bus_speed_clock
sensor.12th_gen_intel_core_i3_12100_cpu_core_1_clock

GPU:
sensor.nvidia_geforce_rtx_4070_super_d3d_3d_load

Disks:
sensor.netac_ssd_2tb_read_activity_load
sensor.netac_ssd_2tb_read_activity_load_2
sensor.netac_ssd_2tb_read_activity_load_3

Now those entity IDs will be prefixed accordingly

CPU:
sensor.gaming_pc_12th_gen_intel_core_i3_12100_bus_speed_clock
sensor.gaming_pc_12th_gen_intel_core_i3_12100_cpu_core_1_clock

GPU:
sensor.gaming_pc_nvidia_geforce_rtx_4070_super_d3d_3d_load

Disks:
sensor.gaming_pc_netac_ssd_2tb_read_activity_load
sensor.gaming_pc_netac_ssd_2tb_read_activity_load_2
sensor.gaming_pc_netac_ssd_2tb_read_activity_load_3

Additionally, the config entry title is also updated from something like

192.168.0.20:8085

to also include the computer name:

GAMING-PC (192.168.0.20:8085)

As this is not a strictly necessary upgrade I have chosen not to force a migration as it would presumably be a breaking change and require a new major config flow version. Previous entries will continue to work as before, the only difference will be that device names will receive the computer name prefix (but nalready existing entity IDs will stay untouched) so nothing should break here.

Will close: https://github.com/home-assistant/core/issues/155953

In order to access the computer name, the library was updated to include it in the data model. Diff: https://github.com/Sab44/librehardwaremonitor-api/compare/v1.5.0...v1.6.0

Screenshot of 2 monitored PCs with the changes of this PR included: Screenshot 2025-12-22 at 08 59 25

Type of change

  • [x] Dependency upgrade
  • [ ] Bugfix (non-breaking change which fixes an issue)
  • [ ] New integration (thank you!)
  • [x] New feature (which adds functionality to an existing integration)
  • [ ] Deprecation (breaking change to happen in the future)
  • [ ] Breaking change (fix/feature causing existing functionality to break)
  • [ ] Code quality improvements to existing code or addition of tests

Additional information

  • This PR fixes or closes issue: fixes #155953
  • This PR is related to issue:
  • Link to documentation pull request:
  • Link to developer documentation pull request:
  • Link to frontend pull request:

Checklist

  • [x] I understand the code I am submitting and can explain how it works.
  • [x] The code change is tested and works locally.
  • [x] Local tests pass. Your PR cannot be merged unless tests pass
  • [x] There is no commented out code in this PR.
  • [x] I have followed the development checklist
  • [x] I have followed the perfect PR recommendations
  • [x] The code has been formatted using Ruff (ruff format homeassistant tests)
  • [x] Tests have been added to verify that the new code works.
  • [x] Any generated code has been carefully reviewed for correctness and compliance with project standards.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • [x] The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • [x] New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • [x] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

Sab44 avatar Dec 18 '25 07:12 Sab44

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks :+1:

Learn more about our pull request process.

home-assistant[bot] avatar Dec 18 '25 13:12 home-assistant[bot]

Thanks for the feedback @joostlek Regarding your points

  1. We shouldn't migrate entity_ids, that will break automations

Makes sense, probably will cause more pain than good to update entity IDs in real-time. I will remove this functionality again.

  1. IMO we also shouldn't manually set self.entity_id as it will make sure it's not translated and whatnot

This has me somewhat confused. If we go to homeassistant/helpers/entity.py and to the definition of the entity_id variable it explicitly states

    # SAFE TO OVERWRITE
    # The properties and methods here are safe to overwrite when inheriting
    # this class. These may be used to customize the behavior of the entity.
    entity_id: str = None  # type: ignore[assignment]

When we check how the overwritten entity_id is handled we can find that it is converted to suggested_object_id (in entity_platform.py's _async_add_entity method) before being passed to entity_registry.async_get_or_create. That makes it sound to me like overwriting the entity_id is a valid and supported way of configuring entities in integrations. Or am I missing something here?

I would therefore suggest the following:

  • Remove auto-update of entity IDs
  • When config entry is newly set up, we add the computer name as prefix to the entity IDs
  • When computer name is subsequently changed on the host we do nothing (might come back to this when adding a reconfigure flow)
  • OPTIONAL: add migration for existing config entries - this is then presumably done via introducing a new minor version and marking this as breaking change when it is released in HA. Would be happy for your feedback on this (or whether we should leave existing config entries simply as they are).

I will mark this PR as ready-for-review again since I want to clarify those points before investing the effort to make the changes, hope that's ok. Thanks!

Sab44 avatar Dec 19 '25 12:12 Sab44

When we check how the overwritten entity_id is handled we can find that it is converted to suggested_object_id (in entity_platform.py's _async_add_entity method) before being passed to entity_registry.async_get_or_create. That makes it sound to me like overwriting the entity_id is a valid and supported way of configuring entities in integrations. Or am I missing something here?

Yes its a valid way to change the entity_id, but I think this comment was from before translations, so while this works, it's not user friendly.

But it leaves me the question, why rename the device? I think you could consider just prepending the device names with entry.title and that would do the same

joostlek avatar Dec 20 '25 08:12 joostlek

But it leaves me the question, why rename the device? I think you could consider just prepending the device names with entry.title and that would do the same

Renaming the devices to prefix them with the PC name was an approach I considered but decided against it since I didn't like the way it looked e.g. having devices listed in the config entry as

[GAMING-PC] AMD Ryzen 7 7800X3D
[GAMING-PC] NVIDIA GeForce RTX 4080 SUPER
[GAMING-PC] Samsung SSD 990 EVO Plus 2TB

but considering your points about directly setting the entity id I suppose this is the way to go. It does also bring the benefit that if we have 2 PCs monitored that have identical hardware parts inside of them it is immediately clear which device belongs to which PC. I will re-implement the solution to follow this approach instead.

So now the only question is: does this warrant a breaking change i.e. "force" migrate existing config entries to the new device names (and subsequently, new entity IDs) or would it be better to only apply this to newly created config entries?

Sab44 avatar Dec 20 '25 20:12 Sab44

Updated PR to only prepend device names, as discussed. Also updated the original PR description to reflect the current state.

Sab44 avatar Dec 22 '25 08:12 Sab44