search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
73.38k stars 30.64k forks source link

The new concept of working with names has broken "customize" and I ask you to analyze and correct the work of friendly_name. #76678

Closed VikeDragon closed 1 year ago

VikeDragon commented 2 years ago

The problem

After the update to Home Assistant 2022.8.0, the concept of working with names was adopted https://developers.home-assistant.io/blog/2022/07/10/entity_naming/ I ask you to review it and return the ability to set custom device names using the friendly_name props. For unification, you can add and add other ui_name props and implement the ideas of the concept with names through it. Please leave the option of using "customize" and specifying custom friendly_name as described in https://www.home-assistant.io/docs/configuration/customizing-devices/ The integration of Taya has already suffered, in which it is unclear what and what has become relevant and has created confusion in the naming of devices. I want to see a Kettle and a Dishwasher in the list of devices and objects, not Socket 1....Socket584 and Socket 2...Socket 32. I ask you to restore compatibility with the naming model to 2022.8.0. Now many remain or roll back to 2022.7.7 that's why, in the hope that everything will return to normal in a couple of releases.

What version of Home Assistant Core has the issue?

Home Assistant 2022.8.3

What was the last working version of Home Assistant Core?

Home Assistant 2022.7.7

What type of installation are you running?

Home Assistant Supervised

Integration causing the issue

Home Assistant Customize; New way to name entities; Tuya

Link to integration documentation on our website

https://developers.home-assistant.io/blog/2022/07/10/entity_naming/

Diagnostics information

No response

Example YAML snippet

switch.smart_socket_socket_1:
  friendly_name: Kettle # But it is displayed as Socket 1, Why???
  icon: mdi:power-socket-eu
  room: Kitchen

switch.smart_socket_socket_2:
  friendly_name: Dishwasher # But it is displayed as Socket 2, Why???
  icon: mdi:power-socket-eu
  room: Kitchen

Anything in the logs that might be useful for us?

No response

Additional information

No response

elupus commented 2 years ago

While this looks like a bug, why don't you just rename the entities from the gui?

VikeDragon commented 2 years ago

While this looks like a bug, why don't you just rename the entities from the gui?

I have renamed one object out of 5 in a double socket. Socket 1 in Kettle and immediately Dishwasher from customize was pulled up for Socket 2! But for the other three sensors Power, Current, Voltage remained and customize was not applied. And I have 44 such devices, 10 of them are extension cords with 4 sockets. It will be very tedious to rename everything, and the most important thing is that "customize" does not work and it's all self-deception. This is all very similar to a bug, please fix it ...

VikeDragon commented 2 years ago

I understood, I didn't named the entities themselves, they were by default, but I used customize to describe icons and names, apparently the friendly_name described in customize is ignored when defining "naming new entities", and since I didn't set the name for the entity manually, Home Asssistant assigned friendly_name as Socket 1. Please fix this bug and take into value friendly_name from customize

VikeDragon commented 2 years ago

Also want to mention? what if we roll back to 2022.7.7 everything comes back to normal and all objects with custom names successfully receive them

elupus commented 2 years ago

Can you test something for me. On one of the entities that is not getting the friendly name, can you make sure that it does not have a name set in GUI? (Empty out the name box)

VikeDragon commented 2 years ago

no_name Did you ask for this? Am I right?

elupus commented 2 years ago

Ok, that is empty and the customize is not taking effect. Will see if i cam figure out what might be going on.

VikeDragon commented 2 years ago

Thanks! I really hope that everything will be corrected...

elupus commented 2 years ago

So a small heads up. The likely change we are going to do is not allow customize.yaml for things that are fully controllable from gui (name, icon, ..). There is no good way to combine the two since we inherit part of the entity (switch) names from the device they belong to, some places mainly pull its name from the database of entities, which is likely what we want.

I will leave this open until we have concluded this, but i suggest you rename the devices from the GUI since that is the likely course of action needed.

elupus commented 2 years ago

We might apply the customizations to the entity registry instead. So might get it back working as before.

VikeDragon commented 2 years ago

All this is very bad : (I sincerely do not understand why it was impossible to create another props and use the information from it, while ensuring compatibility? Well, there would be a custom name friendly_name and a custom icon friendly_iсon, and under the hood of the application there would be true_name and true_icon, according to which you would build dependencies and internal architecture. I don 't understand why to break customize ... Please comment ...

elupus commented 2 years ago

Partly because customize is mostly going away. It's a legacy method of adjusting names. It will only be maintained to a small extent, and mostly only for custom components that lack the modern way of adjusting these fields.

VikeDragon commented 2 years ago

It's a pity, now I have to re-register all the names through the UI with any change. So I connected an outlet with monitoring - go to the UI and describe the names of 4 entities - switch + voltage + current + power. OK, we did it, and now if something needs to be reconnected to this outlet and here again it is necessary to score everything anew - 4 entity names - extremely inconvenient. And copying the same settings for the same sockets in the file is easier than running around and punching names in the UI, yes, you can do it in the registry - but this is extreme.

elupus commented 2 years ago

Should be enough to describe the device name. The 4 entities should follow.

Rudd-O commented 2 years ago

While I am sad that configuration.yaml and customize ways of doing things are going away, I understand there are good reasons for the change.

The only thing I would truly like is, for a way to script these types of changes straight from a Devops tool like Ansible or Salt. Right now it is very useful for me to be able to set up many things in my HASS using Salt -- but the more stuff moves into core.device_registry / core.entity_registry model of doing things, the harder it becomes to actually configure these things in an idempotent, declarative way. If that was possible, it would be absolutely awesome -- because it would enable truly fantastic labor-saving ways of setting up HASS instances repeatably for customers.

Rudd-O commented 2 years ago

I also want another clarification from https://developers.home-assistant.io/blog/2022/07/10/entity_naming

My integration sets up a single device with multiple media players (all with distinctive names). How should I port this integration to be compatible with this entity naming scheme?

github-actions[bot] commented 1 year ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.