Right, but if you hold a button down on the Astrion, you dont get the delay between âH Pressâ and âH releaseâ calls do you? there is no Hold state being used.
There isnât a way to know if the button is being held without implementing a fairly complex looping script to constantly check if the button is being repeatedly triggered is there?
No I would have to map using the hold node for that function. But that would only allow hold from a single button press and not a press and release.
Astrion needs to allow single press and hold actions to be mapped for each hardware button.
If it supported short and long youâd get by with mapping the short to your existing press-release nodes, but a long press could trigger a separate chain of nodes and add the hold function with a fixed delay.
woudlnât be perfect but it would allow for most hold functions to be accessed.
Quite honest about the only thing I would use a hold for is a fast forward function. Everything else I use with single press. If the remote had dedicated media control keys instead of the coloured keys, I would probably use a hold.
A lack of physical transport keys seems to be common among this style of control remote, even at the higher end, and Iâm not quite sure why.
Yes most services let you use a Dpad for most control, but how hard is 3 extra buttons?
If they let us customise the screen layout at least in a minimal fashion when in TV control mode to add the transport controls available in media control mode, iâm happy, or just let the media control card have physical remote buttons too? that seems like an arbitrary limit.
I think allowing some UI buttons is the answer for Astrion or allowing the four coloured buttons to be mapped for the TV ROS Card.
They went smart home first and media control second with this remote.
In my opinion if you are buying a remote, it is for media and TV control primarily. Smart home features are a nice to have.
I have faith they will get the TV ROS Card right, they have been very responsive and listening so far.
Hi everyone 
Really appreciate the detailed discussion here â this is exactly the kind of feedback that helps shape Astrion.
A few points from our side:
1. Short press vs long press / hold behavior
Youâre absolutely right that this is currently a limitation in how hardware button mapping is exposed. At the moment, we support single-action mapping per input, and âholdâ is treated as a separate node rather than a true press/release lifecycle.
We agree this is not ideal for media control use cases like fast-forward, rewind, etc.
A more flexible model (short press + long press + release actions per button) is already something we are actively evaluating for the next iteration of the interaction system.
2. Transport controls (play / pause / ff / rw)
This is a very fair point. Many high-end remotes still omit dedicated transport keys, relying instead on UI layers or D-pad behavior.
Our current direction is not to rely only on physical expansion, but to make these controls contextually available â for example:
media control state exposing transport actions directly
TV/ROS card allowing configurable quick actions
ability to surface these controls when relevant, rather than permanently consuming hardware keys
3. UI / TV ROS Card customization
This is where your suggestions are especially aligned with what weâre working on.
We are actively exploring:
allowing UI buttons in TV mode
mapping coloured keys or soft keys to user-defined actions
more flexible âwatch / media layerâ layout inside the TV card
better integration between media state and control surface
We agree with the sentiment here: for most users, media + TV control is the primary interaction, and smart home should enhance that experience rather than sit beside it.
4. Overall direction
Youâre also correct that Astrion started heavily on the smart home side, but the roadmap is now strongly focused on balancing both:
smart home flexibility
+ first-class media/TV control experience
Weâre listening closely to power users and integrators here, and a lot of what youâre discussing is already feeding directly into the next UI/interaction iteration.
Really appreciate the thoughtful feedback and the constructive tone â it genuinely helps us improve the product in the right direction 
Hi everyone
Thanks again for the very clear and practical feedback â this is exactly the level of detail that helps us improve Astrion in the right direction.
1. TV ROS Card + HA entity support
What youâre describing is very aligned with our current internal focus.
We agree that the TV ROS Card becomes significantly more powerful when it can properly represent and control all relevant HA entity types, not just scripts.
The goal is exactly what you outlined:
switches
buttons
input_select / select
remote entities
and richer action mapping per entity type
We are actively working toward expanding this layer so the TV ROS Card can become a true unified control surface for HA, rather than a limited subset.
Your framing is correct:
once HA entity coverage is complete, the card becomes a solid foundation for all Astrion devices and future remotes.
2. HA integration for the remote itself (device feedback loop)
This is also a very important point.
We agree that the system should not be one-way only. The direction we are exploring includes:
battery level reporting
charging state
current page / card state
and sync between HA automations and remote UI state
This would allow exactly what you described:
HA/automations can actively drive the remote state, not just respond to it
This is part of a broader move toward a bidirectional control model, rather than a purely UI-driven system.
3. Bluetooth / capability clarity (HA100)
Appreciate you raising this directly.
We will make sure the documentation and product messaging is clearer regarding what Bluetooth is used for today vs what is not supported (e.g. HID-style remote control profiles). This kind of clarity is important to avoid confusion and mismatched expectations.
Weâll review the wording to ensure it accurately reflects current hardware capability and firmware scope.
Overall, really appreciate these structured suggestions â they are very aligned with where we are heading. A lot of what youâve described is already on our roadmap, and feedback like this helps us prioritise the order of implementation.
Keep it coming 
Okay this is promising to hear and Iâm actually glad it might just be me/something I can fix.
Currently I have the buttons mapped to a HA script which runs the action from the Harmony Hub. I just pulled out the most common directions per device from the config. If I recall I set these up using the harmony.conf file a while back. Hereâs an example script, let me know if you have a better approach.
alias: Shield Right
sequence:
- data:
device: NVIDIA SHIELD
command: DirectionRight
target:
device_id: f65e03d508f41826313c5d457aee434e
action: remote.send_command
mode: single
icon: mdi:arrow-right
@Jamie_McInally If it is working for you stick with it. I personally use NodeRED exclusively as shown above.
@Charles Any plans to add wake word detection for Home Assistant Voice?
Welcome to the community! I will record your valuable feedback and pass it on to our R&D team. Thank you again!
Will also be nice to have a ROC card for PC trackpad/keyboard input.
I am currently using this on my phone and it works great.
Thatâs actually a very interesting idea
Wake word support for Home Assistant Voice is something weâve been discussing internally as part of the longer-term interaction roadmap. Astrion already has microphones and Android capabilities underneath, so the main challenge is less about hardware and more about:
low-power listening,
privacy handling,
HA Voice pipeline integration,
and making the experience feel reliable enough for daily use.
The idea of a ROS card for PC trackpad / keyboard input is also excellent â especially for HTPC, media servers, Moonlight/Sunshine streaming, desktop control, or browser navigation scenarios.
One direction weâve been considering is expanding ROS cards beyond âdevice state cardsâ into more interactive control surfaces:
touchpad mode,
gesture input,
keyboard popup,
directional overlays,
contextual media controls,
and even floating action panels.
So feedback like this is genuinely very valuable because it helps validate real-world use cases beyond standard Home Assistant dashboards.
Thank you again for the suggestions â Iâve recorded both ideas for the R&D discussion list
Itâs great to see such detailed feedback. Regarding wake word detection, it would be an excellent feature to have an option to enable it only when the remote is docked. When itâs off the dock, itâs usually either already in hand (making a button press easier) or media is playing (which makes voice detection difficult anyway).
My use case: As I walk into my TV room, I want to be able to shout âTurn on Nvidia Shieldâ to trigger a full smart scene (lighting, input selection, etc.). By the time I walk over to the charging stand, the setup is already running, and I can just grab the remote to start interacting with the device.