Input_select: 2 entities declared with same entity_ids

[Ildar_Gabdullin]

I wonder is it a bug or a designed behaviour:

1. Declare two “input_select” entities:

input_select:
  test_abc:
    options:
      - alpha
      - bravo
      - charlie

input_select:
  test_abc:
    options:
      - delta
      - echo
      - foxtrot

in different packages.
2. Note that these entities have same entity_id.
3. Reload “input_select” entities.
4. Check that one “input_select.test_abc” entity is created with MERGED lists:

I believed that HA does not allow me to create entities with same entity_id.
This happened in fact - one entity is created, by WTH it gets a merged list?

[tom_l]

That seems to be a bug to me.

[Ildar_Gabdullin]

Thanks for a reply.
Thinking about registering an issue in core.

Also, I am thinking about possible positive outcomes of this “possibly bug”.
One use-case comes to my mind:

1. Imagine a package-based config.
2. Assume these packages represent “root areas” of some house hold - we have packages like “garden”, “house”, “workshop”, “garage”.
3. Each package has “input_select.areas” (i.e. with same entity_id) - each declaration contains own list of areas like “kitchen”, “bedroom”, or “garage”, or “garden grill”, “hotbeds” etc.
4. The resulting “input_select.areas” contains a full list of areas (collected from packages).

Would be great to hear opinions.

[123 (Taras)]

@Ildar_Gabdullin

entity is created with MERGED lists

Based on experience (errors I made) during my early days with Home Assistant, if you create a duplicate entity configuration in the configuration file, it will get flagged as an error.

I agree with tom_l that what you have observed seems like a bug; instead of reporting the duplication as an error, it attempted to mitigate it (creating a single merged entity).

Makes me wonder if this behavior is limited to Input Select or it attempts to do the same thing with other duplicated helpers, etc.

[Ildar_Gabdullin]

@123

or it attempts to do the same thing with other duplicated helpers, etc.

Tested with these packages:
same_entity_ids_1.yaml

input_boolean:
  test_same_flag:
    icon: mdi:account

same_entity_ids_2.yaml:

input_boolean:
  test_same_flag:
    icon: mdi:car

Got an error:
2024-01-10 07:53:09.633 ERROR (MainThread) [homeassistant.config] Setup of package ‘same_entity_ids_2’ at conf/test/same_entity_ids/same_entity_ids_2.yaml, line 1 failed: integration ‘input_boolean’ has duplicate key ‘icon’
The entity was created from the 1st package:

Seems that these 2 declarations were merged into one - that is why “duplicated icon”.

[Ildar_Gabdullin]

Test with number:

input_number:
  test_same_number:
    max: 456
    step: 12

input_number:
  test_same_number:
    min: 123
    icon: mdi:car

No errors.

[123 (Taras)]

Thanks for taking the time to perform the tests.

Surprising results. Also, undesirable results because I doubt anyone wants what should be separate entities combined into one. If this is not considered to be a bug then I would be interested to hear the justification for this behavior.

[Ildar_Gabdullin]

I see only one justification - for input_select.
This usecase.

Registered the issue.

But may be I made the 1st step to kill a really useful feature.

[Edwin_D]

I’m not hindered by actual knowledge about the code base, but maybe this behavior is what customize relies on? But outside that integration I agree it would be more useful to throw an exception as it is likely a problem.

[Didgeridrew]

@Ildar_Gabdullin

But may be I made the 1st step to kill a really useful feature.

It would require more entities and might not be as “clean looking”, but something similar to your example could be accomplished by merging options using a Template Select.

[Ildar_Gabdullin]

@Edwin_D

but maybe this behavior is what customize relies on?

Hope “fixing” will not touch Customize.
Btw, do you mean this?

homeassistant:
  customize:
    sensor.xyz:
      name: hello

homeassistant:
  customize:
    sensor.xyz:
      icon: mdi:car

i.e. customizing same entity in different packages? ))) (have no idea if it is possible)

[Ildar_Gabdullin]

@Didgeridrew

example could be accomplished by merging options using a Template Select

Thank you, could you post a draft snippet how to do it?
I think I get the idea of defining “options” dynamically - but how this can be done in a simple “a new package added”, “some package is removed” scenario?
In my possible usecase these options may be added/removed automatically.

[Didgeridrew]

Like in your example, a package gets an area Input Select that follows a specific ID convention. Unlike your example, they don’t use the same ID, but they can still contain a single option:

input_select:
  area_kitchen:
    options:
      - kitchen

or multiple options:

input_select:
  area_basement:
    options:
      - utility_room
      - basement_bedroom
      - den

Then the Template select merges the options using the convention as selection criteria:

template:
  - select:
      - name: "Merged Area Selects"
        state: "{{ states('input_text.selected_area') }}"
        options: >
          {{ states.input_select 
          | selectattr('entity_id', 'match', 'input_select.area_') 
          | map(attribute='attributes.options')|sum(start=[]) }}
        select_option:
          - service: input_text.set_value
            target:
              entity_id: input_text.selected_area
            data:
              value: "{{ option }}"

# Helper for template select state storage
input_text:
  selected_area:
    name: Selected Area
    initial: kitchen

[Ildar_Gabdullin]

I see, thank you)

[Ildar_Gabdullin]

One more possible positive outcome: reusable code for helpers.

Here are settings for some “color” entity:

min: 0
max: 255
step: 1
mode: slider

stored in some shared file.

Let’s create two similar entities - but with different icons:

input_number:
  test_color_1: !include /config/shared/helpers/input_number_color.yaml
  test_color_2: !include /config/shared/helpers/input_number_color.yaml

input_number:
  test_color_1:
    icon: mdi:car
  test_color_2:
    icon: mdi:account

This method may be used in cases when similar entities are initially defined in different packages.
Ofc, if they are defined in the same package - yaml-anchors are sufficient.