Generic Platforms

I have an idea that I have been bouncing around a bit lately. I’ve been thinking about developing generic platforms for some of the major components. These generic platforms would allow optionally service calls to be bound to their actions and would allow states to optionally be defined with a template. Here is what this would look like in practice:

Generic Switch:
Turn on action would optionally be defined as a service call as would turn off, status could optionally be defined by a template. If no status template is defined, HA will assume the status. If this platform is used without any service calls or status template set, it acts as a boolean variable.

Generic Light:
Pretty much the same deal as the switch, but optionally allows a service template for handling the brightness being set. With no parameters set, this acts like a float variable.

Media Player:
Service calls get defined for turn on, turn off, set volume, play, pause, next, prev, mute. Templates can be defined for state, volume level, is muted, etc. This one would have mostly required attributes. This would allow a media player component to be made for pretty much any setup. For example, I have a TV, receiver, and Chromecast. This would allow me to create one media player component that could control them all in a very simple way that is sufficiently portable.

After some discussion with Paulus, the new line of thinking is now to have variables in their own component. That way a clear separation of components and their intended function will still exist.

About the generic media player, this is sort of what we came up with:

media_player:
  platform: universal
  name: MEDIA PLAYER NAME
  status:
    - media_player.cast
    - media_player.roku
  status_default: {% TEMPLATE %}
  power_switch: ENTITY ID
  commands:
    turn_on: SERVICE CALL
    turn_off: SERVICE CALL
    volume_up: SERVICE CALL
    volume_down: SERVICE CALL

For the player’s status, the first media player that is not off/idle will have its status reported. That way, only minimal templates will be needed. If all of the media players are idle/off, then the status template will be parsed. This will eventually allow inputs to be controlled by the upcoming select component. All command will be routed to the controlling media player except for a few that may be optionally overwritten. Specifically, turn on, turn off, volume up, and volume down. If volume up/down are specified, then the volume slider on the media player’s card will display volume buttons rather than a slider. Possibly also allow for power to be controlled by a different switch component instead of specifying service calls.

All still a very generic idea so all input is very much welcome.

media_player:
  platform: universal
  name: MEDIA PLAYER NAME
  children:
    - media_player.cast
    - media_player.roku
  commands:
    turn_on:
    	service: SERVICE
    	service_data: SERVICE DATA
    turn_off: 
    	service: SERVICE
    	service_data: SERVICE DATA
    volume_up: 
    	service: SERVICE
    	service_data: SERVICE DATA
    volume_down: 
    	service: SERVICE
    	service_data: SERVICE DATA
    volume_mute: 
    	service: SERVICE
    	service_data: SERVICE DATA
  attributes:
    is_volume_muted: ENTITY ID|ATTRIBUTE
    state: ENTITY ID|ATTRIBUTE 

I think this is the configuration I’m settling on.

Does this actually work? Like this I can send it commands via Xiaomi ir

I just saw it has children but me I want a generic media player which controls my Xiaomi ir device …any ideas ?