Core: tplink component device name support gone

[marc-gist]

Home Assistant release with the issue:

0.89.2

Last working Home Assistant release (if known):
0.88.0

Operating environment (Hass.io/Docker/Windows/etc.):

Python venv

Component/platform:

tplink

Description of problem:

this config no long works

- platform: tplink
  host: 10.20.10.179
  name: "Back Room"
  scan_interval: 60

only host: is valid entry. Should allow alias or friendly_name or better yet, stick with name as before.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

[amelchio]

The TP Link configuration has changed: https://www.home-assistant.io/components/tplink/

You can now set the name in the UI.

[marc-gist]

I have 10 devices... extremely inconvenient. Why was this removed? Can it not be put back in?

[amelchio]

All devices can be set up in Configuration -> Interfaces, it will take just a couple of minutes to rename them all ... and you don't have to restart.

[marc-gist]

All devices can be set up in Configuration -> Interfaces, it will take just a couple of minutes to rename them all ... and you don't have to restart.

Doesn't answer any of my questions... although i like the idea that they can be renamed in the UI (which I believe has existed for some time) without restart... this is only good for setting up one at a time.
installers or people with existing large number of devices should still have a way to quickly setup in config files.

Another benefit of having them named in config files is quicker to code automations, as my IDE picks up the names for auto complete. Its also a great place to reference when coding (yes, UI can as well, but have to constantly change the filter).

[edit] i am curious as to the reason this "feature" was removed? how does it further the awesomeness of HA?

[amelchio]

I was not trying to answer your questions but to make you see that it is not so bad.

Your point of view is somewhat addressed in https://github.com/home-assistant/architecture/issues/143#issuecomment-461929615

In short, yes it can be put back but someone has to volunteer to do the work.

[marc-gist]

@amelchio thanks for that link... I would be happy to try and implement this; would you be able to point me at some more posts that would help me get started? I'm not new to python development, but have no idea where configuration loading would take place, and how it reads/looks for the name or friendly_name directive. likely a trivial task for someone that has done it before...

My "point of view" has nothing to do with complaining about people volunteering their time to improve HA. Note that sometimes HA people that have volunteered their time shouldn't really be saying... I volunteered my time, so too bad for you, live with what I give you and be happy. Both extremes don't help HA. I assume that HA wants peoples feedback as I have given.

I'm just trying to figure out why something that worked well was removed before its replacement was ready (i get why auto-config/components is becoming the norm, its great for people less techie.)... but i think it hurts HA's credibility/adoption rate when features are removed, particularly without full explanations as to why, and how, in the opinion of HA devs, it will be better for HA in the long run.

[amelchio]

Great. To get help with development, it is best to get on the #devs_backend channel on Discord.

(Sorry, I am not joining the discussion on "why")

[Enzo-Matrix]

@marc-gist see this discussion on the forum for suggestion from @rytilahti. I don't know python, but comparing the new code with the old switch/tplink code, I think this is missing from init.py:

from homeassistant.const import (CONF_HOST, CONF_NAME)

...
DEFAULT_NAME = 'TP-Link Switch'

TPLINK_HOST_SCHEMA = vol.Schema({
    vol.Required(CONF_HOST): cv.string,
    vol.Optional(CONF_NAME, default=DEFAULT_NAME): cv.string
})

But I have no clue where to go from there or how to check if the name is still DEFAULT.

[marc-gist]

@Enzo-Matrix thanks, I "fixed" it and did a PR, but the powers that be have closed my PR as they don't deem allow name config in the files is ok... hoping more "powers" look at it and can allow it.

a little frustrated that it currently appears its not even a discussion 😦

[MarkHofmann11]

I agree, the names should have been left in. For people with loads of TP-Link switches that are already setup and working fine, this presents issues. Don't see the reason why the names feature was removed as I'm not aware of it hurting anything.

[amelchio]

This was elaborated in chat. The visible name and entity_id are now handled by the Entity Registry. That is available in the frontend UI where both can be changed.

Support for renames can in principle be added to the YAML config but it will have to be in a way that handles the entire Entity Registry so each integration will not have to add code for that.

[marc-gist]

Makes perfect sense that it be a core feature... however, until someone makes it a core feature, I would still like to see my PR allowed as a temporary "feature".

[amelchio]

Even with your PR, the entity_id will be frozen by the Entity Registry after the first setup.

So it is really only about the friendly name and this can already be set in YAML by using customize, https://www.home-assistant.io/docs/configuration/customizing-devices/#friendly_name

[marc-gist]

@amelchio i understand that and the reasons to not do it this way normally... but until someone does it in the core, why go backwards? my method although can't change the entity_id once its set in the Registry, it will set the entity_id on upgrade from one version to another, or initial setup (which is typically what the YAML file does - or at least how I've used it. I've never used the YAML to override something setup via auto config, unless there is an issue... i.e. auto config isn't working... so again, my Temporary method would work well until a better solution is in place).

[Enzo-Matrix]

In my case, I do NOT have the config option in UI. All I am able to change in the UI are ~users~ logged in users password/tokens and lovelace (for lovelace I change the .storage/lovelace file anway), so having an option to change entity names via yaml files is a valuable feature.

@marc-gist can you post the link to your fix? At least I can run a patch with your fix when I build hass.

[rytilahti]

As I mentioned earlier (probably elsewhere), I personally have nothing against for this configuration entry, but I see that there is simply no point in that (given that fact that it'll be set to stone after the initial naming), as mentioned already.

Regarding to why it was removed (and this my personal opinion) was that I saw no use for it when the ability to rename them via other means thanks to unique ID was introduced. I wanted to keep the code clean to get it merged at some point and get some people to test it; this wasn't a brand new PR, the whole conversion process took almost half a year to get reviewed and merged, and at no point no one apparently tested it.... For how long should we (as developers) be keep backward-compatibility on such cases when half a year is not enough?

@Enzo-Matrix the PR is here: https://github.com/home-assistant/home-assistant/pull/22122 - and as I said, I don't personally have anything against that, it is just that it does not apparently make sense to have when the ID is bound during the initial initialization of the component...

[marc-gist]

@rytilahti thanks for the great and straight forward code. as for "no one testing for 1/2 year", well, not sure how many people pull from the dev branch :) ... the "tough" part of HA is how big it is, which is great, but then things like this are going to happen if backward compatibility don't happen.
Also, perhaps depreciation warning should happen in the UI, as I never saw the warning for TP-Link platform being removed and going to component, or i would have tested before an update, or seeing the "breaking change" in the change log. way too many things flash by on HA startup logs.

[marc-gist]

@Enzo-Matrix thankfully for me when I moved without my patch... most of my TP Link devices have names that matched the HA name, so entity_id came back for all but a few. Before I updated I copied the entity_id. was a pain to have to force them back via the UI, but now the are in the registry and should, in theory, never have this issue again :)

[Enzo-Matrix]

Aww, just noticed the core.device_registry and core.entity_registry in the .storage directory. Guess I will edit these files to get the names back.

[DKrics]

Any of you guys know how to get the TP-Link HS300 (powerstrip) available on homeassistant on the front end? I'm a noob to HA, and appreciate your work. It would complete the TP link library.

[amelchio]

I hope everyone realizes that the tplink configuration can now be completely removed from configuration.yaml and the integration can then be autoconfigured by pressing a button in the UI. From there, name and entity_id can be changed if you want.

This is a huge improvement is usability:

• static IP addresses are no longer needed
• you don't have to read the documentation
• your entity_id won't suddenly change and break your automations
• entities can be placed in Areas

To get these benefits (and more), yes – if you previously renamed your entities in YAML, you must now do that in the UI. This is a one-time operation that takes no more than 20 seconds per entity.

I understand that this is an inconvenience right now but saying that this change is a step backwards is, frankly, a lack of respect for the huge work @rytilahti has put in over the course of six months, to make things better for everyone in the long term.

[MartinHjelmare]

I'm closing this issue since it's not a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum. Thanks!