IR compatibility

General
61

A brief update on my ongoing experiments with system control.

I was unable to get the dCS stack working reliably with the UC IR integration, despite trying different codes, settings and blasters. As a last resort, I decided to try serial control using a Moxa S9650. I am pleased to report that this has been a success. I can now control the Vivaldi stack reliably using the “HTTP Requests” integration.

There is, however, a downside: I had to disconnect the original serial connection to the Vivaldi stack, which means I have lost Mosaic control. I can still use Roon for playback, but I can no longer access the advanced settings through the Mosaic app. So there is a trade-off.

The Grandview screen was the next component to receive the serial treatment. Apart from the minor adventure of having to order three different custom cables before getting the RJ12-to-DB9 pinout correct, this also works extremely well.

These two successes have encouraged me to consider expanding serial control to the Lyngdorf, JVC, Oppo and Zidoo.

The reason is not that I have lost faith in the people developing the UC integrations. Quite the opposite — I think it is impressive how much has been achieved by a relatively small community. The problem is that my system now contains 15+ individual components, each with its own integration, network behaviour, firmware, API or control protocol. In practice, almost every evening something eventually times out or misbehaves, whether when initiating a sequence or when an activity is ending.

At this scale, there are simply too many variables. An integration can work perfectly well in the developer’s environment and still behave differently with a particular combination of hardware, firmware, network configuration and system state. Some developers understandably don’t even have access to the hardware they are developing against, which makes reproducing and troubleshooting these intermittent problems extremely difficult.

This has led me to consider a slightly different architecture.

Rather than having UC act as the primary system controller, I am increasingly tempted to move the actual system control and activity logic into Home Assistant, with the Moxa providing the hardwired serial control wherever possible. UC would then essentially become a very sophisticated and beautifully over-engineered HA controller/interface.

There are obvious advantages to this approach:

  • hardwired control wherever the equipment supports serial;

  • very fast and deterministic communication;

  • fewer dependencies on individual UC integrations;

  • activity logic and system state managed centrally in HA;

  • the AV system can continue operating even if the UC loses its Wi-Fi connection;

  • considerably fewer network/API variables in the critical control path.

The obvious downside is losing some of the functionality that makes UC attractive in the first place, particularly the integrated players and some of its more advanced native features.

I am still weighing the options, and I certainly don’t regard this as a criticism of the UC ecosystem. In fact, the ecosystem has expanded dramatically since the early days and, overall, I find the platform much more reliable than it used to be.

However, in my particular installation, the Remote 3 still misfires often enough that I am no longer convinced the remaining problems can simply be attributed to Wi-Fi. Troubleshooting 15+ separate components and their respective integrations every time something randomly times out is becoming increasingly tedious.

So my current thinking is that serial control + Home Assistant may be the next step, with UC retained as the user-facing controller rather than being responsible for the underlying system reliability.

To be continued…

62

This is the way I ended up taking. Not at once, but gradually moving towards home assistant.

My system is nowhere near as complicated as yours, but I do use IR, Bluetooth, WiFi and Ethernet IP connections to control my components. And at the moment the UC remote is controlling none of them directly, except for Bluetooth for typing on the Apple TV). Every button or control is a home assistant control and home assistant controls the components and the Broadlink IR blaster (very nice, versatile, stable and well priced).

I haven’t regretted it for a second.

Home assistant is a lot more stable than the remote and even better: it provides ways to (automatically) check for errors and fix them, acting as safeguards. When the safeguards fail, it sends a message to my phone too.

One one hand it’s a shame I use this expensive remote merely as a shell of what it can be, but home assistant makes the entire experience way more powerful and reliable.

And for media players I haven’t noticed any difference compared to the ones in natively installed integrations.

63

Any noticable delays?

Especially when adjusting volume?

64

No, it’s the same as when controlled by the remote itself.

65

A short idea for IR problems. There is a Broadlink integration which should support more protocols and as a bonus it supports 433 MHz which I needed for my motor screen.

Btw. I have 20+ devices programmed but a lot similar devices most IP controlled.

Ralf

66

Most Integrations use the same protocols and libraries as the ones in Home Assistant so if your only having problems with them on the remote it’s most likely the WiFi connection and not the integrations itself.
Some people have noticed better performance if they move or add an access point closer to the remote. In comparison to other devices the remote has a much weaker WiFi reception.

67

HarmonyFan, thank you for your suggestion, but unfortunately the IR issue with the Vivaldi goes further than simply finding a better delivery system.

The Vivaldi is now more than 20 years old and uses RC5. There are no Vivaldi codes in any of the known universal IR libraries. Harmony didn’t have any, which is ultimately how I ended up using the UC in the first place. Global Cache doesn’t have them either.

The codes available for the more recent Rossini don’t work with the Vivaldi, and neither do the codes for the older Scarlatti and other dCS models.

dCS themselves have been rather unhelpful on this. I suspect the IR/IP/Mosaic control system may have been outsourced, because all they could really tell me was to read the manual.

There is another complication, regarding the original dCS remote: the handset sends multiple IR codes simultaneously when, for example, you press the power button to switch on the DAC, Upsampler, Clock and SACD player together. If you try to learn those codes with a universal remote, the learning system identifies only the first code in the sequence, which isn’t particularly useful.

So, despite trying different IR codes, settings and blasters, I could never get reliable IR control of the Vivaldi stack through the UC.

Until I started experimenting with the serial interface, the Vivaldi essentially had to be controlled manually with its original remote.

The good news is that the serial route has finally solved the problem. Using a Moxa S9650, I can now control the entire Vivaldi stack reliably, including power and other functions, and integrate it into the UC/ HA via HTTP commands. It turned out to be a much better solution than trying to make the IR control work.

68

The worst offender at the moment is the madVR Envy Core, but I still get occasional random issues with the Oppo, Lyngdorf, JVC, etc. Individually they are rare occurrences, but taken as a whole, there always seems to be SOMETHING that doesn’t respond as it should.

And no, this isn’t a Wi-Fi issue. All of my components are hardwired. The sequence typically consists of multiple commands/actions, and at some point along the chain something fails.

The Cisco AP is in the same room as the remote, and I’m using 2.4 GHz, which in my experience has provided the most reliable connection. Reliability did improve considerably perhaps 6–12 months ago, but some of the more recent firmware releases and integrations, which were specifically intended to address these reliability issues, have actually brought some of the problems back in my particular setup.

Frankly, I’ve reached the point where I no longer have the patience to contact individual developers, reproduce the problem, download logs, send them over, wait for a response, and repeat the process for every individual integration.

It is simply easier for me to move as much as possible to serial control.

And so far, the serial connection has been absolutely bulletproof. That’s really what convinced me to go down this route.

69

I’d also like to eliminate the last remaining potential weak points in the UC setup: the Wi-Fi connection to the remote itself and the ongoing uncertainty around beta firmware.

My plan is therefore to move as much of the control logic as possible onto the hardwired Home Assistant server. The UC would effectively become a pretty but relatively “dumb” controller for HA, rather than being responsible for executing the entire activity and coordinating all the individual devices.

That way, even if the UC temporarily loses its Wi-Fi connection, the worst that should happen is that a command from the remote is missed. It shouldn’t be possible for an activity that has already started to fail halfway through because the remote has briefly dropped off the network.

It also means that the critical control logic is no longer dependent on whatever changes or unknowns may be introduced by future beta firmware releases or integrations on the UC side.

The actual logic and device control would remain on the hardwired HA server, with serial, IP and other control methods handled there.

So the UC becomes essentially the user interface, while HA becomes the control layer. Given that the serial connections have so far been rock solid, this feels like a much more robust architecture to me.

I still get to keep the nice remote — I’m just no longer asking it to be the thing that keeps the whole system together.