Add example showing multiple entities for a platform

[tboyce021]

Is your feature request related to a problem? Please describe.
The current platforms are supported via a list of entities to configure. However, all configuration options are optional, which means configurations like the following are possible (although not necessarily intended to be used):

blueprint:
  sensor:
    -
    -
    -

I have no idea if that actually works in YAML, but probably something like sensor: [{}, {}, {}] would.

The reason for this is so that it's possible to add different types of sensors in the future.

Describe the solution you'd like
Add an example with different entities for one of the platforms to show what it would actually look like:

blueprint:
  sensor:
    - type: type1
    - type: type2
      name: Type 2

In this case, type is now required, so there's no possibility to have empty entries. However, it's still possible to configure multiple of the same type. I'm not sure if there's an actual use case for supporting that:

blueprint:
  sensor:
    - type: type1
    - type: type1
      name: Another type 1

Describe alternatives you've considered
Possibly use a dict instead of a list:

blueprint:
  sensor:
    type1:
    type2:
      name: Type 2

This way, it's only possible to configure each type once. An empty configuration for each type is acceptable here, since the key itself is already unique.

One example that could make sense both ways is configuring a sensor that is of the same type but has different options. Both ways could support that, but the way of doing so is a bit different:

list:

blueprint:
  sensor:
    - type: json_entry
      entry_key: key1
      name: Key1 Value
    - type: json_entry
      entry_key: key2
      name: Key2 Value

dict:

blueprint:
  sensor:
    json_entry:
      - entry_key: key1
        name: Key1 Value
      - entry_key: key2
        name: Key2 value        

With this, it's possible to end up creating the exact same sensor multiple times with either approach, however it's still possible to prevent that in the second example by again using a dict instead of a list:

blueprint:
  sensor:
    json_entry:
      key1:
        name: Key1 Value
      key2:
        name: Key2 value        

In the end, I'm not sure it's really worth trying to prevent that. I'm willing to bet several core components can already be easily duplicated via their own configs, e.g. hue. So the original approach is probably fine.

Additional context
It's still a bit odd to have a list if the component only supports one type of entity from a platform, especially if all the configuration options are optional. In that case, the configuration to use the default values would still be

sensor:
  -

It's not very clear what that is doing. It would be more clear using the dict:

sensor:
  blueprint_sensor:

[tboyce021]

I can probably throw something together for the dict version as an example to see what you think unless there's a particular reason for still preferring the list.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.