RFC: Default Platform Schema

[cdce8p]

Currently we support at least two different configuration patterns for platforms:

1. Just platform (e.g. YR, Version Sensor, Min/Max Sensor)

sensor:
  - platform: yr
    monitored_conditions:
      - temperature

2. Mostly template platforms (e.g. Template Sensor, Template Cover)

sensor:
  - platform: template
    sensors:
      sensor_entity_id:
        value_template: "{{0}}"

Since it came up in the discussion regarding my PR: home-assistant/core#12500, is one schema better than other? If so should we try to harmonize the other components?

[OttoWinter]

• For some platforms 2. makes sense. For example speedtest has a common data object that does the periodic speed testing, but it can output multiple sensors:

- platform: speedtest
  minute:
    - 0
    - 15
    - 30
    - 45
  monitored_conditions:
    - ping
    - download
    - upload

Combining this into a separate platform entry would be very cumbersome

• Somewhat like my first comment: Platforms with shared configuration benefit from 2. For example, in WUnderground:

- platform: wunderground
  api_key: !secret wunderground_api_key
  monitored_conditions:
    - weather
    - weather_1d_metric
    - ...

This list can contain lots of monitored conditions and I seriously wouldn't want to type platform: wunderground \ api_key: !secret wunderground_api_key for every single one of them.

• \1. makes more sense when the individual sensors/... are separate and don't control each other. As a user, if I see sensors: in the Template Sensor, I assume that I can't use multiple platform: directives or else something will break.

• \1. allows for much better separation in config files. For example, I can have all my "livingroom" entities grouped under the comment "livingroom" and don't have to navigate between file positions all the time. Of course multiple platform: directives are technically allowed, but then the previous comment comes into play again.

• \1. saves on indentation: Especially in the Template Sensor platform, where lines can get pretty long, having 4 more characters per line is gold 💯.

• In 2. sensor_entity_id: is very misleading: It is not your entity_id. For example, if I type wohnzimmer_heizkörpertemperatur as key, the "ö" will get converted into an "o". While the current way of having the friendly name control the entity_id so closely isn't perfect IMHO, having a standardized way that you can rely on is important. Edit: Same with lower+uppercase

[balloob]

I think that both have their purpose.

I think for template ones, I would probably have prefered if we defined 1 entity per config. No reason to cramp it all together because they are not related.

The first one is related because it's based on, for example, a location that is passed in.

The need to define entity IDs or names should not be added to platforms or components anymore. That can now be done via the entity registry.

[pvizeli]

For core site: it doesn't matters. Since we have change add_devices callback too none blocking, there is no speed benefit. For the yaml parser I don't know.