Read through this thread… at times quite turbulent. So my take… the error below is nothing to worry about, and will be sorted over time. Anything I missed?
Thanks to Pedro for his help 
Ok, so Z2M is fine. Got it. What will happen to all the other MQTT reliant integrations in 6 months? Will they break or just throw warnings? Will it just be the entities that are listed in the error messages or everything associated with the device?
Will autodiscovery be broken for the whole device (i.e. It won’t set up at all) or just the entity?
If devs don’t/won’t update their code will devices become incompatible with HASS?
I understand it’s not your decision, so I’m trying not to shoot the messenger, but we really need a clear understanding of what will happen if code isn’t updated.
Editorially speaking this does appear the equivalent of creating a breaking change for the sake of standardizing on the UK or US spelling of the word color, again directed at the decision makers not you, Petro.
1 Like
Nothing will break, it’s just that the names will be duplicated. Your Bathroom temperature sensor will be Bathroom Bathroom temperature until you rename it.
3 Likes
An interesting take on “zero-defects mentality”. Just hide the warnings you don’t want to see 
Sarcasm: just get rid of the logging component completely and there will be no more errors in home assistant ever 
I still haven’t understood the real reasoning behind this. Mostly I’m frustrated, as I have automation also outside HA, working directly with MQTT topics, and I need to modify those well working automations according to this change.
1 Like
I’ve suggested the HASS MQTT Discovery documentation is updated to add examples to explain usage not just syntax, however the preference seems to be for less is more:
Here’s the GitHub issue link so you can also contribute.
I’ve also posted two examples with full values down to units and icons which may help.
2 Likes
Here’s a link back to a speculatitive attempt at understanding how we got here without any internal information:
TL;DR : Tidy up entities, change add-on API, MQTT discovery changes to give “Device Name Device Name” which looks silly, so add user-facing Repair which is for MQTT developers.
The first example only removes that exact log. So it’s not hiding anything but the message in question. Thanks for taking the time to understand that configuration.
I totally understand that.I was just, using sarcasm, illustrating how this is a slippery slope towards something really undesirable.
My vote, perhaps due to lack of better understanding, is for not changing the way entities are named as it was not a problem for the average end user in the first place. Then there would be no error message to hide, and this thread would be unnecessary.
If the change was really needed, for (perhaps internal?) reasons that I do not understand, the way it is handled leaves room for improvement. More specifically so regarding the wording and use of error messages and warnings. If it is not a problem and is never going to be, it is not a “WARNING”-level logging message. If it is or will be a problem that the user needs to fix, then it is a WARNING and it should thus not be hidden.
2 Likes
It’s not really a slippery slope at all, the member asked how to remove the warning from his logs and I provided a solution.
I’d like to remind you that open source does not mean democracy, especially when one party doesn’t understand the underlying system. There’s api changes all the time in open and closed source software. This announcement was made (with a 6 month grace period) so that everyone can catch up with the api changes. There’s no voting on that, adapt and move on like we all did during the beta. Harping on this doesn’t help anyone and it won’t change the outcome, sorry.
It will be a problem in 6 months. Again, the warning is to get the message out to all people who are using MQTT discovery with devices and entities. I’m sorry that you hand to click an ignore button, I’m sorry that you had to update your entity names to not include the device name. Keep in mind that the ending result of the entity_id and name is identical in this situation, so most users won’t even see any change unless the discovery providers fail to update their code within the next 6 months. Lastly as I’ve said many times before in this thread, there are building blocks in MQTT discovery that can completely get around this if the discovery providers offer an object_id.
2 Likes
It seems I already have that happening with my devices in the 08 release - so is that the worst of it?
The last time there was a breaking change with MQTT, around a key name in autodiscovery of lights, all those devices stopped working in HASS.
All the documentation around this latest change says ‘this’ stops working in April, without saying what ‘this’ is - if ‘this’ is just the concatenation and your entities will be double named that’s very different from ‘this’ meaning devices that supply an entity name on discovery will not be set up in HASS.
It’s not different. The result of the double names is because the name exists in both the device and entity. You have to stop supplying the device name in the entity name so that you won’t have double names come April. Also keep in mind, you’ll only get double names in April for newly created devices, existing names are already in the system and won’t be altered.
3 Likes
Genuine question, I can see why this is being done, but how would someone name multiple entities that have similar names?
For example I have sensors for soil moisture, each one is named the plant/veg bed that they are monitoring, so in this example I will have on called Plant bed 1 and one called Plant Bed 2 which creates sensor.plant_bed_1_soil_moisture, and one called sensor.plant_bed_2_soil_moisture, if I am understanding this correctly in future I won’t be able to have this?
The same holds true for sensors around my house, or in servers, pretty much every single MQTT device I have flagged in the logs but when I check the entities, yes they have the device name in the entity, but that actually makes sense to have sensor.living_room_tempreture or binary_sensor.living_room_door
I have tried reading the documentation linked from the breaking changes but it only references friendly names, not entity/sensor ID’s.
This for example is not allowed:
But what else am I to name it or rather what will it be named based on the new naming convention?
I think you’re over thinking it. Just name the device Firekeeper, and your entity will be named CPULoad. The result will be sensor.firekeeper_cpuload with a name of Firekeeper CPUload. But seeing as your entity already exists, nothing will change if you remove Firekeeper from entity name, meaning your existing entity_id will remain the same. Secondly, don’t keep the leading _ when you update your entity name. Keep in mind that these are the names of the device and entity, which leads to the suggested entity_id. You can overcome that by providing an object_id.
Lastly, suggested entity_id’s are only provided when you first add the device. From that point forward, you can change or keep the entity_id and any other incoming entity suggestions are ignored because the config entry already has a static entity_id. This is what’s keeping this from being a breaking change for users, because their existing entity_id’s will not change.
2 Likes
Hi,
yesterday I updated to 2023.8.0 and got two MQTT related warnings, that seem to touch hundreds of my MQTT entities. I also got the warning, that in the upcoming release 2024.2 everything probably gets broken then.
That would be disastrous to my Home Assitent setup, with hundreds of sensors, dozens of scripts and automations. I habe build my setup throughout years.
If I understand the warnings right, my entities have to be renamed or a renamed automatically?
So everything that with reference to those entities gets finally “broken”? At least in the upcoming release 2024.2?
I have attached two screenshots of the warnings.
The warnings are in german, so I have translated them:
Warning 1 MQTT:
Some MQTT entities have an entity name that starts with the device name. This is not to be expected. To avoid a duplicate name, the prefix of the device name is removed from the entity name as a work-around. Please inform the maintainer of the software application providing the affected entities to fix this issue.
List of affected entities
Warnin 2 MQTT
*Some MQTT entities have an entity name that corresponds to the device name. *
*corresponds. This is not to be expected. As a work-around, the *
*entity name is set to “null” to avoid a duplicate name. *
Please inform the maintainer of the software application providing the affected
- Entities to fix this problem. *
*List of affected entities: *
update.pump_heating_basement
switch.deco_staircase_eg_og1
light.0x00178801034d4c19_light
I’m really more than uncertain how those reports/messages to interprete und very unsetteld about that matter…
I would be very thankful for some clairification. If I had really to rename or reconfigure everythin cause of renamed entitites it would be catastrophic…If that would be the case, the effort would be the same as reconfiguriung everything from scratch…
Thanks and good weekend…
1 Like
Please read the topic post in this thread. Thank you.
2 Likes
I have not claimed that it is a democracy. Relax, it is just a way to phrase oneself. I was humble, admitting a possible lack of better understanding. And given this lack of understanding, the obvious choice is to “keep it simple” due to Occam’s razor. I.e. if the end result is going to be the same, there is the easy way of not changing and the complicated way of changing and upsetting a lot of people that would have to “adapt and move on”. Thus one should chose the easy way. Again, perhaps due to lack of understanding what the actual point of all this is.
I am aware of breaking changes in API’s. But changing for the sake of changing (i.e. end result is going to be the same anyway) is usually not very popular. That also seems to be true in this case judging on the sentiment in this thread. So I certainly hope that something under the hood will get significantly better thanks to this change.
Obviously the communication around this has not been successful, but I appreciate your effort in this thread although it is not your “fault”; i.e. you’re only the messenger.
1 Like
The communication on any breaking change is never successful. No matter how the information is presented, there’s always the same comments suggesting different ways to provide the information.
We’ve tried developer blogs before the change occurs. No one read them, got upset it wasn’t posted here.
So we started announcing things here in the blog post as well as a developer post. Then, the deprecations weren’t long enough. It was a 2 week deprecation cycle at that point.
We started with a 2 release deprecation process, which at the time was about 1 month. That wasn’t long enough.
We moved to a 1 release a month (with a week long beta prior to the release) strategy with a 2 release (about 2 months) deprecation process, that wasn’t long enough.
We are now at a 6 month deprecation process and the change is automatically adjusted under the hood. And now, 6 months isn’t long enough and the blog post isn’t the “proper place to communicate”.
See the trend? Nothing is good enough. There’s always going to be an upset group regardless of the breaking change. So to me, the communication is A-OK because there’s no point in trying to make a forever-upset-group happy.
18 Likes