I was responding to the post above mine where @reven6e suggested moving the intelligence from the remote to the dock for an ‘R4’ implementation if and when UC decide to produce another new remote.
Ralf, UC runs pretty hot. It runs through the battery in a matter of hours. And the constant connection issues are causing regular headaches - a few seconds lag before a command is triggered because the remote has to wake up from standby, reconnect to WiFi, reconnect to the entities in the activity, then trigger the command and receive feedback. Even after I disabled the standby altogether and programmed it to always stay connected to WiFi, I continue to have these problems.
Why is this happening? The handset runs the OS. This means heat from the SOC or whatever is used here, this means battery consumption, this means that if the internet connection is dropped, the whole activity times out and you are stuck with a red screen.
Now imagine the UC server runs on the dock, connected to your switch / router with an Ethernet cable. You can remove most of the electronics from inside your remote as the handset becomes purely a controller with a display. The handset will stay cool. The handset will use less power. And you will have space for say larger antennas inside the handset for better connectivity.
The dock on the other hand can have active cooling if needed and more space for beefier hardware, extra ports, other protocols (Zigbee etc). Because you are hardwired your activity will NEVER be dropped even if your handset disconnects. At worst you will have a delay until the server receives the command from the re-connecting handset but no red screens and activity failures. The connection itself between handset and dock can occur over Bluetooth rather than WiFi, which in close proximity would probably be more reliable than WiFi.
The server CAN run on the handset but should it run on the handset? I say no and all the major players in the field seem to agree with me. The dedicated server, whether a hub, a standalone dock or a rack mounted solution is the common solution in AV installations. It’s more reliable, it’s more powerful and it is more flexible than a hot running, battery eating and constantly lagging handset. Power management and network connectivity might improve with future firmware updates but the fundamental issues remain and, really, the dedicated server is a no brainer.
Another bit of experience I would like to share. Those of you who have a mixture of IR and IP controlled devices with multiple activities might have encountered annoying behaviour when switching between activities. Logitech Harmony was switching activities seamlessly knowing what to power on and off without user intervention. UC doesn’t. Some useful info is found here about the steps involved but it’s not a straightforward setup and for me it has been trial and error so far.
First of all you have to include your activities in a group. Then you have specific settings for switching activities within the group - how to deal with delays and the off sequence.
The main issue is with IR devices. Note in the link above that UC can not check their state so it is a case of “best effort”. According to the documentation UC switching will only recognise the POWER_ON & POWER_OFF (or POWER_TOGGLE for “dumb” devices) IR commands. Any other command name will NOT be identified correctly and will lead to incorrect powering on / off. Be warned however that in my experience even the POWER_TOGGLE IR command is not used correctly in a switching sequence.
What have I done to address this: I have created a POWER_ON and a POWER_OFF IR command for my Gryphon Diablo using the same IR code (the toggle on/off code) and bingo, Gryphon is no longer turned off when switching between activities.
The second offender was my projector screen which had an Up and a Down command. When I would switch between say my Apple TV activity and my Blu-ray playback the screen would go up and then down again. Once I renamed the Down to POWER_ON and the Up to POWER_OFF the remote stopped moving it when switching activities.
I would also draw your attention to the player / remote entities of many integrations. While the commands seem similar, their functionality depends on your usage scenario. For instance my Lyngdorf amplifier has a player component (streaming via ethernet, Airplay etc) and a remote component. If for instance I assign the physical volume buttons on the remote to the Volume Up/ Down Player controls in an activity which is not actually using the internal player (say using an external Blu-ray player as source, Lyngdorf acting purely as a preamp / amp) the physical buttons will fail to control the volume in the activity. In this case the physical buttons have to be assigned to the Remote volume controls. If on the other hand I would assign the Player volume commands to the physical buttons during an activity where I stream music using the internal Lyngdorf player, the volume buttons would work correctly. But the remote volume buttons would also work, regardless.
So pay attention to the difference between the Player and Remote entities for your integration. Using the Remote rather than the Player commands is generally a safe bet, particularly for the physical buttons (D-pad, volume, mute etc). It makes sense if you think about it but it is not something obvious.
I continue to experience annoying issues with integrations timing out (the main culprits at the moment being Oppo and JVC) and I haven’t figured out a way to control my dCS Vivaldi stack yet. I would also like to try the 5V trigger function of the dock with my screen - it’s not needed as IR works well so far but for testing purposes. To be continued.
Regarding your experience with volume commands: This might only be an issue with the specific integration you’re using and could be a bug.
Usally it shouldn’t make a difference which entity type your using for a command. Also there is no difference for an integration wether the command was triggered from a physical or a soft/display button.
The only thing you need to be aware of that if you’re mapping remote entity commands to a physical button and you press and hold that button the command will be automatically repeated 4 times by the remote itself. This doesn’t happen with media player commands and is the expected behaviour according to UC. Most likely a workaround until native detection of holding a button is implemented.
You might be right but since we all have one amp our experience is limited to the specific hardware.
My Lyngdorf processor will not take volume commands in an activity with a Zidoo player from the physical buttons linked to the player entity as for some reason the remote overrides my settings and tries to control the Zidoo player volume instead. In other activities (Apple TV) the player controls work but using the volume buttons overlays on the screen a volume level which I personally dislike. The remote entity on the other hand adjusts the volume without the screen overlay.
So behaviour varies and one should experiment if things don’t work properly or if one would prefer it one way (screen volume overlay) over the other (no overlay).
And another thing - the slider control below the screen can now adjust reliably certain parameters.
I tried the Seek function with Apple TV, Oppo etc but I didn’t find it particularly accurate or useful and for this purpose I still prefer the physical buttons.
Controlling the volume of my amp with the slider on the other hand works faster than the physical buttons. So what I tend to do now - I use the slider for say jumping from 40 to 80dB as the adjustment is instant and then I fine tune the level with the physical buttons (which work in 0.5dB increments). Using the volume up / down a jump from 40 to 80 would take at least 5 seconds and repeat presses and I don’t find the volume buttons particularly tactile or ergonomic.
So for those of you who have dismissed the slider in the early days and have ignored it since, consider revisiting it as it is more than a gimmick now.
This sounds more like a HDMI CEC issue which should be disabled anyway when using a universal remotes.
If you map a command to a button only the integration that is liked to this command will receive this command. This applies to all integrations as this is how the remote core/integration api works.
Interesting observation on the Lyngdorf. Initially, I also did not like the display overlay when changing the volume with the media entity. In the meantime, I find it quite useful, however, I wish it would use the same scale as the Lyngdorf. Just tested your other observation: at least on my TDAI120 the volume control of the media entity works in all my entities, including the ones that do not use the integrated streaming module. E.g. it works with a CD Player connected to one of the digital inputs.
CEC disabling is the first thing I do when setting up new AV devices. The only time I got CEC working reasonably well was in the days of a Sony TV with a Sony soundbar. So no, not a CEC issue. Unless Zidoo, which is a buggy mess, ignores my settings which is also possible.
Heimspielvier, try the touch slider. It works well with Lyngdorf.
And another difference between the player and remote entity, specifically for Lyngdorf. If I use the player entity to switch inputs, I need to set up a delay of over 8 seconds between the power toggle and input switch. If I use the remote entity Lyngdorf executes the input switch after 3s.
Again, this could be device related but it is worth experimenting if you have both entities and one doesn’t work as smoothly as you would like it to.
Another thing to consider. Harmony had an Activity screen and a Device screen. Should an activity fail to correctly trigger a boot sequence for a specific component for instance, you could flip to Devices, select the device that failed to power on and manually toggle it from there, then return to your activity.
UC does not have this function and if a device fails to power on, you have to reach for the original remote.
A solution (there might be others): I created a Devices page, similar to Harmony. Then I created separate activities for each component which are listed on this page. Each such bogus activity includes only one integration - the device I am controlling with it. Such a “device” specific activity has no on/off sequence, just screen / button assignments for powering on, input switching, volume control etc.
So if a UC activity fails to wake up a device, I can go to the Devices screen, select the component and power it on from here. Then I can go back to the original activity. Since no on / off sequence is configured for the specific device activity, switching will be seamless.
This will not work with IP controlled devices because, if an IP control fails, the whole activity times out / fails. But it is useful for IR controlled devices, which are less reliable with UC.
Hi,
You already have a “device screen" if you open the device entity. Furthermore if the activity is running and you tap into the middle on top of the screen a list of all included entities is shown and you can open it direct from the activity.
Ralf
How do you open a device entity on the remote when no activity is running?
Also I tried getting the list of entities directly from an activity but I did not see the option to, for instance, power cycle a specific IR controlled component. Keep in mind, I am talking IR. Not IP controlled devices. And it is IR where UC is mostly hit and miss.
Did you tap on top of the screen while activity is running?
Create a page in customize your remote and add device entities to this page.
Btw. Which firmware are you using. Latest is 2.8.4 for R3 and 2.8.5 for R3. Although they are beta they are stable.
Ralf
Correct, 2.8.4. The problem with your method is that yes, you can create a custom page for Devices just as I suggested above. But if you populate this page with entities, they are only listed. Once you select one from the list, you land on an empty page. Whereas if you create an activity for each device, you can customise each device page and assign buttons and controls. I don’t know if I make myself clear. It’s a small change but it makes a big difference in functionality.
If your devices are remote entities you can map buttons and customize the user inteface of this remote entitiy similar to an activity but of couse only with commands from that entitiy
Yep, you are right. I see it now. IR entities also have User interface / Button mapping tabs. I didn’t notice this before, my bad. Thank you.
Thanks for the tip with the touch slider. It does indeed work nicely with the Lyngdorf integration for changing volume. When I initially tested the touch slider I found it quite clumsy and fiddly to use (but that was with another integration).
I am still curious about your comments about the differences you see when using the media player vs the remote entity of the Lyngdorf integration. My remote almost exclusively uses the media player entity and I am not seeing any delays or issues.