Just that?
but if I don’t want? how can I do to fix this “naming thing”?
Yes. Just that. It’s not a thing for end users to fix… If you’re not writing your own integrations or building a bunch of MQTT devices manually. There’s nothing for you to do - hit ignore.
1 Like
The dev branch of Zigbee2MQTT already contains the proposed fix for that and make the warnings go away.
Thank you all! 
…at the beginning I thought I had to manually rename all entities, fortunately it is not so 
So i Understand that i have to nothing so far. And that I don’t have Fear about nothing works after April 2024.
BUT since the update some Automations with my Aqara Switches doesnt work. If i Triger a light wether it is ligt or switch it will work fine. If I trigger a Cover if it is a real cover or a Switch triggering a Garage Door unit it will not work…
If i trigger the same things with a Philips Hue dial everything is fine…
Am i right here ? I have openend an Issue the developer of the aqara Blueprint too…but i don"t know if a blueprint can be broken by an update
Then your problem is unrelated to this and you should start a new topic. This existing topic may be relevant and you should read it first though.
Also, for all the users not happy with how this was handled, Nabu-Casa hired a Product Manager a week ago to handle and anticipate customer issues like this in the future.
Things should go smoother when this person is more involved in the product release loop and the team finds their flow going forward.
In the meantime on this issue, just push ignore…
8 Likes
What is the impact on ESPHome?
Currently, I have several remote ESPHome devices connected via MQTT. The entity names for those devices are prefixed with the device name and I am getting similar messages this time.
Should I change the entity name in ESPHome and update the firmware for these existing devices?
1 Like
I agree that this has been handled really poorly. In the end, this wasted a lot of everyones time, but no big issues coming out of this. I hope Nabu Casa learns from this for future releases. And thanks to @petro ro for clearing stuff up.
2 Likes
Hrmm. z2m was supposed to be unaffected, yet somehow mine has had it’s guts fall out.
All my devices (bar one) have disappeared from the z2m dashboard. The remaining one has lost it’s configuration.
I’m not sure what happened. Perhaps not entirely related to this change.
I installed 2023.8, noticed that my SleepAsAndroid MQTT (and HASS AGENT, I think) stopped working, so attempted to restore a backup. Which failed for whatever reason I didn’t catch.
So I decided to be patient and let them be broken for now, and went ahead installing 2023.8.1. After which I noticed the above issue, that my entire zigbee network was essentially empty from within z2m (edge branch, last updated who knows when last year).
The devices/entities for the missing z2m devices all appear within my mosquito broker with This entity is no longer being provided by the mqtt integration. and I no longer get the repair warning list containing these devices.
No idea what caused this, or if it can be quickly fixed. Restoring a backup of the add-on did not resolve the issue. I have to assume that my zigbee co-ordinator itself was wiped somehow? Rebinding, naming etc several dozen zigbee devices is going to be a nightmare.
I wonder if anyone else has experienced a similar problem.
If they have disappeared from the z2m dashboard, it has nothing to do with name change.
Do you have older backups ?
2 Likes
That is unrelated to this change. Whatever your problem is it’s entirely within Zigbee2MQTT and you should start a fresh thread.
2 Likes
Yeah my apologies, figured that might be the case. Posted just in case I was missing some linking cause, as updating to 2023.8 was the initiator for my problem to appear.
I was also worried about this change and have a lot of (now ignored) warnings.
But I upgraded the MiFlora-mqtt-Daemon (GitHub - ThomDietrich/miflora-mqtt-daemon: Linux service to collect and transfer Xiaomi Mi Flora plant sensor data via MQTT to your smart home system, with cluster support 🌱🌼🥀🏡🌳) and the warnings for MiFlora sensors were gone after a restart of HA.
Now waiting for an upgrade of Zigbee2MQTT
My ¢0 this topic. The HA announcement and warning itself are far from clear and MQTT docs are not updated at all. And this is the ONLY complain from me.
I run my own MQTT device with discovery, so I googled around and found this topic. It makes everything clear but only if you can ignore most of whining. It looks like only handful users actually understand the case.
For me the change is very logical and welcome. It makes device name important and part of entity name but also removes some unnecessary duplication. It is also well engineered as it doesn’t change any existing entity id (unless discovery message shows it like a new device).
I don’t understand users who call HA developers to let device developers “fix” their software beforehand. You can’t change MQTT discovery messages before HA change without big negative impact in entity names. Think about it and you can figure out yourself (or read along) what would happen in this case.
Only possible problem I see here is with users who don’t upgrade HA. After MQTT discovery message change in their devices (or running newer version of Zigbee2MQTT or other software), their entity naming for new devices will be quite bad because HA versions before 2032.8 didn’t add device name to the entity name.
Assume your device name is “Device” and sensor name is “Sensor”. Depending on version of HA and MQTT discovery message, this is what happens:
- Old MQTT, old HA:
sensor.device_sensor - Old MQTT, new HA :
sensor.device_device_sensor← this is what a warning is about - New MQTT, new HA:
sensor.device_sensor - New MQTT, old HA:
sensor.sensor← this is what happens when other devs change before HA
Now when you are in the last combination all your new temperature sensors will be just temperature_2, temperature_3 and so on with all called just “Temperature” instead of kitchen_temperature or shelly_livingroom_temperature.
Sorry for this long post.
7 Likes
I’ve read the entire thread however I just want to be clear as 99% of everything in my house is MQTT.
All of my MQTT entries are manually defined like:
mqtt:
light:
##################SHOP INTERIOR
- name: "Shop Light South"
state_topic: "/shop/r7_s/"
command_topic: "/shop/r7/"
payload_on: "1"
payload_off: "0"
qos: 0
retain: true
- name: "Shop Fab Light"
state_topic: "/shop/r6_s/"
command_topic: "/shop/r6/"
payload_on: "1"
payload_off: "0"
qos: 0
retain: true
So this does not effect me because I don’t use any MQTT autodiscovery?
It affects you if you make devices in YAML, otherwise, No. When I say devices, I mean devices: in the literal sense, not your YAML MQTT entities.
1 Like
I think I’ve corrected all my devices that publish HA discovery messages to MQTT. After I’ve clicked ignore for the warning messages, is there a way to retrigger the check to confirm I’ve fixed them correctly?
Wel, I took action. Tried to restore full backup from before the upgrade. Didn’t work. Took me a full day to get it up and working again. Was not amused!