Currently set up my remote 3, all working great so far.
This is more a discussion of user experiences for button press response/latency and what you found the best.
My setup is the remote 3 using the Jack Powell integration for HA to push only what is needed to the remote. Everything is configured as scripts at the moment in HA (Button presses, on/off logic etc).
I have just done a quick test of the speed difference between the LG Magic Remote and the short press DOWN button mapped to a HA script. Needless to say when bringing up the EPG and holding the DOWN button, the Magic Remote wins over the mapped button on the R3. Not too much of a surprise since the R3 needs to go wifi->HA and then HA->LG. However I wonder if this might also be slightly because of whatever the short press repeat delay is on the R3 buttons (maybe in a future release can allow editing this value).
TBH the delay is not overly excessive and I can live with it. When I eventually get to the Denon though it might be different as one would expect to hold down the volume button and not take too long to adjust.
My question is for those of you using a Denon AND HA, what did you end up using for volume control? I have a feeling the scripts method from HA might be a bit too slow for volume.
I have an Integra/Onkyo AVR. I found that the IR controls for the volume too slow when holding the volume up/down buttons. I figured out a way to send IP commands to the AVR. It is more responsive this way and holding the volume button changes the volume faster but it could be better. It is still not like using the original IR remote for the AVR.
Like you said, I think the delay between repeat commands when holding down a button is too long. If there was a way reduce the delay, it should work like the original remote.
Maybe the UC Denon integration would be the best option. But even using the Android TV integration, holding the direction buttons is still slow.
Will that make holding down the volume up/down repeat delay faster?
The IR command doesn’t have delay option. I thought the delay option in IR sequence was the delay between the sequence of commands and not the repeat delay from holding down the button.
OK, so after some quick and dirty testing have found the following.
UC Denon integration
With the default step of “1” for the volume config it is marginally faster than HA scripts but not by as much as I was expecting.
Setting the volume step to “4” was quite faster, only the issue was even pressing once you also get a step by 4, not ideal.
Using IR codes with the internal emitter
So I am aware that this is not supported for repeat IR commands but thought I would try it anyway.
I added IR codes just from the default library for Denon, works sort of the same way but different
It starts off very slowly, but then accelerates too fast at then end, almost as if the IR codes were buffered and then all come at once towards the end. Again, this might not be a valid test since it’s not officially supported on the internal emitter.
Will try this test again with a properly setup dock over the next few days and see if results are similar.
HA Script Ideas
One idea might be to try simulate in my HA scripts somehow using some kind of logarithmic/exponential calculation for the media player setvolume instead.
Another idea might be to have 2 scripts for volume short press/long press with a higher step count in the long press script. I guess the only drawback to this is that on the long press you won’t get that ‘accelerating’ effect of starting slowly and then ramping up the steps.
I wonder how the holding of the button actually works, how does it know the difference between a long press, and holding down the button. Or is it that short press repeat only works if nothing is mapped to long press? Otherwise I can’t see how it would differentiate the two.
If both short and long press is assigned, pressing the button quickly will trigger the command for the short press. Pressing and holding the button will trigger the command for long press after a pre-defined timeout of 800ms. Keeping the button pressed after the long press command is triggered will invoke no action.
If only short press command is assigned, then pressing and holding the button will repeat the command, until the button is released. If the device supports special repeat commands (like IR devices), after the first command, a special repeat command will be sent until the button is released.
Well I made a quick application to call my HA Denon volume script over the LAN (and from my laptop over WIFI, just to compare apples to apples) with a simple ‘for loop’ just to see what the speed on the Denon would be like. It was significantly faster than associating it to the R3 button.
Not as fast as the Denon remote, but close enough that I would be happy with it.
So it seems that it is indeed to do with the delay between repeats of the button press commands, not much can be done about it for now until we can get a configurable timer for the repeat single press action.
Thanks Kenny, will reply to those tickets regarding the inter delay timing. However from a development point of view i get the difficulty this poses between the short press and long press. Because if we want both of those tickets implemented, we wont be able to get any timing we want. The inter delay of a short press and the detection of lomg press duration may overlap, limiting what timings can be provided.
What I will propose is a 3rd mode we could have for buttons, which is short press repeat ONLY. This would allow any timings we require.
So a button can either be:
Short press/Long press with limited timing adjustments
Short press repeat ONLY, which will allow whatever timing is required, forfeiting any long press on that button only.
This would allow the flexibility most people would need per button.
Also this needs to be configured on a per activity mapping, not a GLOBAL basis.
There isn’t a universal answer for this. Is the HA server and device your controlling on WiFi or Ethernet? How good is your WiFi setup regarding latency. What integration are you using in HA.
Unfortunately the Android ADB HA add on was deprecated. This is by far the fastest response times I have gotten through HA (Note, I don’t have my R3 yet). The reason being that all Android TV’s had custom codes. In fact with the python ADB HA integration you can still learn the commands, they just don’t work. I made a detailed video on this but YouTube took it down for hacking.
Obviously the below is Android dependent but if you are saying, still using your harmony hub with the HA integration then it has to connect to the hub via.the network or Bluetooth I believe anyways to send the command over BT to the hub, the. iR from the hub. I don’t think there’s a universal answer. If you have crazy low latency WiFi then obviously that will be faster than a flat LAN with 200+ devices and not enough AP’s.
Obviously the remote has to be WiFi but if everything else is Ethernet then it will be faster simply due to latency. Faster than Bluetooth or IR is going to come down to the device and integration. Android has generic commands that still work but not as fast with ADB as the dedicated codes.
When sending commands like UP, DOWN, HOME, etc. via ADB, the device can be slow to respond. The problem isn’t ADB, but rather the Android command input that is used to perform those actions. A faster way to send these commands is using the Android sendevent command. The challenge is that these commands are device-specific. To assist users in learning commands for their device, the Android debug bridge integration provides the androidtv.learn_sendevent action. Its usage is as follows:
ADB is not really fast only for certain commands. I tried to use adb for a dpad and it was awfully slow. On the other hand you can do everything with adb like input and output switching on Android TV TVs.
Only the R3 is wifi, everything else is LAN on Unifi network with about 4 AP’s through the house.
I already use the HA ADB in conjuntion with the Android TV Remote on HA, the ADB lets me use deeplinks on apps and force close naughty apps like WeTV which always seem to make the Shield lag after wakeup Basically inside my Wake Shield HA script is some ADB commands that force closes a list of naughty streaming apps. I find the AndroidTV HA Integration more than fast enough for single button presses.
In any case, I have since tested all connection methods now on each device.
DENON
IR
R3 Integration
HA Integration
In all 3 tests above, a single button press is fine, but holding down a button (like volume) is much slower than original remote
SHIELD
Bluetooth
R3 Integration
HA Android TV Integration
HA ADB Integration
Again in all 4 tests above, a single button press is fine, but holding down a button is much slower than original remote (like scrolling through a long EPG list in Tivimate).
For example, even using bluetooth on the SHIELD, the R3 just can’t keep up with the original remote when scrolling through a long EPG for example. This essentially takes out your concern over the network, this is where I think the repeat delay is the limiting factor.
As mentioned before, the network is fine as continually repeating the HA scripts via a application on the laptop over wifi is several times faster than the R3 via wifi or even bluetooth. I even made sure to test both the laptop and the R3 from the same AP when doing the wifi comparisons. I actually find the ADB and AndroidTV integrations on HA quite responsive, and the R3 AndroidTV Integration great as well provided it is only single press or quick press and release (like scrolling letf/right).
It’s when holding the button down is the issue.
Don’t get me wrong, I love this R3 and can see huge potential in it. I knew coming into this that there will be little gremlins to be ironed out.
@kennymc.c You are right, I did read that but my slow brain didn’t process it I think an option for the repeat delay should do what we need, and maybe an option to define how long a single button press actually is (i.e. Button down/up duration) for something that doesn’t have a long press defined.
Yeah, really sounds isolated to the R3 based on your thorough testing although if repeat commands were an overall issue with repeat commands, regardless of method then others have noticed similar behavior would really need my R3 but I was a late pledge so it gets here when it gets here but if it works from HA on a laptop then that rules out HA or network issues.is there a universal delay or delay you can set between key presses? Nevermind, your first post mentions this and it doesn’t seem like an option at this point but it would be nice to be able to tweak the inter-key delay and other delays like power on although most of that could be done through HA outside the repair command delay on the R3.
I don’t know why they got rid of the ADB add on so it was a full ADB server in a docker container but even the Python integration has the learnsendevent action due to all Android boxes having unique codes although generic ones still work. They just don’t work with the python solution. It was probably the fastest control method I’ve used. With that said this is something completely different isolated to repeat commands it appears.
I also force close some apps on my Sony Android TV, you can typically disable them unless you actually use them but some preinstalled apps just can’t be removed. I did get wake words working on my Android TV using Termux Wyoming but it doesn’t work through the remote, the TV has a mic as I was trying to get it work through the Sony remote.mic. Granted the R3 will at some point, hardware is there but software isn’t according to my knowledge. Just thought I would let anyone reading this know. It actually works perfectly with no false positives on wake word detection. Pretty easy to install on any Android phone. Just make sure to install Termux from GitHub, the one from Google Play strips stuff out. Also works in my nspanel pro 120. Off topic but might be useful to someone
If it’s an overall repeat command delay issue then it should be able to be fixed, especially using IR, if they allow users to modify the delay but I think you thoroughly ruled out everything but the R3 so pretty positive that’s were the issue is. Especially if it’s the same with native intrqtions on the R3 like Android TV not going through HA.
