Since 2024.2.0 switching between mqtt: and api: is now impossible

I guess it’s because the change that disallowed device prefix in the name.

As many, I had name: “${device_name} …” in esphome config files everywhere and relied on the auto-generated sensor.device_name_sensor_name_id as the entity_id in home assistant. Friendly names all had the prefix removed and capitalized, looking nice.

Now, updated HA past 2024.2.0 and everything broke. MQTT entities become device_name_device_name_sensor_name, API still good. Okay, I googled, found out, spent all day removing the prefix, reuploaded the firmware to all my devices. Still wrong. Now MQTT devices have a single prefix in the name (not by me, automagically), API devices don’t, those now look like name_2/_3/…, which is completely unaccaptable.

What should I do?

What should I do?

  • Step 1 - have a look at this thread (forum search is always your friend):
    PSA: MQTT Name changes in 2023.8 - #61 by FloatingBoater

  • Step 2 - Give the community some idea what MQTT client devices you are using so we can help.

    Tasmota? Shelly? Custom code? Paho Python library? Z2MQTT? PDP11 with a serial cable?

“Friendly Name” might hint at Tasmota - which would is very easy to fix:

  • Configure Other
  • Device Name = hardware device based - e.g TH16
  • Friendly Name 1 = usage based - e.g. HW Cylinder

Some folk post issues after adding HASS updates only a few times a year, then don’t update integrations and get issues - e.g. Z2MQTT was updated for this old change several months ago. Personally, a RPi4 makes a good pre-production test-bed if you really don’t like tracking current releases.

If this helps, :heart: this post!

I saw that thread. And I understand the naming recommendation. It just creates a problem for me that I am unable to solve.

There are smart plugs, bluetooth sensors, 443mhz sensors, the usual things. All running on esp boards. Some I have at home, some in other locations (where I use mqtt). There is a common yaml code base for the sensors, and depending on the location, I include the mqtt: or the api: yaml files to set the connection type.

With this change I can no longer have the same name. For mqtt I don’t need the prefix, for api I do, because there HA does not put it into the entity_id. I either have double prefix or auto-numbered useless ids, which I cannot use in automations and scripts, becuase I refuse to cross-reference them every time. It also breaks my historical data.

I only use the ESPHome and the MQTT integration. All up to date. This is a very ESPHome specific problem, but it has nothing to do with ESPHome. That’s why I asked it here.

Here is a very simplified example:


  plug_name: bw-shp6-7-15a
  voltage_div: "740"  
  api: !include packages/api.yaml
  #mqtt: !include packages/mqtt.yaml
  wifi: !include packages/wifi.yaml
  device: !include packages/bw_shp6_15a.yaml


  - platform: gpio
    name: "${plug_name} Relay"

If I enable mqtt I get (if I keep the prefix):
entity_id: switch.bw_shp6_7_15a_bw_shp6_7_15a_relay
friendly name: bw_shp6_7_15a bw_shp6_7_15a Relay

With api (if I remove the prefix):
entity_id: switch.relay_7
friendly name: Relay

Before 2024.2.0 (both api and mqtt):
entity_id: switch.bw_shp6_7_15a_relay
friendly name: Relay


Sorry - I didn’t pick up on the ESPhome tag, only the MQTT problem statement, probably as I assumed (wrongly?) that ESPhome is tightly integrated into HASS, so the transport underneath is pretty transparent (e.g. local API).

For remote MQTT, I’ve only used raw code and not ESPhome so can’t contrast local API verses remote MQTT. The post I linked to includes mosquitto_pub examples if you need to compare the ESPhome code against what the broker and HASS publishes, verses what actually works in MQTTexplorer.

For me, naming is just a case of changing the friendly_name to the human-readable text for each device e.g.

  name: "heater-switch"                    # generic hardware device name
  friendly_name: "En Suite Towel Radiator" # human-readable instance name
  version_s: "0.4"

  name: ${name}                    # generic hardware device name
  friendly_name: ${friendly_name}  # human-readable instance name

  # Automatically add the mac address to the name
  # so you can use a single firmware for all devices
  #name_add_mac_suffix: true

  # This will allow for (future) project identification,
  # configuration and updates.
    name: floatingboater.$name
    version: $version_s

Not relying on autogenerated friendly_name can fix one problem, but that’s only cosmetic. What I really need is a unique entity_id and to be cosistent between both integrations. It used to work. But now MQTT is trying to be smart and prefixes it with the device name. This was not the case.

Staying on 2024.1.6 I guess.

Not sure in relation to mqtt, but why not just remove the friendly name for the esp and keep the prefix? If there’s no friendly name, the esp won’t prefix it, so you just have your own prefix.

I have no friendly_name in my yaml. The way MQTT integration alters the entity_id is my problem really. It prefixes, like I used to do, device_name + name.

In that case, maybe you should set the friendly name for the esp and not do your own prefixing for the entities? Same as mqtt, that name is prefixed automatically by HA.

To be clear, I’m talking about this, the friendly name for the device (the device name):

  friendly_name: ${friendly_name}  # human-readable instance name

I don’t think it will have any effect on the generated entity_id name. That’s what I refer to in automations and scripts, not the friendly name.

Now I came up with this workaround.


  name_prefix: ""


  name_prefix: "${plug_name} "


  - platform: gpio
    name: "${name_prefix}Relay"
    friendly_name: "Relay"

It’s stupid but almost the same as before 2024.2.0.

It does. The docs:

friendly_name (Optional, string): This is the name sent to the frontend. It is used by Home Assistant as the integration name, device name, and is automatically prefixed to entities where necessary.

It is refledted in the entity id for all my devices.

I have to try it in that case! The “where necessary” part makes me worried.

Confirmed. It does affect the id. It’s like a secret hidden function, but kinda important. The id only changes when deleting and re-adding the device. Have to be careful not to be fooled by the old values. And mqtt still does not care, it adds the prefix without asking. At least it is consistent now.

1 Like