Weird behavior for esphome binary sensor in HA

ESPHome
,
1

Noticed weird behavior of binary sensors displayed in HA. I have two sensors, only one is displayed, but if I reconfigure device (in HA, not esp) the displayed sensor changes sometimes.

What can be wrong? I use this sensors to control endstop cover, are endstop cover sensors not supposed to be viewed from HA? How can I debug the problem?
Esphome code:

binary_sensor:
  - platform: gpio
    pin: 
      number: GPIO23
      inverted: true
      mode:
        input: true
        pullup: true
    name: "Датчик открытия основного крана"
    id: main_valve_opened_sensor
    filters:
      - delayed_on: 10ms
  - platform: gpio
    pin: 
      number: GPIO19
      inverted: true
      mode:
        input: true
        pullup: true
    name: "Датчик закрытия основного крана"
    id: main_valve_closed_sensor
    filters:
      - delayed_on: 10ms
cover:
  - platform: endstop
    id: main_valve
    name: "Основной кран"
    open_action:
      - output.turn_on: forward_valve_motor
    open_duration: 1min
    open_endstop: main_valve_opened_sensor
    close_action:
      - output.turn_on: backward_valve_motor
    close_duration: 1min
    close_endstop: main_valve_closed_sensor
    stop_action:
      - output.turn_off: forward_valve_motor
      - output.turn_off: backward_valve_motor
2

If you don’t want the sensor exposed to HA, either don’t give it a name: or set the internal: option to true.

3

I don’t mind it being shown. The problem is: I have two similar sensors, but one is available and one is not for no particular reason.

4

Well, it’s an HA problem then, not an ESPHome problem. I’d start by removing the device completely and re-adding it. There have been many changes recently in the way HA handles ESPHome entities and it does weird things, especially if you don’t have a friendly_name set in the device.

5

Most likely, a second similar entity exist with _2 after the id. Deleting the device from HA and adding it again will fix this kind of problem too though.

6

I removed the device and added again. It didn’t help.
I have a suspicion that HA didn’t remove the device fully. Somehow it remembers the zone it was in and suggests exactly it to me when adding again. What can I do to remove the device for sure?

7

I think found actual problem, HA logs tells me that esphome does not generate unique IDs. It is weird because I specified IDs myself for every sensor. How do I fix it?

2025-08-13 19:29:02.213 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform esphome does not generate unique IDs. ID 88:88:88:88:88:44-binary_sensor-_______________________________ is already used by binary_sensor.leakcontrol_datchik_otkrytiia_osnovnogo_krana - ignoring binary_sensor.leakcontrol_Датчик закрытия основного крана

8

I found the problem. I had russian letters in my sensor names. For some reason id is generated from name even if separate id is provided in esphome. I had 88:88:88:88:88:44-binary_sensor-_______________________________ as unique_id in HA before and it is 88:88:88:88:88:44-binary_sensor-main-valve-closed_sensor after I changed letters.

This seems wrong and I will file that as an issue to esphome github later.

9

Yes, munging human-readable names into IDs is always going to have the potential to go wrong.

There is an OHF policy in place that mandates that the ID of an ESPHome entity is not used outside the device. I personally think that’s a design error, but there seems little prospect of it being revisited.

If you raise an issue (and it will need to be raised in HA, not just ESPHome) there might be another band-aid fix applied, but I doubt the underlying problem will be addressed.

10

HA is actually able to deal with it. I have a name: "Датчик открытия основного крана" and it produces entity_id binary_sensor.leakcontrol_datchik_otkrytiia_osnovnogo_krana. So HA is actually able to transliterate russian letters into english for ids. It is just the unique_id problem. I am not good enough at code to find out where the problem happens, but logs suggest that it is esphome fault.

Anyway, I made an issue https://github.com/esphome/esphome/issues/10283

11

Which is an HA problem, it has nothing to do with ESPHome.