It would be great if we could map buttons on the media card as we can on the tv card (eg arrows for navigation on the media device)
2 Likes
The Media Card and TV Card should be paired together. Just swipe to change between TV Card and Media Card views, same hardware button mappings for both.
but unfortunately not yet.
@Tom101 @Chykan_Hunter
Hi Gentleman,
Thanks for the feedback — this is actually a very good observation 
You’re absolutely right:
-
TV Card currently allows hardware button mapping and directional navigation.
-
Media Card is still more focused on media transport control (play/pause/seek) and does not yet expose the same level of hardware button customization.
Internally, we also see these two cards as closely related concepts rather than completely separate ones.
The idea mentioned by @Chykan_Hunter — treating TV Card + Media Card as paired views that share the same hardware button mappings and allow quick switching between control modes — is very much aligned with how we are thinking about the future interaction model.
Why it isn’t implemented yet
Right now the limitation mainly comes from how ROSCard contexts are handled:
-
TV Card → navigation-centric device control
-
Media Card → playback/state control
They currently run different control layers, so button mapping is not unified yet.
What we are exploring
Some directions under consideration:
Unified hardware button mapping across card types
Shared control context between Media & TV cards
Swipe or quick-switch workflow between navigation and playback control
Global button behaviors independent of active card
Our long-term goal is that you shouldn’t have to think about which card you’re on — the remote should understand what you’re controlling.
Please keep the ideas coming. Posts like this help us prioritize real-world workflows instead of theoretical ones.
— Charles
Sanytron Team
1 Like
The Idea of a swipe/scroll to change pages while keeping the physical buttons assigned to the first page could expand out to a Parent/Child setup where one TV card would have child media cards or other pages grouped to it.
so you could have the master TV card, swipe right for a buttons grid (input/activity selector for example), swipe again for a media card, again for a selected lighting card etc. but they all use the button assignments of the parent card.
This could be implemented with a “container card” that can have sub-cards assigned to it for quick swipe navigation while the selected TV cards physical buttons are always active. The other way it could be done is by allowing a TV card to act as a master for a dashboard page, so that the buttons can be used when at the cards menu for example, but that would mean more tapping around for navigation rather than quick actions like swipes.
Then you could make a master container card for multiple rooms or even just for different activity types, one for TV, one for music, one for reading for example. paired with a script trigger when opening a card and you have a great activity controller.
1 Like
I currently use a popup on the music button to quickly switch back and forth to a media card. One press to bring it up then another press dismisses it. Giving relatively fast access to everything but would be nice if it was better integrated. Even just access to the arrow keys from the media card would be excellent
That’s how I’m managing it at the moment too, I have a master TV card and Master Media card that are automatically routed to and from whatever is running automatically.
They already have a Show Independently for light cards. All they need is a Show Independently for a media player from the TV ROS card configuration, while holding the hardware button mappings of the TV ROS Card.
Thank you so much for your guys very helpful suggestions. Actually, as mentioned by Hunter, the lighting, air conditioning, and media playback controls can now be displayed independently and controlled by swiping pages.
Thanks for video sharing which give us clear idea, Faceman.
Since the team is working on infrared pre-research functions, we will add the custom button controls for media playback cards and the optimization of the TV card structure to a to-do list and study and update them one by one. Thank you again for your feedback.
1 Like
I’ve just received my Astrion remote and had preconfigured some cards and scripts in HA.
Happily, my activity automations work and icons look great, but feel like I’m missing something when it comes to the TV and media card. As @Chykan_Hunter suggested, I had a TV card and a media card on the same HA view, but all that does is gives me two small rectangles on that view and none of the button mappings work. If I click on the TV card, now my buttons work, but if I click on the media card from the first view, buttons no longer work.
How do I “pair” them as suggested and keep button mappings across both the TV card and the media card?
@Sierra055 This is a feature they have not implemented yet. It should be simple enough to achieve.
Thanks, I thought I was going crazy.
I see that 1.1.3 of the Ros Card integration has added the ability to have different volume control via script for the media card. It would be great if power controls/buttons could also be via script as my LG WebOS TV doesn’t have a remote entity and I’ve had to map all the buttons via script.
@Sierra055 welcome to the forum!
Thank you both for the discussion and feedback 
Yes — your current understanding is correct.
At the moment, the hard-button mappings are primarily attached to the active/focused TV Card context. This means:
• When the TV Card is opened/focused, the remote’s physical button mappings become active.
• When switching focus to a Media Card, the Media Card UI takes over visually, but it does not currently inherit the TV Card’s hard-button mapping context automatically.
So currently there is no true “paired” or shared activity-layer context between TV Cards and Media Cards yet.
The newer Roscard v1.1.3 update added independent volume-routing support for Media Cards (including scripts and external entities), which was the first step toward decoupling control logic from visible card UI.
We absolutely agree that:
• shared activity-level button context,
• hidden/background TV Card mappings,
• and arbitrary script-based power/media routing
would make the system significantly more flexible and closer to a full Harmony/Pronto-style experience.
Regarding script-based power handling:
Thank you for mentioning the LG WebOS case — this is actually a very good real-world example. Some ecosystems do not expose proper remote entities, so script-level abstraction becomes extremely important.
The implementation of more generalized script/button abstraction and expanded entity compatibility is already part of our longer-term roadmap planning. We are gradually restructuring the Roscard interaction layer to become more activity/context-oriented rather than tightly bound to visible card types.
Your feedback is genuinely valuable because advanced HA AV setups like yours help us identify where the current architecture still feels restrictive in real-world usage.
Thank you again for supporting Astrion and for helping us improve the platform