Fix WUnderground names

[OttoWinter]

Description:

With the changes made for the entity registry, WUnderground's (horrible) way of reporting friendly names to Home Assistant's core broke. Before, each WUnderground sensor would set the friendly name by setting the ATTR_FRIENDLY_NAME attribute on the sensor and the entity_id would be reported through the name property. This no longer works with the following code that creates the entity_id for each entity and no longer takes into account attributes[ATTR_FRIENDLY_NAME]:

https://github.com/home-assistant/home-assistant/blob/034eb9ae1aa33cec829393f409343919c036044c/homeassistant/helpers/entity_platform.py#L230-L233

This PR simply makes WUnderground use the name property for the friendly name and the entity_id attribute to set the entity_id.

Before:

After:

Related issue (if applicable): fixes #12282

Example entry for configuration.yaml (if applicable):

sensor:
  - platform: wunderground
    api_key: !secret wunderground_api_key
    monitored_conditions:
      - weather
      - weather_1d_metric
      - weather_1n_metric

Checklist:

• The code change is tested and works locally.
• Local tests with tox run successfully. Your PR cannot be merged unless tests pass
• Tests have been added to verify that the new code works.

[OttoWinter]

So I just went looking a bit at recent code changes to figure out how entity_id creation was done previously and when it "broke" for some components. Specifically, I looked a lot for ATTR_FRIENDLY_NAME being used in entity id creation - but without success. While I still believe the attribute ATTR_FRIENDLY_NAME and the property name of an Entity should always be the same (not like previous WUnderground), I currently have no idea how this even worked before.

[balloob]

I changed that logic here: https://github.com/home-assistant/home-assistant/pull/12237/files#diff-2f6e7e067d836cc94edba0d7d51d0241L227 . We should always have just looked at self.name instead of seeing if it was already overridden.

[balloob]

You are not allowed to call async functions from a sync context.

This is not executed in an async context (because it's setup_platform instead of async_setup_platform).

[OttoWinter]

Good catch! Fixed.

[balloob]

fix async in sync context

[rpitera]

Just a note; this fixed the sensors but missed the forecast entities. Restarted after 0.63.1, cleared browser cache and restarted browser. All forecast entities are still displaying this behavior. Let me know if you want me to open a new issue.

[OttoWinter]

@rpitera Works for me :/ (Yes it's quite cold here in Austria 😄)

Question: Are you sure you've manually patched this into your install? Because this PR isn't in Home Assistant yet - though it will be in 0.63.2

[rpitera]

I checked my perms and they are correct; do I have new wunderground.py in the wrong location maybe? I have it in

/custom_components/components/sensor

I just restarted and cleared the cache again but still seeing the same thing. Only on the forecast sensors, everything else is fine.

[rpitera]

So just to follow up, 0.63.2 did fix the problem for me; I removed the test code prior to update and restart.

But I am still confused as to why the test code didn't work or whether I had it in the wrong location.

[amelchio]

@rpitera It should be just custom_components/sensor/

[rpitera]

Thanks! It's been awhile since I tested anything and I forgot.