We’d love to see how everyone is using Astrion Remote 
Some ideas to share:
Feel free to post:
Photos
Button layouts
Automation ideas
Your setup might inspire others!
Hi, I understand that it can be integrated with Home Assistant, but I wanted to know if it can also be used as a remote control for a home theater system that needs to control multiple devices, like the Logitech Harmony Touch, in short.
Currently can control Android TV, integrated with HA. They are working on updating the Roscard to enable it to control a harmony hub directly, another option would be for it to control any other IR hub.
Hi Massimiliano, welcome to the community! 
Great question — and yes, this is a very common use case.
Astrion can absolutely be used as a “home theater remote”**, but the approach is a bit different from Logitech Harmony.
Astrion is 100% Home Assistant–centric, so instead of directly learning IR codes itself like Harmony Touch, it works through HA as the control brain.
That means:
Multiple devices (TV, AVR, player, projector, etc.) are controlled via Home Assistant
Astrion sends commands to HA
HA talks to your devices using:
If Home Assistant can control it → Astrion can control it.
Some real-world examples from users:
This actually makes Astrion more flexible than Harmony in many cases, because you’re not limited to a fixed device model list.
As Chykan mentioned:
This keeps everything unified in HA and avoids vendor lock-in.
If you’d like, feel free to share:
We’re happy to suggest a clean setup 
As seen below, I have managed to select my harmony as the volume control. But it does not work for volume control.
Need to be able to add a button.* entity for that command, within the TV card.
The Harmony power off activity can be mapped directly to a button. In my case below power_off works with the power button but only provides power off not toggling.
Hi @Chykan_Hunter, thanks for the detailed screenshots.
What you’re seeing is expected with the current implementation.
Although Harmony activities can be selected as a volume source, Harmony does not expose volume as a standard Home Assistant media_player volume entity (volume_up / volume_down / volume_set).
The RosCard TV card volume control currently relies on standard HA media_player volume services, which Harmony does not fully support. As a result, volume commands bound this way won’t take effect.
At the moment:
We’re evaluating adding per-button command entities to the TV card in future updates to better support Harmony-style command-based control.
Good observation
This behavior is normal and comes from the Harmony integration itself.
Harmony activities usually expose power_off only, not a true on/off toggle state.
Because Home Assistant cannot reliably know whether the activity is currently on or off, Astrion:
If an integration exposes a true toggle service, Astrion will support it automatically.
Thanks for the clarification and screenshot
You’re correct.
In Home Assistant, the Harmony integration exposes activities as an input_select:
power_off = OFFThis also explains why Harmony does not provide a true toggle or volume-capable media_player entity. From HA’s perspective, Harmony is command-driven, not state-driven, which is why many advanced setups (including FireRemote) rely on explicit button entities or scripts.
This behavior is fully understood on our side.
Thank you for sharing the FireRemote YAML example — this is a very good reference.
What FireRemote does extremely well is:
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.
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:
This removes the assumption that one media_player entity fits all use cases.
No UI switching required on Astrion RemoteOn Astrion hardware:
This keeps interaction hardware-first, not UI-first.
Full physical button customization with “Default / Override” logicBecause Astrion’s physical buttons are fixed, we will expose full per-button customization, using this rule:
This is essentially bringing FireRemote-style button_overrides into RosCard, but adapted for hardware buttons.
The 4 custom function buttonsThe four original customizable function buttons on Astrion will also be:
These buttons will remain device-agnostic, making them ideal for global shortcuts.
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:
This will make advanced Harmony + Shield + AVR setups much cleaner.
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:
Once implemented, users will be able to choose:
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.
How do you interact with Up, Down, Left, Right navigation controls?
Do you get a D-pad style UI on the touchscreen?
I have an LG TV, I’m thinking of using an old Harmony Hub for the sole purpose of allowing the Astrion to display the D-pad for navigation.
Hi @NeilsOnWheels, thanks for the detailed follow-up — this is a great question and a good opportunity to clarify how Astrion works today 
One of Astrion’s core design principles is that physical function keys adapt automatically based on the controlled device type, rather than being hard-coded to one use case.
Here’s how it works conceptually:
Context-aware button behaviorThe same physical buttons will behave differently depending on what you’re controlling:
This means you don’t need to “rethink” the remote every time — the same muscle memory applies, while the function adapts to context.
Why this mattersThis adaptive behavior is what allows Astrion to feel like:
As we continue improving RosCard (especially the upcoming media control redesign), this context-driven button logic will remain a core foundation, with even more flexibility added on top.
Thanks again for taking the time to describe your expectations — they line up very well with how we want Astrion to evolve.