Pre-submission checklist
Bug description
Bug: Duplicate unique_id warning for binary_sensor cover_open on startup
Description
On Home Assistant startup, the integration logs a "does not generate unique IDs" warning for the cover/lid binary sensor, even though the entity registry contains exactly one entry for that unique_id. The entity continues to function afterward.
Log output
Platform xtool does not generate unique IDs. ID <SERIAL>_cover_open already exists - ignoring binary_sensor.<device>_deckel
Environment
- Home Assistant Core: 2026.6.4
- Home Assistant OS: 18.0
- Integration: xtool (custom_components/xtool)
- Device: xTool M2
Investigation so far
binary_sensor.py contains exactly one XtoolCoverSensor class definition with _set_unique_id("cover_open") (line 46) — no duplicate class/key in source.core.entity_registry contains exactly one entry with unique_id ending in _cover_open:
binary_sensor.xtool_m2_<serial>_deckel | <serial>_cover_open | disabled_by=null | platform=xtool
async_setup_entry in binary_sensor.py calls coordinator.register_platform_add("binary_sensor", async_add_entities) (line 24) in addition to the direct async_add_entities(entities) call (line 34) for the statically-known XtoolCoverSensor.- This suggests
async_setup_entry (or the coordinator's first refresh callback) may attempt to add the same statically-defined XtoolCoverSensor instance twice during startup — once via the direct async_add_entities call, and potentially again via the dynamic accessory-dispatch path intended for runtime-discovered entities (_known_accessory_keys mechanism around line 425).
Expected behavior
No duplicate-ID warning on a clean startup; the static cover sensor should only be added once.
Suggested area to check
Whether the dynamic accessory dispatch (register_platform_add callback, invoked from the coordinator's data-refresh handler) can fire before/independently of the static entities.append(XtoolCoverSensor(coordinator)) setup path, and if the statically-added entities should be excluded from the dynamic dispatch's candidate list (e.g. via _known_accessory_keys pre-seeding for static entities).
Impact
Cosmetic/log-only — the entity registers correctly after the warning, no data loss observed. Filing for visibility since the underlying race condition could affect other statically-defined entity types if the device firmware reports overlapping data on first refresh.
Device model
Other / not listed
Firmware version
ka
Integration version
ka
Home Assistant version
la
Steps to reproduce
Bug: Duplicate unique_id warning for binary_sensor cover_open on startup
Description
On Home Assistant startup, the integration logs a "does not generate unique IDs" warning for the cover/lid binary sensor, even though the entity registry contains exactly one entry for that unique_id. The entity continues to function afterward.
Log output
Platform xtool does not generate unique IDs. ID <SERIAL>_cover_open already exists - ignoring binary_sensor.<device>_deckel
Environment
- Home Assistant Core: 2026.6.4
- Home Assistant OS: 18.0
- Integration: xtool (custom_components/xtool)
- Device: xTool M2
Investigation so far
binary_sensor.py contains exactly one XtoolCoverSensor class definition with _set_unique_id("cover_open") (line 46) — no duplicate class/key in source.core.entity_registry contains exactly one entry with unique_id ending in _cover_open:
binary_sensor.xtool_m2_<serial>_deckel | <serial>_cover_open | disabled_by=null | platform=xtool
async_setup_entry in binary_sensor.py calls coordinator.register_platform_add("binary_sensor", async_add_entities) (line 24) in addition to the direct async_add_entities(entities) call (line 34) for the statically-known XtoolCoverSensor.- This suggests
async_setup_entry (or the coordinator's first refresh callback) may attempt to add the same statically-defined XtoolCoverSensor instance twice during startup — once via the direct async_add_entities call, and potentially again via the dynamic accessory-dispatch path intended for runtime-discovered entities (_known_accessory_keys mechanism around line 425).
Expected behavior
No duplicate-ID warning on a clean startup; the static cover sensor should only be added once.
Suggested area to check
Whether the dynamic accessory dispatch (register_platform_add callback, invoked from the coordinator's data-refresh handler) can fire before/independently of the static entities.append(XtoolCoverSensor(coordinator)) setup path, and if the statically-added entities should be excluded from the dynamic dispatch's candidate list (e.g. via _known_accessory_keys pre-seeding for static entities).
Impact
Cosmetic/log-only — the entity registers correctly after the warning, no data loss observed. Filing for visibility since the underlying race condition could affect other statically-defined entity types if the device firmware reports overlapping data on first refresh.
Expected behaviour
Bug: Duplicate unique_id warning for binary_sensor cover_open on startup
Description
On Home Assistant startup, the integration logs a "does not generate unique IDs" warning for the cover/lid binary sensor, even though the entity registry contains exactly one entry for that unique_id. The entity continues to function afterward.
Log output
Platform xtool does not generate unique IDs. ID <SERIAL>_cover_open already exists - ignoring binary_sensor.<device>_deckel
Environment
- Home Assistant Core: 2026.6.4
- Home Assistant OS: 18.0
- Integration: xtool (custom_components/xtool)
- Device: xTool M2
Investigation so far
binary_sensor.py contains exactly one XtoolCoverSensor class definition with _set_unique_id("cover_open") (line 46) — no duplicate class/key in source.core.entity_registry contains exactly one entry with unique_id ending in _cover_open:
binary_sensor.xtool_m2_<serial>_deckel | <serial>_cover_open | disabled_by=null | platform=xtool
async_setup_entry in binary_sensor.py calls coordinator.register_platform_add("binary_sensor", async_add_entities) (line 24) in addition to the direct async_add_entities(entities) call (line 34) for the statically-known XtoolCoverSensor.- This suggests
async_setup_entry (or the coordinator's first refresh callback) may attempt to add the same statically-defined XtoolCoverSensor instance twice during startup — once via the direct async_add_entities call, and potentially again via the dynamic accessory-dispatch path intended for runtime-discovered entities (_known_accessory_keys mechanism around line 425).
Expected behavior
No duplicate-ID warning on a clean startup; the static cover sensor should only be added once.
Suggested area to check
Whether the dynamic accessory dispatch (register_platform_add callback, invoked from the coordinator's data-refresh handler) can fire before/independently of the static entities.append(XtoolCoverSensor(coordinator)) setup path, and if the statically-added entities should be excluded from the dynamic dispatch's candidate list (e.g. via _known_accessory_keys pre-seeding for static entities).
Impact
Cosmetic/log-only — the entity registers correctly after the warning, no data loss observed. Filing for visibility since the underlying race condition could affect other statically-defined entity types if the device firmware reports overlapping data on first refresh.
Actual behaviour
Bug: Duplicate unique_id warning for binary_sensor cover_open on startup
Description
On Home Assistant startup, the integration logs a "does not generate unique IDs" warning for the cover/lid binary sensor, even though the entity registry contains exactly one entry for that unique_id. The entity continues to function afterward.
Log output
Platform xtool does not generate unique IDs. ID <SERIAL>_cover_open already exists - ignoring binary_sensor.<device>_deckel
Environment
- Home Assistant Core: 2026.6.4
- Home Assistant OS: 18.0
- Integration: xtool (custom_components/xtool)
- Device: xTool M2
Investigation so far
binary_sensor.py contains exactly one XtoolCoverSensor class definition with _set_unique_id("cover_open") (line 46) — no duplicate class/key in source.core.entity_registry contains exactly one entry with unique_id ending in _cover_open:
binary_sensor.xtool_m2_<serial>_deckel | <serial>_cover_open | disabled_by=null | platform=xtool
async_setup_entry in binary_sensor.py calls coordinator.register_platform_add("binary_sensor", async_add_entities) (line 24) in addition to the direct async_add_entities(entities) call (line 34) for the statically-known XtoolCoverSensor.- This suggests
async_setup_entry (or the coordinator's first refresh callback) may attempt to add the same statically-defined XtoolCoverSensor instance twice during startup — once via the direct async_add_entities call, and potentially again via the dynamic accessory-dispatch path intended for runtime-discovered entities (_known_accessory_keys mechanism around line 425).
Expected behavior
No duplicate-ID warning on a clean startup; the static cover sensor should only be added once.
Suggested area to check
Whether the dynamic accessory dispatch (register_platform_add callback, invoked from the coordinator's data-refresh handler) can fire before/independently of the static entities.append(XtoolCoverSensor(coordinator)) setup path, and if the statically-added entities should be excluded from the dynamic dispatch's candidate list (e.g. via _known_accessory_keys pre-seeding for static entities).
Impact
Cosmetic/log-only — the entity registers correctly after the warning, no data loss observed. Filing for visibility since the underlying race condition could affect other statically-defined entity types if the device firmware reports overlapping data on first refresh.
Debug logs
## Bug: Duplicate unique_id warning for binary_sensor cover_open on startup
### Description
On Home Assistant startup, the integration logs a "does not generate unique IDs" warning for the cover/lid binary sensor, even though the entity registry contains exactly one entry for that `unique_id`. The entity continues to function afterward.
### Log output
Platform xtool does not generate unique IDs. ID <SERIAL>_cover_open already exists - ignoring binary_sensor.<device>_deckel
### Environment
- Home Assistant Core: 2026.6.4
- Home Assistant OS: 18.0
- Integration: xtool (custom_components/xtool)
- Device: xTool M2
### Investigation so far
- `binary_sensor.py` contains exactly one `XtoolCoverSensor` class definition with `_set_unique_id("cover_open")` (line 46) — no duplicate class/key in source.
- `core.entity_registry` contains exactly one entry with `unique_id` ending in `_cover_open`:
binary_sensor.xtool_m2_<serial>_deckel | <serial>_cover_open | disabled_by=null | platform=xtool
No orphaned/duplicate registry entries found.
- `async_setup_entry` in `binary_sensor.py` calls `coordinator.register_platform_add("binary_sensor", async_add_entities)` (line 24) in addition to the direct `async_add_entities(entities)` call (line 34) for the statically-known `XtoolCoverSensor`.
- This suggests `async_setup_entry` (or the coordinator's first refresh callback) may attempt to add the same statically-defined `XtoolCoverSensor` instance twice during startup — once via the direct `async_add_entities` call, and potentially again via the dynamic accessory-dispatch path intended for runtime-discovered entities (`_known_accessory_keys` mechanism around line 425).
### Expected behavior
No duplicate-ID warning on a clean startup; the static cover sensor should only be added once.
### Suggested area to check
Whether the dynamic accessory dispatch (`register_platform_add` callback, invoked from the coordinator's data-refresh handler) can fire before/independently of the static `entities.append(XtoolCoverSensor(coordinator))` setup path, and if the statically-added entities should be excluded from the dynamic dispatch's candidate list (e.g. via `_known_accessory_keys` pre-seeding for static entities).
### Impact
Cosmetic/log-only — the entity registers correctly after the warning, no data loss observed. Filing for visibility since the underlying race condition could affect other statically-defined entity types if the device firmware reports overlapping data on first refresh.
Screenshots / additional context
No response
Pre-submission checklist
Bug description
Bug: Duplicate unique_id warning for binary_sensor cover_open on startup
Description
On Home Assistant startup, the integration logs a "does not generate unique IDs" warning for the cover/lid binary sensor, even though the entity registry contains exactly one entry for that
unique_id. The entity continues to function afterward.Log output
Environment
Investigation so far
binary_sensor.pycontains exactly oneXtoolCoverSensorclass definition with_set_unique_id("cover_open")(line 46) — no duplicate class/key in source.core.entity_registrycontains exactly one entry withunique_idending in_cover_open:async_setup_entryinbinary_sensor.pycallscoordinator.register_platform_add("binary_sensor", async_add_entities)(line 24) in addition to the directasync_add_entities(entities)call (line 34) for the statically-knownXtoolCoverSensor.async_setup_entry(or the coordinator's first refresh callback) may attempt to add the same statically-definedXtoolCoverSensorinstance twice during startup — once via the directasync_add_entitiescall, and potentially again via the dynamic accessory-dispatch path intended for runtime-discovered entities (_known_accessory_keysmechanism around line 425).Expected behavior
No duplicate-ID warning on a clean startup; the static cover sensor should only be added once.
Suggested area to check
Whether the dynamic accessory dispatch (
register_platform_addcallback, invoked from the coordinator's data-refresh handler) can fire before/independently of the staticentities.append(XtoolCoverSensor(coordinator))setup path, and if the statically-added entities should be excluded from the dynamic dispatch's candidate list (e.g. via_known_accessory_keyspre-seeding for static entities).Impact
Cosmetic/log-only — the entity registers correctly after the warning, no data loss observed. Filing for visibility since the underlying race condition could affect other statically-defined entity types if the device firmware reports overlapping data on first refresh.
Device model
Other / not listed
Firmware version
ka
Integration version
ka
Home Assistant version
la
Steps to reproduce
Bug: Duplicate unique_id warning for binary_sensor cover_open on startup
Description
On Home Assistant startup, the integration logs a "does not generate unique IDs" warning for the cover/lid binary sensor, even though the entity registry contains exactly one entry for that
unique_id. The entity continues to function afterward.Log output
Environment
Investigation so far
binary_sensor.pycontains exactly oneXtoolCoverSensorclass definition with_set_unique_id("cover_open")(line 46) — no duplicate class/key in source.core.entity_registrycontains exactly one entry withunique_idending in_cover_open:async_setup_entryinbinary_sensor.pycallscoordinator.register_platform_add("binary_sensor", async_add_entities)(line 24) in addition to the directasync_add_entities(entities)call (line 34) for the statically-knownXtoolCoverSensor.async_setup_entry(or the coordinator's first refresh callback) may attempt to add the same statically-definedXtoolCoverSensorinstance twice during startup — once via the directasync_add_entitiescall, and potentially again via the dynamic accessory-dispatch path intended for runtime-discovered entities (_known_accessory_keysmechanism around line 425).Expected behavior
No duplicate-ID warning on a clean startup; the static cover sensor should only be added once.
Suggested area to check
Whether the dynamic accessory dispatch (
register_platform_addcallback, invoked from the coordinator's data-refresh handler) can fire before/independently of the staticentities.append(XtoolCoverSensor(coordinator))setup path, and if the statically-added entities should be excluded from the dynamic dispatch's candidate list (e.g. via_known_accessory_keyspre-seeding for static entities).Impact
Cosmetic/log-only — the entity registers correctly after the warning, no data loss observed. Filing for visibility since the underlying race condition could affect other statically-defined entity types if the device firmware reports overlapping data on first refresh.
Expected behaviour
Bug: Duplicate unique_id warning for binary_sensor cover_open on startup
Description
On Home Assistant startup, the integration logs a "does not generate unique IDs" warning for the cover/lid binary sensor, even though the entity registry contains exactly one entry for that
unique_id. The entity continues to function afterward.Log output
Environment
Investigation so far
binary_sensor.pycontains exactly oneXtoolCoverSensorclass definition with_set_unique_id("cover_open")(line 46) — no duplicate class/key in source.core.entity_registrycontains exactly one entry withunique_idending in_cover_open:async_setup_entryinbinary_sensor.pycallscoordinator.register_platform_add("binary_sensor", async_add_entities)(line 24) in addition to the directasync_add_entities(entities)call (line 34) for the statically-knownXtoolCoverSensor.async_setup_entry(or the coordinator's first refresh callback) may attempt to add the same statically-definedXtoolCoverSensorinstance twice during startup — once via the directasync_add_entitiescall, and potentially again via the dynamic accessory-dispatch path intended for runtime-discovered entities (_known_accessory_keysmechanism around line 425).Expected behavior
No duplicate-ID warning on a clean startup; the static cover sensor should only be added once.
Suggested area to check
Whether the dynamic accessory dispatch (
register_platform_addcallback, invoked from the coordinator's data-refresh handler) can fire before/independently of the staticentities.append(XtoolCoverSensor(coordinator))setup path, and if the statically-added entities should be excluded from the dynamic dispatch's candidate list (e.g. via_known_accessory_keyspre-seeding for static entities).Impact
Cosmetic/log-only — the entity registers correctly after the warning, no data loss observed. Filing for visibility since the underlying race condition could affect other statically-defined entity types if the device firmware reports overlapping data on first refresh.
Actual behaviour
Bug: Duplicate unique_id warning for binary_sensor cover_open on startup
Description
On Home Assistant startup, the integration logs a "does not generate unique IDs" warning for the cover/lid binary sensor, even though the entity registry contains exactly one entry for that
unique_id. The entity continues to function afterward.Log output
Environment
Investigation so far
binary_sensor.pycontains exactly oneXtoolCoverSensorclass definition with_set_unique_id("cover_open")(line 46) — no duplicate class/key in source.core.entity_registrycontains exactly one entry withunique_idending in_cover_open:async_setup_entryinbinary_sensor.pycallscoordinator.register_platform_add("binary_sensor", async_add_entities)(line 24) in addition to the directasync_add_entities(entities)call (line 34) for the statically-knownXtoolCoverSensor.async_setup_entry(or the coordinator's first refresh callback) may attempt to add the same statically-definedXtoolCoverSensorinstance twice during startup — once via the directasync_add_entitiescall, and potentially again via the dynamic accessory-dispatch path intended for runtime-discovered entities (_known_accessory_keysmechanism around line 425).Expected behavior
No duplicate-ID warning on a clean startup; the static cover sensor should only be added once.
Suggested area to check
Whether the dynamic accessory dispatch (
register_platform_addcallback, invoked from the coordinator's data-refresh handler) can fire before/independently of the staticentities.append(XtoolCoverSensor(coordinator))setup path, and if the statically-added entities should be excluded from the dynamic dispatch's candidate list (e.g. via_known_accessory_keyspre-seeding for static entities).Impact
Cosmetic/log-only — the entity registers correctly after the warning, no data loss observed. Filing for visibility since the underlying race condition could affect other statically-defined entity types if the device firmware reports overlapping data on first refresh.
Debug logs
Screenshots / additional context
No response