Thank you for sharing the FireRemote YAML example — this is a very good reference.
What FireRemote does extremely well is:
- Allowing device family + model selection
- Treating every button as an overrideable action
- Letting users bind buttons to any HA service, not just media_player services
Your requirement — “insert the above entities into the TV RosCard” — is valid and highlights a structural limitation of the current TV / Media Play RosCard design.
RosCard Media Play redesign (confirmed direction)
After internal discussion with the development team, we agree that the Media Play RosCard needs a structural redesign, and your example aligns very well with where we want to go.
Here is the proposed direction, point by point:
Device family & model selection (FireRemote-style)
The Media Play RosCard will be redesigned to:
- Select device family (Android TV, Apple TV, Fire TV, Shield, Harmony, etc.)
- Optionally select model type, which defines:
- Default key mappings
- Default command behavior
- UI hints / labels
This removes the assumption that one media_player entity fits all use cases.
No UI switching required on Astrion Remote
On Astrion hardware:
- Users do not need to switch cards or screens
- Selecting a different playback device will:
- Update the control context
- Refresh the control UI automatically
- Rebind physical buttons in real time
This keeps interaction hardware-first, not UI-first.
Full physical button customization with “Default / Override” logic
Because Astrion’s physical buttons are fixed, we will expose full per-button customization, using this rule:
- Default → Button keeps its native behavior
Examples:- D-pad: navigation
- OK: select
- Volume ±: volume
- Channel ±, Mute, etc.
- Override → User-defined behavior takes precedence
Examples:- UP / DOWN send scripts to Harmony or Shield
- LEFT / RIGHT trigger HA button entities
- Volume keys control a different device than the navigation target
This is essentially bringing FireRemote-style button_overrides into RosCard, but adapted for hardware buttons.
The 4 custom function buttons
The four original customizable function buttons on Astrion will also be:
- Fully configurable
- Able to trigger:
- Scripts
- Scenes
- App launches (Netflix, YouTube, etc.)
- Any HA service call
These buttons will remain device-agnostic, making them ideal for global shortcuts.
Regarding the posted TV RosCard YAML
Your current YAML example clearly shows the limitation:
entities:
- key: UP
type: remote
entity_id: remote.shield_debug_bridge_remote
The redesign goal is to remove the need to hard-code this per card, and instead:
- Let the card define a control context
- Let users override button behavior without duplicating entire card definitions
This will make advanced Harmony + Shield + AVR setups much cleaner.
Reply — Default RosCard on wake (feature request)
Ability to set a particular Roscard as the default card to display full screen when waking the remote.
This is a valid and frequently requested UX improvement.
We’ve logged this as a standalone feature request, because it affects:
- Power / wake behavior
- Last-state memory
- User workflow consistency
Once implemented, users will be able to choose:
- Resume last card
- Always open a specific RosCard on wake
Closing
Thanks again for the detailed YAML, screenshots, and explanations — this is exactly the kind of advanced, real-world usage that helps us evolve Astrion and RosCard in the right direction.
We’ll announce the Media Play RosCard redesign officially once the implementation plan is finalized.