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 ?