Why ? I don’t do anything for my Zigbee2MQTT devices, I know it will be fixed. I’m more concerned about the other MQTT integrations I hade to write my own discovery messages for.
2 Likes
I didn’t create the issue if that’s what your implying, however I am taking all the backlash. So you will get snark. Sorry.
10 Likes
The changes on Z2M side are already implemented and you can use them by switching to the dev branch.
A few months ago, some changes have been made to Zigbee2MQTT that will result in different entity IDs for various devices classes. _contact will be renamed to _door, _water_leak to _moisture, _occupancy to _motion, _particle_pm2.5 to _pm2.5 and likely a few other things I haven’t discovered yet or don’t own sensors for.
Those changes in Z2M make sense, and very likely also the ones in Home Assistant (although I still don’t understand, what’s really the reason for that change, but I trust the developers that it makes sense.
But when you combine both changes, your entities will be renamed. Your dashboards and automations will break and theres - as of now - no automated way to fix that (if you are willing to take a little risk try sed).
2 Likes
Sorry, that came out wrong and I didn’t mean to imply that this was your change. I was more leaning toward the “looking for solutions” part.
No the existing entity_ids will remain the same. Ha ensures this through the entity registry in combination with a unique_id that z2m still provides (and hasn’t changed). The only entity_ids that will be different are newly added devices. And z2m can still override that by providing an object_id if they choose to.
4 Likes
That does not (yet) seem to work, see Switch, Update, and Light entity warning logs in Home Assistant 2023.8 · Issue #18445 · Koenkk/zigbee2mqtt · GitHub. Around 50 entities have been renamed, causing dashboards and automations to fail.
2 Likes
The update for Z2M hasn’t been merged or provided to HA yet. From what I understand, It’ll be added in Septembers release of z2m
3 Likes
@petro Thanks for all your patience 
. I see you answering questions all the time in the forum and applaud your good work. Hate to add nothing to the issue but felt the need to be human.
11 Likes
The fix feat: Let Home Assistant generate entity name when device_class is present by Koenkk · Pull Request #18208 · Koenkk/zigbee2mqtt · GitHub is already available in the dev branch of Z2M and as such looks fine to me. I also guess the change in HA is fine as the historic changes in Z2M are. But in combination with a long existing smart home they lead into an ugly situation.
Also, as you can see, the fix in Z2M is quite simple and the maintainers were able to implement it very quickly. The September issue seems more like a release management issue to me. Which brings me back to bad coordination: From the outside it does not look like anyone has spoken with the major MQTT “integrations” (I know that’s not the correct wording) before releasing the change in HA to the public.
6 Likes
So we’re throwing error on user installs in order to align with a function of the Z2M project which isn’t out yet, and in doing so, breaking everything MQTT-but-not-Z2M in the process.
Is this really the best solution available? Are there any other future Z2M functions that will force HA to change the MQTT API that we should be aware of? Is there any way for developers of other non-Z2M things to weigh in on the future direction?
2 Likes
You mention the z2m as being fixed come September. Do we notify the MQTT software in the add on store? (Mosquitto broker Current version: 6.2.1.)
Z2m had nothing to do with this change. The code owner of mqtt implemented this change. All you’re doing is speculating. If you want to start discussions about HAs mqtt architecture, please do so in the discussion section of the HA architecture GitHub page. Just be prepared to offer full detailed proposals and don’t go there just to start an argument.
2 Likes
No, you don’t have to do that.
Thanks for the clear and simple PSA. 8 months of notice feels like a ton of time to get this right. Thanks for all your volunteer time, big deprecations like this can be stressful and confusing for everyone. I’m sorry not everyone agrees…
Just to be clear, this isn’t currently a breaking change, it’s a warning about a breaking change coming in April, is that correct? More specifically, MQTT providers who do nothing, will be broken in April, right? I’m tracking a few bugs on a few MOTT provider’s GitHubs’ and seeing some confusion out there, I wanted to clarify before I go start making things more confusing.
4 Likes
Proof of this old axiom:
4 Likes
Unfortunately not, which leads to the important detail that users must update HA before Z2M, see Switch, Update, and Light entity warning logs in Home Assistant 2023.8 · Issue #18445 · Koenkk/zigbee2mqtt · GitHub
In the vast majority of installs this order of upgrade will be the case, but in the rare cases where people upgrade Z2M but not HA, this will likely lead to another case of problems with renamed entities.
Again. I have no doubt that all these changes make sense when looking at them isolated but also it seems like the latest change in HA has not been fully elaborated wrt it’s consequences and coordination with the major MQTT based projects.
2 Likes
Yes. Nothing is broken yet if you update to HA 2023.8 alone.
I think you have a misconception on how this works. Existing entity_id’s will not be renamed at all, it’s not possible as Z2M provides an unique_id with each entity & device. Something else is happening on your system. I just checked out the dev branch of Z2M and not a single entity_id changed (as expected).
3 Likes
The following may be off topic but is related.
After playing around (by publishing faux MQTT Discovery messages) with the new 2023.8 changes and thinking about this some, I’m left wondering what is now considered to be the “Best Practices” for a Device name and an Entity Name?
I’ve read the “Entity Naming Guide” from the release notes, which leaves me wondering what is the guide on Device naming?
What I see looking at a few samples in the core.device_registry, some Device names come from user input somewhere along the way (like “Living Room Light”), whereas other Device names are from the manufacturer (like “Essentials A19/A60”).
1 Like
Some context about my environment:
- My Zigbee network is quite old. Things have changed over the years on both sides of the MQTT broker. A lot of things. Still: Up until now, upgrades always went smooth and all those internal changes how things are handled on either side of the MQTT broker always went smooth without any problems. No magic renames or anything else that broke something. Nothing I can remember at least.
- I regularly (at least once a month, typcially once a week) do updates of z2m & HA if available (via docker-compose). It’s defintely not an issue of skipping months of updates.
- No fancy MQTT broker involved. Just plain mosquitto.
- After the upgrade, I found the deprecation already being reported to and fixed by the z2m maintainers and found the comment Switch, Update, and Light entity warning logs in Home Assistant 2023.8 · Issue #18445 · Koenkk/zigbee2mqtt · GitHub in the corresponding ticket. So yes, I did one other thing than just upgrade: I disabled
Persist cache stateandSend cached state on startupbefore restarting z2m and re-enabled them afterwards. But looking at https://github.com/Koenkk/zigbee2mqtt/blob/f6196107a75f9257366505a3ad5ef7b29ff5bc1c/lib/state.ts I doubt, this has something to do with the problem either.
The renames that happend are in the source (and quite old, so already running in my infrastructure for quite some time without causing any renames): https://github.com/Koenkk/zigbee2mqtt/blob/f6196107a75f9257366505a3ad5ef7b29ff5bc1c/lib/extension/homeassistant.ts#L535
- contact becomes door
- occupancy becomes motion
- water_leak becomes moisture
Of course these old changes are not the cause of the problem that happend to me. Nor is fix: Fix Home Assistant `MQTT device name is equal to entity name in … · Koenkk/zigbee2mqtt@f619610 · GitHub. Nor is the deprecation warning in Home Assistant. Also in combination they unlikely are. I agree, there are other variables in this bug that contributed to it happening. Which? I don’t know.
I have no idea what happened, but it happend. I’m a bug magnet. I crash the pump when fueling my car. Literally:
Often I understand enough of the systems involved to file a proper bug report with reproduction instructions. Unfortunately not this time (and not with the pump either). I’m done renaming my entities and thus likely can’t bring more light into the possible causes of this issue other than providing information about my enviroment and what the steps were to trigger this bug (see above). While fixing this, I restarted home assistant a few times, so unfortunately no logs are available on that side. On the z2m side, I have logs, but those look unsuspicious.
The z2m ticket reads like others upgraded to the dev-branch including the fix without any problems. If we are lucky, it’s just a “pump issue” that happens once in 100 million times.
1 Like