Have an experimental idea or technical proposal?
This is the place for:
- Early concepts
- Developer feedback
- Technical feasibility discussion
Not all ideas will become features.
Need to be able to pair the Roscard for TV and Media Player together.
Example.
If I open the TV Control Card for my Shield, I should be able to swipe sideways to go to the Media Player Card for my Shield, While the remote keeps the button mappings for my TV Control card active, while on the Media Player Card.
This is a very good suggestion, thanks for sharing the use case.
At the moment:
Each RosCard is independent
Physical button mappings are tied to the currently active card
Cross-card context sharing (TV ↔ Media) is not implemented yet
What you’re describing would require:
Shared device context between cards
Persistent physical button mappings while switching UI views
This is a valid feature request and aligns well with Astrion’s hybrid hardware + touchscreen design.
I will recommend to the RD team for evaluation.
1 Like
Thank you Charles. It is great that you take on feedback from us users.
I agree with @Chykan_Hunter on this one. A broader design thought might be to realise that actual “devices” are often more complex than a single entity. When I’m watching TV, it’s actually the TV, the media player (a Sky Q satellite stb), and a audio receiver. If I watch amazon prime or netflix, I might use the player built into the TV rather than the one in the media player, if I’m watching sport, I’m using the stb (so changing the TV input). If the source is 4k UHD on the STB, I run a script to change the output. I currently use mini media player which allows me to assemble a set of actions from diverse entities into a single UI element. But in general, I’d say there isn’t a 1:1 mapping always between the “logical” device we want to control and an entity. Maybe building a roscard to Universal Remote might be a way to achieve this?
1 Like
Below is an example yaml showing what HA entities are used for mapping my keys on my dashboard remote GitHub - PRProd/HA-Firemote: Apple TV, Amazon Fire TV, Chromecast, Homatics, NVIDIA Shield, onn., Roku, Xiaomi Mi, and Android TV remote control card for Home Assistant
- type: custom:firemote-card
entity: media_player.shield_debug_bridge
device_family: nvidia-shield
device_type: shield-tv-pro-2019
compatibility_mode: default
android_tv_remote_entity: ""
defaultRemoteStyle_override: AL2
app_launcher_relative_size: -30
button_overrides:
mute-button:
service: switch.toggle
target:
entity_id: switch.nad_mute_switch
power-button:
service: remote.toggle
target:
entity_id: remote.harmony_hub
left-button:
service: button.press
target:
entity_id: button.harmony_left
right-button:
service: button.press
target:
entity_id: button.harmony_right
up-button:
service: button.press
target:
entity_id: button.harmony_up
down-button:
service: button.press
target:
entity_id: button.harmony_down
center-button:
service: button.press
target:
entity_id: button.harmony_select
volume-down-button:
service: button.press
target:
entity_id: button.harmony_volumedown
volume-up-button:
service: button.press
target:
entity_id: button.harmony_volumeup
reboot-button:
service: button.press
target:
entity_id: button.harmony_surroundmode
scale: "100"
hide_button_group_frame: true
dpad_style: apple-tv-black
useCustomSkin: false
skin: "#7246b4"
So what I need is to be able to have my TV Roscard below have the above entities inserted.
- type: custom:aiks-tv-card
id: f880c45f-643d-4119-9e38-94d93426ca12
tv_type: android_tv
tv_name: Shield
media_play_entity: media_player.shield
entities:
- key: POWER
type: select
entity_id: select.harmony_hub_activities
value: power_off
- key: UP
type: remote
entity_id: remote.shield_debug_bridge_remote
value: UP
- key: DOWN
type: remote
entity_id: remote.shield_debug_bridge_remote
value: DOWN
- key: LEFT
type: remote
entity_id: remote.shield_debug_bridge_remote
value: LEFT
- key: RIGHT
type: remote
entity_id: remote.shield_debug_bridge_remote
value: RIGHT
- key: CENTER
type: remote
entity_id: remote.shield_debug_bridge_remote
value: CENTER
- key: BACK
type: remote
entity_id: remote.shield_debug_bridge_remote
value: BACK
- key: PLAY
type: remote
entity_id: remote.shield_debug_bridge_remote
value: PLAY
- key: PAUSE
type: remote
entity_id: remote.shield_debug_bridge_remote
value: PAUSE
- key: VOLUME_UP
type: remote
entity_id: remote.harmony_hub
value: VOLUME_UP
- key: VOLUME_DOWN
type: remote
entity_id: remote.harmony_hub
value: VOLUME_DOWN
- key: MUTE
type: remote
entity_id: remote.shield_debug_bridge_remote
value: MUTE
- key: UN_MUTE
type: remote
entity_id: remote.shield_debug_bridge_remote
value: UNMUTE
- key: SETTINGS
type: remote
entity_id: remote.shield_debug_bridge_remote
value: SETTINGS
- key: HOME
type: remote
entity_id: remote.shield_debug_bridge_remote
value: HOME
- key: MENU
type: remote
entity_id: remote.shield_debug_bridge_remote
value: MENU
- key: NUM_0
type: ''
entity_id: ''
value: ''
- key: NUM_1
type: ''
entity_id: ''
value: ''
- key: NUM_2
type: ''
entity_id: ''
value: ''
- key: NUM_3
type: ''
entity_id: ''
value: ''
- key: NUM_4
type: ''
entity_id: ''
value: ''
- key: NUM_5
type: ''
entity_id: ''
value: ''
- key: NUM_6
type: ''
entity_id: ''
value: ''
- key: NUM_7
type: ''
entity_id: ''
value: ''
- key: NUM_8
type: ''
entity_id: ''
value: ''
- key: NUM_9
type: ''
entity_id: ''
value: ''
- key: DELETE
type: ''
entity_id: ''
value: ''
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.
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.
1 Like
I just got my remote last night and so far I’m very impressed with how responsive it is, and I’m excited to see what your team does with it in the future. I think everything you’ve mentioned that you’re working on hits a few of the things I want to do, so thank you for your detailed breakdown of those things. I had a couple ideas I haven’t seen mentioned yet.
- I’d like to remap the home button. I understand we need a way to navigate the android interface on the remote still so maybe an option to change it to a long press for remote navigation and a short press can be mapped by the user.
- I’d love a custom card that lets me design a mappable button/fader layout on the touchscreen with customizable icons, as well as map the physical buttons. Even if it’s a yaml only card.
Hi @starkkaman, welcome to the community 
And thank you very much for the kind words — we’re really glad to hear you’re enjoying the responsiveness of the Astrion Remote so far.
Your ideas are very good, and they’re also very much aligned with the direction we’re already discussing internally.
Home button remapping (short press / long press)
This is a very reasonable suggestion.
Separating short press vs long press behavior (for example, keeping system navigation on long press while allowing user-defined actions on short press) is a clean and flexible approach. We’ve taken note of this and will record it as a potential enhancement when we expand physical button customization logic.
Custom touchscreen card with fully mappable layout
This is also an excellent idea, especially for advanced users.
A custom card that allows:
- User-designed button / fader layouts
- Custom icons
- Touchscreen + physical button mapping
- YAML-only configuration (for power users)
is something we see as a very powerful extension for Astrion, particularly for complex AV and automation setups. While this is not part of the current stable feature set, we’ve recorded your suggestion as part of our advanced / experimental direction.
Thank you again for taking the time to share thoughtful, constructive feedback.
We actively collect and review ideas like yours, and many of our recent design changes have come directly from community input like this.
Please feel free to keep sharing ideas or use cases as you explore the remote further — discussions like this genuinely help us shape better features going forward.
— The Sanytron Development Team 
1 Like