MQTT device name is equal to entity name in your config error in Home Assistant 2023.8
#18445
Comments
|
It's not just the |
Yup, you're right! Looked deeper into it and I see that the name is also repeated for switch entities without appending the descriptor. So, based on my setup I can confirm that update and switch entities are affected. From your log it appears that light entities are also affected. |
RobertD502
changed the title
|
I had not seen this, but my HA log does not shows warnings, only errors. |
|
Not only update entities indeed, all names seem duplicate now: |
@tjorim For example, for my Lavviebot litter box integration, the device name is Litterbox and the Humidity sensor entity name is "Humidity". On the device page, the entity is listed as "Humidity": 
However, when I click on the entity, the friendly name is shown as "Litterbox Humidity" due to how naming is handled in Home Assistant: 
If you want to customize the entity name from the Zigbee2MQTT side of things, although it requires some manual work, you can do so by checking out the documentation here. Hope this clears up some things. |
|
I updated my home assistant to 2023.8.0b3 this afternoon and those 2 warning messages appeared. |
|
Could you check if this is fixed by #18208 ? This is available in the dev branch now. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html) |
|
@Koenkk Nope, still logging the warning. Example: With their temporary fix of stripping the device name from the entities that have a name of The additional warning that is being logged now, on top of the original issue that we are facing with entities that use just the device name as the entity name, was introduced by this change. |
|
Merged another fix, could you check if it works? (Wait 1 hour before updating to make changes are build and published) |
|
Out of curiosity, after taking a quick look at the changes, any reason for choosing not to capitalize the entity name? For example, using Battery instead of battery. For entities with multiple words, only the first is capitalized (e.g., |
|
Yep, fixed on 1.32.2-dev commit: f619610 |
|
@Koenkk Running I've restarted the broker and Home Assistant, but the issue still persists. |
|
Can you confirm those timestamps are close to your actual time? Asking because they're hours away from my timezone, but also minutes from now (if you disregard timezones) and I actually was looking at old logs just a few minutes ago as well. It appears that the system log page isn't fully cleared during reboot with the HA window open - a caching issue in the HA frontend. I have no errors anymore from Zigbee2mqtt entities. |
Yes these are up to date logs. Fresh log from the time I restarted Home Assistant (after zigbe2mqtt was pulled and up and running). edit: Example after another restart: Regarding caching issue: As long as you reload the website (in your browser, not the reload button on the log page), the log page will be refreshed and up to date after a restart. No need to empty cache. |
|
@Koenkk Indeed fixed! @hmmbob's discussion regarding Home Assistant cache made me remember there are caching settings within Zigbee2MQTT. By disabling |
We tried to do this, but then reverted the change. #16702 @Koenkk Is f619610 a breaking change for HA users lower 2023.08.0, right? |
It looks like it was shot down because the way of handling the naming in that PR was too uniform in the sense that all names will only have the first letter capitalized which isn't always the case (as seen in the VOC example: Voc if the name is voc to begin with). However, you were indeed correct about how the entity name should look like. The capitalization or not of the first word isn't a breaking change / not what this issue is about - I was just raising the capitalization discussion as a secondary question since the naming is being worked on at the moment. You could have an entity named |
|
@Drafteed this is indeed somewhat breaking but there is no way we can prevent it (we don't have control over what HA users are running). I will put it as a note in the next release notes. Assuming this can be closed now. |
|
@Koenkk what do think about my last suggestion in #16702? I propose to introduce a new property |
|
It seems like the change breaks a lot of sensors. I have many https://www.zigbee2mqtt.io/devices/MCCGQ11LM.html#xiaomi-mccgq11lm installed. Those provided a balbalba_contact entity that now seems renamed to blabla_door:
|
|
A downgrade to latest does not fix this. Entity stays named _door. |
|
I did. Context from documentation:
|
For me this (as well as the upgrade to version 1.32.2 / 1ec1e57) did not solve the issue with those warnings. I still get the "MQTT device name is equal to entity name in your config" for a lot of entities and the one aka "MQTT entity name starts with device name" for even more entities. Don't know if this could be related or the cause: for many devices I set a custom name in zigbee2mqtt (frontend) with the toggle "Update Home Assistant entity ID" enabled. |
Fix will only be included in the release of next month. |
It is fixed in the image tagged "latest-dev". Changing the name in Home Assistant doesn't fix the issue because the naming is caught upstream - although you change the name in Home Assistant, this doesn't change the entity name that is sent in the MQTT message, which is what triggers the exception in Home Assistant. |
I didn't change the name in Home Assistant, but in Zigbee2Mqtt directly. And because this actually reduced the amount of warnings in Home Assistant I was confused and thought that 1.32.2 should already contain the fix. I'll try it with the dev version or with the next release. Thx! |
Ah. If you changed the name via the UI, then you either changed the friendly name or device name. With 32.2, the MQTT messages would still prefix the device name to the entity name. Only way, that I know of, to manually circumvent the errors in 32.2 is to manually name each and every entity for a given device within the configuration file. If you have a lot of Zigbee devices, this would take a while. It's a lot easier to just change your image to "latest-dev". |
@Koenkk No, but if you remove a device or entity from HA and add it again, it will be added with a new HA |
Z2M sets the
However if the name just changes when you remove the device from HA an add it again, I think we should not consider this as a blocking issue. |
|
Hi, just switched to z2m (was using deconz before), should I use dev branch to configure my lights or can I just use the release? I named all my lights in z2m with following pattern: ie: kitchen.light.1 or kitchen.switch.1 |
|
It is still a bit confusing if it's OK to wait for the fix or take action now and what to do exactly, I have 320 entities reported with warnings across 30+ devices. Since all is working now and 2024.02 is a few months away should we assume it's likely to be fixed by the end of the year? |
|
I am wondering the same as @outlying Do I just keep updating to stable z2m and suddenly it will fix itself or am I to manually edit hundreds of entities/scripts etc? |
|
as stated numerous times before, it's already fixed in the next release: 1.33.x. You can use it already as part of the Edge version of the z2m add-on if you want but there's absolutely no real NEED for that, apart from cleaner logs (I temporarily switched over just for this), as the issue will be automatically solved at the next z2m go-live, end of this month. There was no need for me to change any scripts/automations etc, as HA is gentle enough to make the current issue invisible, up to release 2028.2. And after moving to the Edge version, all kept on working as before as well. I did have to do the z2m cache disable/enable actions as described above but that was a once-off. Maybe it would be good to have this actions build it into the next update, to prevent all 1000s of installations to have to do it manually. If not, it's not a problem either, it just would be nicer/cleaner. |
|
For Dutch users who search for clues to this problem: Home Assistant reports this problem as "Ontdekte MQTT entiteiten met een naam gelijk aan de apparaatnaam". |
|
So after updating everything and restarting etc etc (no error logs) I now end up with Zigbee devices that use the sensor type in the friendly name, like:
The worst part is that Home Assistant puts Is this really the solution, or am I missing something very obvious? Because this feels like an extremely bad solution having to manually change these things in order to not have a duplicated name or wrong sensor type names? |
|
While this is solved now largely with the updates from Home Assistant for all Zigbee devices, I still get the warning below, which is about not adhering to the naming conventions for the Z2MQT bridge states, version and health. As I can not change the name, how can I get rid of these warnings? MQTT entity name starts with the device name in your config {'name': 'Zigbee2MQTT Version', 'unique_id': 'zigbee2mqtt_version', 'state_topic': 'zigbee2slzb/bridge/info', 'value_template': Template<template=({{ value_json.version }}) renders=0>, 'icon': 'mdi:zigbee', 'entity_category': <EntityCategory.DIAGNOSTIC: 'diagnostic'>, 'device': {'identifiers': ['zigbee2mqtt'], 'name': 'Zigbee2MQTT', 'model': 'Zigbee2MQTT', 'manufacturer': 'Zigbee2MQTT', 'connections': []}, 'force_update': False, 'payload_not_available': 'offline', 'qos': 0, 'enabled_by_default': True, 'payload_available': 'online', 'availability_mode': 'latest', 'encoding': 'utf-8'}, this is not expected. Please correct your configuration. The device name prefix will be stripped off the entity name and becomes 'Version' MQTT entity name starts with the device name in your config {'name': 'Zigbee2MQTT health', 'unique_id': 'zigbee2mqtt_healty', 'state_topic': 'zigbee2slzb/bridge/response/health_check', 'value_template': Template<template=({{ value_json['data']['healthy'] }}) renders=0>, 'icon': 'mdi:zigbee', 'entity_category': <EntityCategory.DIAGNOSTIC: 'diagnostic'>, 'device': {'identifiers': ['zigbee2mqtt'], 'name': 'Zigbee2MQTT', 'model': 'Zigbee2MQTT', 'manufacturer': 'Zigbee2MQTT', 'connections': []}, 'force_update': False, 'payload_not_available': 'offline', 'qos': 0, 'enabled_by_default': True, 'payload_available': 'online', 'availability_mode': 'latest', 'encoding': 'utf-8'}, this is not expected. Please correct your configuration. The device name prefix will be stripped off the entity name and becomes 'Health' |
Am I the only one having this issue? If so, what can I do about it? |
|
Running 1.34.0-1 with HA 2023-12 and still seeing these messages, hundreds of them. I found them after troubleshooting a hue bulb going unvail in HA after 2 minutes, but controllable in Z2M. As well as an Aqara TVOC sensor not updating values in HA. I figured this error message could be attrib to the problems I was having. Interestingly, all of those reports only mentioned devices that worked reliably in HA and Z2M. I re-paired the TVOC to Z2M a couple of times and it seemed to clear up both that devices update lag and the hue bulb going unavail. At least for the last few hours now. |
If you have |
|
This is a good tidbit to keep in mind! THX. |
|
***perhaps this should get moved to it's own thread. I'm not positive that there is any relation to what I am seeing here and the naming issue Well, I'm back to the disappearing Hue bulb. It was working fine for a while, but then I went and did the 2023.12.1 update, and both the Hue and the Aqara TVCO are awol in HA. I can see them and control them in Z2M but HA shows them unavailable. I've deleted them in HA, shut down Z2M and restarted Z2M. They pop back up again but immediately go unavail. I've made sure that all the cache in Z2M is disabled. I checked each device and made sure the cache was also unchecked. I considered my wifi could be causing a problem and changed AP's channels and power output. I've deleted the bulb again, renamed it in Z2M and then cold restarted Z2M. Still, it's the same thing every time. HA finds it and adds it and immediately it's offline. I have no idea what I need to check or do next to troubleshoot this!!! Any ideas? PS, All my other devices are working perfectly while this is all going on. I have door sensors, motion sensors and AC plugs. All working without an issue. It's just these two items that are not playing nicely. |
|
I recommend opening a new issue or seeking guidance on the Home Assistant community forums since the issue you are experiencing is not related to the one this issue thread is about. |
|
What steps do I need to do to fix the issue, its still present here. Also disabled and restarted: "Persist cache state and/or Send cached state on startup" already but that didnt solve the issue. Do I need to change the mqtt device names or zigbee home automation device names? Thx |
Use a program such as MQTT explorer and delete all topics created by Z2M. There could be some things retained there that are causing your issue.
Once all topics are cleared out, restart Z2M and re-enable the options if you want to. |
What happened?
A breaking change was introduced in Home Assistant 2023.8 involving naming of MQTT entities which affects update entities exposed by Zigbee2MQTT.
The following warning is logged by Home Assistant:
As you can see, the update entity name is the exact same as the name provided for the device name (for the device registry). As a result, this warning is being logged for all update entities.
By the looks of it,
update entity is the only one thatswitch, update, and light entities are not currently setting the name of the entity in the form of {Device Name} {entity descriptor}.Disregard, entity name should only be of the descriptor like "Humidity" or "Temperature".For example, the energy sensor entity for my outlet has an entity name ofDisregard, entity name should only be Energy for this entity.Eagle Outlet energywith a device registry name ofEagle Outlet:However, the update entity, as seen in the payload below, has its name set to
Eagle Outletinstead of, for example,Eagle Outlet update:Update:What did you expect to happen?
No response
How to reproduce it (minimal and precise)
No response
Zigbee2MQTT version
1.32.1
Adapter firmware version
N/A
Adapter
N/A
Debug log
No response
The text was updated successfully, but these errors were encountered: