PSA: MQTT Name changes in 2023.8

[Brandon_Beierle]

OK, so in April new devices will still be autodiscovered and function properly, even if they supply an entity name that is the same as the device name, but the friendly name within HASS will be doubled (eg. “Bedroom Light Bedroom Light”). Meanwhile, devices already existing within HASS will be similarly double-named automatically, but the entity IDs will not be changed. Is this correct?

That is perhaps inconvenient but it means devices that aren’t updated can still be used in HASS. I think that is what everyone (outside of Z2M) is worried about - that things will just stop working (eg. an MQTT-based light switch will no longer turn the lights on and off from within HASS) in April without updated integrations or (in some cases) updated firmware, and/or that automations, scripts, scenes and everything else that relies on Entity IDs will break and need re-coding.

The details are important to understand because even if it won’t break devices that already exist within HASS, people with MQTT devices using now-unsupported integrations or from devs/companies who don’t have time or motivation to fix their code would be put in a position that if they ever have to re-install anything it might not work anymore. Everyone has had the legacy server in the corner that they don’t dare touch because they can’t rebuild it - I don’t think we want to put HASS users in that position. This kind of change is also problematic for the Works With Home Assistant program - having the badge is a liability if compatibility is a moving target.

Sorry you’ve had to bear the brunt of people’s frustration, and thanks for taking the time to help with everyone’s queries.

[petro]

@Brandon_Beierle

OK, so in April new devices will still be autodiscovered and function properly, even if they supply an entity name that is the same as the device name, but the friendly name within HASS will be doubled (eg. “Bedroom Light Bedroom Light”). Meanwhile, devices already existing within HASS will be similarly double-named automatically, but the entity IDs will not be changed. Is this correct?

Yes, this is correct. The name will be duplicated in the entity but the entity_id will remain unchanged.

@Brandon_Beierle

That is perhaps inconvenient but it means devices that aren’t updated can still be used in HASS. I think that is what everyone (outside of Z2M) is worried about - that things will just stop working (eg. an MQTT-based light switch will no longer turn the lights on and off from within HASS) in April without updated integrations or (in some cases) updated firmware, and/or that automations, scripts, scenes and everything else that relies on Entity IDs will break and need re-coding.

No, that’s why I stressed in the original message:

@petro

There is nothing to worry about, your names are safe.

@petro

Again, during this whole transition period, your names and the default device names should not change. Please keep us informed if they do change.

@petro

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

There’s only so much reassuring I can do.

[bschatzow (Bill Schatzow)]

Thanks for the clarification. Your statement says that I will not get double names next April. If this is true, why am I seeing the errors in the logs if they are not an issue? Shouldn’t new stuff found after this release show up as errors?

The more I read on this the more confused I get. What else is new!

[petro]

please understand the difference between entity_id’s and names. Also understand that there’s auto-generated names and names set by you. Entity_id’s are not changing at all.

Auto-generated names after april will be double if your upstream software does not remove the device name from the entity name. Names set by you will remain unaltered.

And for clarification. Name is this:

[templeton_nash]

I think that @petro should be on the Nabu Casa payroll. The time @petro has spent dealing with this!

[123 (Taras)]

@templeton_nash

should be on the Nabu Casa payroll

Last year I thought the job position was filled: 2022.6 Gaining new insights!

Also: Hi Jacqueline Raaflaub! Jacqueline has joined Nabu Casa; she will help out with support and assist in moderating our community. We are excited to have you, and welcome!

However it appears I have misunderstood the job’s responsibilities because the lion’s share of support in this community forum has always been, and continues to be, provided by a (small) group of regular volunteers.

If not for petro’s many contributions, and those of other prolific contributors, it’s not hard to imagine how frustrating an experience it would be to use Home Assistant, especially after a new release.

[nohn (Sebastian Nohn)]

A likely more successful way would have been notifying API consumers beforehand via push (for example a ticket in their repo). “Heads up: We are going to deprecate $api on $date1. On $date2 the old API will be dead. While there is plenty of time until $date2, we advise to update you software until $date1, so both of don’t confuse our users and reduce support effort and avoid duplicate or bogus bug reports.”

If everything would have went well, by $date1, z2m, espresence and whoever else would already have updated and only a small number of users would have seen the deprecation warning. Best case - and yes, software development is not a democratic process but results often are better if both sides of the API communicate before APIs are changed - things could have been implemented even better than they are going to be next year.

[petro]

We did. But that’s the problem with MQTT, there’s so many users & providers that many get missed, hence the warnings in the logs.

[mcsmark]

I have read the complete thread. It is still not clear to me. I use some tasmota sensors. The entities are shown in my warning : sensor.plugrf_status And as i understood i could fix it by changing the name. So i change the name but after a reboot i still see the same warning.

• if i click it away, will it come back after a reboot? or how can i check the issue if fixed?
• i checked all config options of tasmota but i see no option or way how to fix. i can specify a name and friendly name. I gave them both the same name. i wonder must i fix it in tasmota? or do i need new firmware?
• must i change some other setting?
• as i understand it i can click away the warning. but as renaming the name did not have much effect i wonder how i fix this?
• the warning just links to a short blog that gives not much of a clue of what need to be done exactly, and where, nor what will happen i the future. if i understand petro correct nothing bad will happen in the future.
• how can i restore my previous version? i always make a backup but i see no simple option on how to go back to the previous version.
  i respect all the hard work but i am a simple user, it simply need to work without me fixing things when i update.

[HeyImAlex (Alex)]

@petro

Nothing is good enough.

Because breaking changes are almost never a good idea. They’re an absolute last resort if all other possibilities are exhausted. HA is the only software project I am involved in (both open and closed source) that throws breaking changes around like they’re candy.

This one is particularly strange. Official communication around it has been cryptic at best, as is evident by the many concerned users posting here. It seems completely unnecessary, as it’s basically around enforcing a naming scheme. If you ignore it entirely (even as an MQTT developer), then by 2024.2 nothing is going to break at all. You just get some strange named entities. Or are they planning to actually validate their naming scheme from that version on and entity creation will fail if it doesn’t follow the scheme ? That would be completely insane, but by now I believe anything is possible with HA…

[petro]

I figured you’d disagree, can’t have a controversy without an armchair dev opinion. Please, partake in the discussions in the HA architecture github if you feel strongly about how things are handled.

[HeyImAlex (Alex)]

@petro

armchair dev opinion

Nice. Good to know how you think about me. I’ll make sure to not bother you with my armchair dev opinion anymore.

[petro]

Well, you’re always there with an opinion on every single heated thread… whether it affects you or not… Cant fault me for making an observation.

[HeyImAlex (Alex)]

My entire home automation system is based on MQTT. A lot of my MQTT data comes from drivers I have written myself. I’ll let you do an educated guess of whether or not this change affects me.

@petro

Cant fault me for making an observation.

When an ‘observation’ is a thinly veiled shell around an insult, well, yadda yadda. As a moderator, you should know that.

This is not the thread to discuss this. I’m out.

[petro]

I’m not familiar with Tasmota. From what I understand the device handles the discovery, therefore I would assume a new firmware version of Tasmota would handle this. Maybe someone else can answer that.

[XcOM9876]

I can see this has gotten very heated, and to be honest I don’t blame the likes of Petro being they way they are.

All they’ve tried to do is explain the issues people are seeing, but on the flip side as much as this has been communicated it doesn’t appear to have been done so in a way that the majority understand.

I’ve seen the changes, I read the changes, I thought I understood them before I updated, apparently not as I found this thread when searching for the new warnings I saw.

These updates were communicated out where people would see it, but personally I feel that it wasn’t clear before the update went out what breaking changes are, what they are attempting to fix/prepare for, and what needs to be done.

I think I know what it means going forward, but at the same time I am not sure if things will just fail to function or register if they don’t meet the new naming structure.

I think they will, but that’s not been 100% confirmed, if I understand this change correctly, things such as Zigbee2MQTT in future can’t supply the device name in a way which HA doesn’t like, I won’t admit to understand any of this, I presume it’s all under the good because for example this item from Z2M flags as not compatible

I don’t know why, I don’t know how to change this, I just have to wait for Z2M to update and hope none of my entity ID’s change and/or my automations break.

I think everyone needs to step back as it’s getting heated in both directions, and maybe HA make a formal statement going in to detail why this change is taking place as joe blogs doesn’t understand why, and what needs to happen, and what the risks are if things aren’t updated (IE will things continue to work but have a strange name?, or will they outright break)

[petro]

Please fully reread the first post. It covers everything you as a user has to do. It even covers what will happen with your entity_ids.

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

I think the notification in this manner is just fine actually. I am not a dev, but I share a dozen blueprints including some that create MQTT entities that are affected. If this were a separate dev only notice I would not have known. I now know what to fix and there is 6 months to do it. Not a problem.

Linking this thread in the breaking change would be a nice touch as the explanation is better detailed here…

NOTE:
(update 6 days later, mine are fixed…)

[francisp (Francis)]

@mcsmark

I use some tasmota sensors. The entities are shown in my warning : sensor.plugrf_status

Depending how many you have, probably the easiest way is to upgrade the firmware, and change from the MQTT integration to the Tasmota integration (setoption19: 0)
Be sure to follow the correct upgrade path :

Upgrade Flow~

v1.0.11 v3.9.22 v4.2.0 v5.14.0 v6.7.1 v7.2.0 v8.5.1 v9.1 Current release

Upgrading - Tasmota

For me, I still over 30 devices that are still on Tasmota 6.6, and some that are stuck at 8.0
it is the third breaking MQTT change

First the change in lights. Instead of upgrading them all (which would have been a days work), I just copied the discovery messages from MQTT Explorer, created a script which published the copied message, but with I thing val_tpl changed to stat_val_tpl. All errors gone.

Then some HA versions ago, there was the error about begin TotalStartTime being a string and not an int.

Same fix, but this time remove the unit_of_measurement from the offending discovery messages

This time, I’m doing the same again for the offending discovery messages.

[martingale]

This is the kind of change that could only be released by a bunch of software engineers who lack appropriate product oversight, which is I guess likely with open source software.

This is a train wreck. The clueless devs are like deer caught in the headlights totally unclear what the problem is.

I imagine they think it was ok to push this because a fix is coming, there’s a workaround, the warning can be ignored, the user can manually fix the problem and a bunch of other truly clueless things.

No thought from the perspective of a customer. No interest in a pleasant experience for people using the system. No worry about how it might be seen from other people’s perspective. Clueless introverted myopic thinking.

Did it occur to you that EVERY SINGLE USER is going to have to halt what they are doing and go search the web to find this thread and wade through an arcane technical discussion to try and figure out what this means? And still likely not know what it means or whether it’s safe to install.

Shape up if you want to be taken seriously. It’s supposed to be stable software now, this is completely unprofessional and causes absolutely everyone to lose trust in your ability to manage this project.