PSA: MQTT Name changes in 2023.8

[Loeffel]

Still he is right. The HA core developers changed something totally unnecessary which causes a lot of integrations to break.But why they changed it no one will ever understand.
It is like the last change to the voice assistant. Instead of integrating the old configuration, they just ignored it.
No you can say it is a software free to use, but that doesn’t change the problem.

Yes, the “solution” is provided in the first post, but to be true it isn’t a solution at all. It is not your fault @petro but still it is extremly frustrating and unsatisfying.
I have two integrations that will fail ZigBee2MQTT and Octoprint. For Z2M they are trying to find a solution but it seems at the moment there is no solution.

All this work and manpower isn’t needed at all, if they wouldn’t have changed it, as everything was running without problems.

[petro]

@Loeffel

Still he is right. The HA core developers changed something totally unnecessary which causes a lot of integrations to break.But why they changed it no one will ever understand.

The core developers didn’t make the change, nor did they enforce it. Would you like me to fire the volunteer who did?

EDIT: I fired him. Not sure if it will stick, seeing that he’s a volunteer and all.

[JRJSmith (Joseph R Smith)]

Sorry Petro, you appear to be taking all of this personally and that is to be regretted.
Volunteers should be able to make the changes that they consider appropriate but there needs to be Change/Release Control to do the following:

1. Ensure that the changes are necessary and work without unnecessary impact
2. Are NOT just pedantic changes, which are unnecessary (other than to satisfy the pedants’ needs) and contribute nothing to the code base.
3. Breaks other contributors’ code without providing them the opportunity to implement changes to their own code to accommodate the proposed change. I acknowledge that you will state that they are being given six months’ notice to this particular change and that would have been true had they been contacted directly by the change developer rather than the users’ being instructed to contact the developer themselves. Again, I appreciate that some of those developers may be the users themselves but I suspect that these will be minority cases.

So, a direct question; what was being broken or was causing failures that necessitated the concatenation of device name and entity name? If nothing, then this is clearly an unnecessary (pedantic) change.

I would like to take this opportunity to thank you for clarifying that the ‘root’ change is not from the Home Assistant Core Developers but from the MQTT Developers. My mistake.

Regards
Joe.

[123 (Taras)]

@JRJSmith

So, a direct question; what was being broken or was causing failures that necessitated the concatenation of device name and entity name? If nothing, then this is clearly an unnecessary (pedantic) change.

The reason for the change was provided on the first line of the Release Notes containing this Breaking Change

The person who implemented it simply made the integration conform to an existing standard.

You can read more about it in post #61.

[parautenbach (Pieter Rautenbach)]

Naming things in programming is often and famously stated as one of the hardest things to get right. It’s not just pedantry. I prefer this way over the alternative where you’d get entities suffixed with numbers, not knowing where it comes from. That’s why the recent changes to have a better relationship between devices, entities and integrations are welcome too.

Let’s distinguish between the necessity of the change and the comms of the change. For me, the change is good. The comms had gaps, but as already called out, Petro very smartly preempted this. That said, even if what’s been stated here was stated verbosely in the release notes, the same yelling would’ve ensued. There’s clearly a strategy by many to just jump in and do and not first to check, read and understand. There’s lots of evidence of this behaviour in this thread.

[TheHolyRoger]

This is definitely a change that needed to happen as esphome device names were all messed up between the mqtt and the native api versions and building discovery topics in my other diy devices was painful too.

I have a painful road ahead to fix everything though

[dimkin.eu]

This stops working in version 2024.2.0. Please address before upgrading.

this one sounds pretty scary. So will it ( who exactly ) stop working or not ?

[petro]

The main post covers exactly what you’re asking. Read it in it’s entirety.

[luma]

Here’s a question: what about backwards compatibility? If I push out this change to my users (specifically, removing the device name from the “name” field), what impact would this have on naming for users who haven’t upgraded to the current HA release?

In my limited testing, doing so changes the behavior for naming on older releases and the rest of the HASPone project depends on being able to predict the entity names. I think this means I now need to either maintain two releases, one for pre-breaking change HA and on for new HA, or I need to force my users to upgrade.

[petro]

They wouldn’t even notice anything. The autogenerated names in the UI would look the same. New users would need to be on the current version of HA if you’re expecting auto generated names.

But as I’ve said directly to you multiple times, you can suggest an entity_id through discovery by supplying a object_id. EDIT: Apparently I didn’t say it directly to you, I said it to another guy after a few of your posts. Sorry.

[luma]

That’s really helpful! Does that apply to prior versions? Let me be specific here, the HASPone project blasts out several discovery messages on startup, one for the device and then one for each entity that can be controlled. Here is an example of the existing discovery message for the backlight on a device named devhasp:

{
  "name": "devhasp backlight",
  "command_topic": "hasp/devhasp/light/switch",
  "state_topic": "hasp/devhasp/light/state",
  "brightness_state_topic": "hasp/devhasp/brightness/state",
  "brightness_command_topic": "hasp/devhasp/brightness/set",
  "availability_topic": "hasp/devhasp/status",
  "brightness_scale": 100,
  "unique_id": "devhasp-8cce1234abcd-backlight",
  "payload_on": "ON",
  "payload_off": "OFF",
  "payload_available": "ON",
  "payload_not_available": "OFF",
  "device": {
    "identifiers": [
      "devhasp-8cce1234abcd"
    ],
    "name": "devhasp",
    "manufacturer": "HASwitchPlate",
    "model": "HASPone v1.0.0",
    "sw_version": 1.05
  }
}

Today, this creates an entity named “light.devhasp_backlight”. That entity is referred to by name in associated blueprints etc, so any changes to that entity name is going to break the stack. Yeah, I get that this shouldn’t be the case but limitations on blueprint selectors and template functions forced the issue at the time this was developed. It has worked fine for years.

My understanding of the new HA requirements suggest I should change the line "name": "devhasp backlight" to "name": "backlight", which should create the entity light.devhasp_backlight just as before.

However, in my limited testing, I think this also means that prior releases will create that device as light.backlight, and as a result, most of the blueprints won’t work.

Am I understanding this correctly?

edit: reading further on object_id, it turns out this directive goes back a ways and probably can solve this for me. Thanks @petro !

[petro]

@luma

That’s really helpful! Does that apply to prior versions?

seems like you answered you own question. Yes, this works in older versions, not sure when it was added. It may even be a legacy field.

@luma

However, in my limited testing, I think this also means that prior releases will create that device as light.backlight, and as a result, most of the blueprints won’t work.

Am I understanding this correctly?

Yes, but only for NEW implementations. Existing implementations of your system wouldn’t see a name change because you’re using unique_id.

[luma]

Dude this is really helpful

Just to be clear, if I change the discovery packet to look like the following (non-pertinent fields removed):

{
  "name": "devhasp backlight",
  "unique_id": "devhasp-8cce1234abcd-backlight",
  "object_id": "light.devhasp_backlight"
  "device": {
    "identifiers": [
      "devhasp-8cce1234abcd"
    ],
    "name": "devhasp",
    "manufacturer": "HASwitchPlate",
    "model": "HASPone v1.0.0",
    "sw_version": 1.06
  }
}

Should that then result in the created entity being named light.devhasp_backlight regardless of HA version (well, post-object_id HA versions at least)?

[petro]

well, yeah but you’re missing a comma after object_id, and you’d want to just have the name as "backlight". Oh and remove the domain from object_id.

{
  "name": "Backlight",
  "unique_id": "devhasp-8cce1234abcd-backlight",
  "object_id": "devhasp_backlight",
  "device": {
    "identifiers": [
      "devhasp-8cce1234abcd"
    ],
    "name": "devhasp",
    "manufacturer": "HASwitchPlate",
    "model": "HASPone v1.0.0",
    "sw_version": 1.06
  }
}

[luma]

I pressed the heart icon but I’m going to waste everyone’s time here with another THANK YOU! Now to get this going.

[Stefan_U (Stefan Uytterhoeven)]

I just see your reaction.
I don’t use unique ID’s in pyscript. The naming of my entities is unique…
Are we going to have non unique entities? (Apart from the id). Pyscript only works with entity_id, not unique_id.
I hope I 'm wrong about the naming…

[petro]

This change does not affect your entity_id.

@petro

And lastly, this change does not affect the auto generated entity_ids.

@petro

Please read the first post, it explains how you handle this. Also, please understand that Name does not equate to entity_id.

[kerryland]

I updated a couple of days ago and noticed a zigbee/mqtt bulb has stopped working. It looks to me like a naming problem.

1. The UI claims the entity is called light.garage_energy:

2. The zigbee MQTT discovery data refers to it as homeassistant/light/0xa4c13813d36a0ff5/light/config
3. The yaml in the automation calls light.0xa4c13813d36a0ff5. This no longer works.
4. If I add the bulb again via the UI it is now called 69505d59e417ebdfa5be4316822b10f9. It does work – the bulb turns off.
5. If I manually change the entity name to light.garage_energy that works too, which is nice.

Before:

  - type: turn_off
    device_id: c36c5c284a384682037defa16098a328
    entity_id: light.0xa4c13813d36a0ff5
    domain: light

After:

  - type: turn_off
    device_id: c36c5c284a384682037defa16098a328
    entity_id: 69505d59e417ebdfa5be4316822b10f9
    domain: light

I get the impression this (breaking light.0xa4c13813d36a0ff5) is not expected behaviour, but maybe not.

Is 69505d59e417ebdfa5be4316822b10f9 expected?

Should I raise a bug? With what component?

Thank you.

[petro]

The name is still Garage Energy. Because your device is named garage energy and the entity is named garage entity, the UI is hiding the device name on that page. Therefore it looks empty, but it’s really not. If you view this from the non-device page, it will show the full name.