I’ve been experimenting further with RosCard v1.1.3 and the TV / Media Player cards.
My current understanding is that hard-button mappings only become active when a TV Card is opened full-screen/focused. The Media Player card is much better visually for “now playing” artwork/metadata, but it does not expose the same hard-button mapping flexibility. So at the moment I don’t see a way to have a full-screen Media Player view while an activity-level or hidden TV Card provides the hard-button mappings.
I also noticed that the two TV Card types expose different button models. Android TV exposes Channel Up/Down, numeric keypad etc., while Apple TV exposes separate power on/off behaviour. I tried copying Channel Up/Down mappings from an Android TV card into an Apple TV card in YAML; the code persists, but the remote ignores those buttons in practice, so it seems the active button set is filtered by the selected TV type.
Is this understanding correct?
Longer term, I think the ideal model would be activity-level hard-button context independent of the visible card, so that:
-
the screen can show Media Player artwork/metadata
-
hard buttons can still be routed by activity/context
-
users can define arbitrary short/long-press mappings per activity
-
button availability is not restricted by Apple TV vs Android TV card templates
That would make Astrion much closer to a true Harmony/Pronto-style AV control surface while keeping Home Assistant as the control brain.
1 Like
Hi @grahamn1956,
First of all, thank you very much for the detailed testing and analysis — your understanding is largely correct, and your observations are very valuable for us.
At the current stage of RosCard architecture:
-
Hard-button mappings are primarily attached to the active/focused TV Card context.
-
The Media Player card is currently designed more for media presentation and interaction (artwork, metadata, transport status, source display, etc.) rather than full hardware-button routing logic.
-
Different TV Card templates (Apple TV / Android TV / generic TV) indeed expose different internal button models depending on the capabilities and common usage patterns of those ecosystems.
So your testing result regarding Channel Up/Down copied into the Apple TV card is expected behaviour at the moment — the configuration may persist in YAML, but unsupported button groups are filtered internally by the active device profile and therefore ignored by the runtime layer.
Your conclusion about separating:
is actually very aligned with the long-term direction we want to move toward.
The architecture you described:
-
Media Player card for artwork and metadata
-
Independent activity-level button context
-
Arbitrary short/long press mappings
-
Unified button abstraction independent of TV type
-
Context-aware routing similar to Harmony / Pronto systems
is very close to the conceptual direction of Astrion as it evolves from a “dashboard remote” into a more complete AV interaction platform.
One of the current limitations is that RosCard originally inherited a relatively entity-centric design philosophy from Home Assistant itself, while traditional AV remotes are fundamentally activity/context-centric systems. Bridging those two paradigms cleanly is one of the larger architectural goals we are gradually working toward.
The implementation of:
-
independent button routing layers
-
activity-level button contexts
-
global hard-button abstraction
-
and more advanced short/long press behavior
has already been discussed internally and is also partially reflected in our previously published roadmap.
At the moment, the TV Card templates still intentionally expose constrained button models to reduce configuration complexity for general HA users, but we fully understand the need for a more advanced “power user / AV installer” layer.
Your feedback is extremely helpful because it validates that experienced AV users are pushing Astrion toward exactly the kind of hybrid HA + professional control workflow we envisioned originally.
Thank you again for the excellent write-up and experimentation.
1 Like