Better HDMI-CEC controller

[retsyx]

HDMI-CEC is supposed to allow universal home theater control but tends to fail in practice. Mostly because devices don’t cooperate very well, steal inputs, and don’t always follow the spec.

An Omote HDMI-CEC accessory may be the fix.

HDMI-CEC’s input stealing problem stems from no one device having authoritative knowledge of user intent. So devices vie for input based on bad guesses, and manufacturer whim.

With a Logitech Harmony-like activity concept, an Omote can be the authority. Then the question is how to bend HDMI-CEC to do what it should. If the home theater uses a receiver for input source selection, then there is a way.

A minimal device, an Omote CEC controller, can splice into the HDMI-CEC wire between the TV, and the receiver while passing through all other HDMI signals as-is.

The controller will operate by partitioning the CEC network into two. In one network it will act as the sole source for the TV, and in the second network it will act as the TV, coordinating inputs as instructed by the Omote controller in your hand.

The CEC controller can control source devices as a TV would (turning them on, putting them in standby, controlling volume, and even relaying button presses) while knowing to ignore source requests from devices (because it authoritatively knows the users desired activity, and thus which device should be the source input), and the TV will never see them because it can only see the Omote CEC controller.

It seems that the implementation can be very, very simple. Generally, HDMI’s high rate signaling is very demanding of PCB layout. Except the CEC pin which is a very low rate serial signal. It seems a prototype could be built with an ESP32 with two GPIO pins connected to a cut CEC pin wire of a standard HDMI cable.

Hopefully, a final controller PCB would be easy to design because all the high rate HDMI signals are passed straight through.

For HDMI home theater systems, this could fix the current HDMI-CEC headache, and be simpler, and more reliable than IR.

Thoughts?

[KlausMu]

Sounds interesting. It seems there already exist some projects that can deal with the CEC protocol, and it was already done with an ESP32.

https://github.com/johnboiles/esphome-hdmi-cec
https://github.com/Palakis/esphome-native-hdmi-cec
https://tasmota.github.io/docs/HDMI_CEC/

The CEC controller would also need to switch the HDMI signals, right? So this controller is not completely trivial. It had to switch the whole HDMI connection, not only the CEC pin. Is this correct?

With such an CEC controller, OMOTE would have another way to control the devices. Currently we have bluetooth and IR. With that we would have CEC.

Until now, for me bluetooth and IR were sufficient for all my devices. Maybe an IR satellite would be helpful in some situations. My guess is, that an IR satellite would be much easier to achieve than an CEC controller.

Are there any other advantages of the CEC controller I do not see?

[retsyx]

I don't think so, no. The controller doesn't need to do anything with the HDMI signal itself. That's why tapping the CEC, and ground wires on a standard HDMI cable is functionally complete. The controller design would need to minimize signal interference but I think it can be done with only traces on a PCB (I'm not a HW engineer).

So you would break up every single HDMI connection and would attach every single CEC to an ESP32 pin? One ESP32 pin for every device involved?

No. There would be only one ESP32 CEC controller. Between the TV and the AVR. CEC creates an ad-hoc network that all devices can see and participate in. An Omote CEC controller would effectively partition the CEC network into two CEC networks. One network with only the TV, and one network with all the other components and itself as acting TV.

If I still did not get it, could you please provide a schematic drawing?

Here are a couple very rough diagrams of a simple HDMI setup.

The first diagram shows the system as it is today. One TV, one AVR, and three A/V devices. The lines between the boxes are HDMI connections. The double lines are the A/V lines in the cable, and the dashed line is the CEC wire in the exact same physical cable.

The second diagram shows how the Omote CEC controller would work. In this case, only the CEC wire is handled by the controller. The rest of the signal wouldn't be touched. In the case of carefully stripping a standard HDMI cable, this would be the CEC wire pulled out of the bundle, cut and spliced to two GPIO pins. In a final device, all the signals would go through the controller housing, the CEC wire would go to the two ESP32 GPIO pins - one for each side of the now partitioned CEC network while the A/V signals would be bridged directly between the HDMI connectors without any active components in the path.

My guess is, that an IR satellite would be much easier to achieve than an CEC controller.

With the usual caveat that other CEC devices need to be well behaved (not always true), I think CEC is easier. There is no need for an IR code library, or to learn IR codes. There is no placement problem (that an IR hub seeks to solve).

But you cannot completely avoid IR, right?

Maybe not completely, but I suspect that it could potentially avoid it for the vast majority of users. It would make the IR database less critical.

Or how do you switch on the first device? To my understanding, for HDMI-CEC normally the TV is the master, and only the TV remote is used for all the devices.

Omote CEC would act as an A/V device to the TV, and act as the TV device for all the other devices. The TV would not see the other devices.

At least the TV remote has to be replaced. This replacement would be OMOTE, sending IR commands. Right?

The idea is to replace the TV remote. Many (but perhaps not all) commands, like volume control, power/standby, and menu navigation can be communicated over CEC. That's part of CEC's promise already - that you can use one remote, typically the TV remote, to control other CEC compliant devices. There is no need for IR for typical functions, they can be relayed over CEC.

Does that make sense?

[KlausMu]

Ok, thanks, this makes it clearer.

I have some questions about the routing of messages:

• So the AVR always routes all CEC message from the TV (or the CEC controller) to all connected devices on the right side?
• And all messages from one of the devices on the right side are routed to the TV (or the CEC controller) on the left side?
• Do the devices on the right side see each other? Is this even needed?

To understand how the controller could improve the situation, I have some questions. In your first post you wrote that in real life HDMI-CEC causes problems. What kind of problems are these? And why will they not happen anymore with the Omote CEC controller?

Do you have an example

• of a specific action (and the CEC message that would normally been sent for this action)
• how this could lead to an misbehaviour
• how this would be avoided by use of an CEC controller (which message would be sent instead by the controller)

[retsyx]

These are all good questions.

I had typed out a detailed reply but then read the spec. again and realized that I may have missed something important. I'm going to do some stripped cable testing to see if what I want to do will work well or not.

For your reference, a PDF of the CEC spec. is available for download from here. Section 13.1 in the document applies to the source selection process I want to 'fix'.

Also, CEC-O-MATIC is a handy resource for constructing, and deconstructing CEC messages.

I'll update if I have news.

[retsyx]

Ok, thanks, this makes it clearer.

I have some questions about the routing of messages:

• So the AVR always routes all CEC message from the TV (or the CEC controller) to all connected devices on the right side?

The AVR will route message as necessary. So it will rebroadcast broadcast messages to all devices and forward directly addressed messages to the addressed devices.

• And all messages from one of the devices on the right side are routed to the TV (or the CEC controller) on the left side?

Yes, the TV will get broadcasts and messages addressed to it.

• Do the devices on the right side see each other? Is this even needed?

All devices can communicate with each other. If one device is presently being used by the user for control (as the video source) and another non-AVR device is the audio output device, then they would need to communicate to change volume. From my experience, all devices can communicate.

To understand how the controller could improve the situation, I have some questions. In your first post you wrote that in real life HDMI-CEC causes problems. What kind of problems are these? And why will they not happen anymore with the Omote CEC controller?

The protocol is ill-conceived, and doesn't serve its purpose well. As a result, devices have to often guess the user's intent based on hints of activity (or manufacturer commercial interests). For example, if a device powers up from standby, is that because the user intends to do something with it? Who knows. But I've seen a TV assume that, and switch over inputs to the device, interrupting an already running activity. Similarly, devices will see the TV powering up, and assume it is for them, and so they declare themselves as sources, racing with each other. If you search for people's problems with HDMI-CEC, this input stealing comes up often as a problem.

In my experience, a dedicated CEC controller (i.e. an Omote CEC controller) avoids these problems by avoiding these guessing games. For example, it need never declare its power status to source devices to avoid the race. It can ensure the TV, as the authority of an HDMI-CEC bus does very little and doesn't try to select the wrong source.

I've been toying with this concept for a while and have something that works very well for me, using a Raspberry Pi. My system never worked correctly with HDMI-CEC enabled before (constant input stealing), and with my controller in the middle, it now works flawlessly. A nice side effect is that very little configuration work is required by the user. HDMI-CEC allows auto-discovery of (well-behaving) devices and from that it is easy to auto-generate activities.

My testing has been restricted to the equipment I have - LG OLED TV (used as a dumb TV), Denon AVR, Apple TV, Sony Playstation 4/5, Nintendo Switch. I also very briefly tested an Amazon Fire TV stick. While it works excellently for me, and seems generally promising, I don't know how widely applicable this solution is. It is a bit of a mystery. Given the nature of HDMI-CEC, the only way to know is by testing more hardware. It also doesn't work with non-HDMI-CEC capable gear (which is where the rest of Omote functionality would take over to offer a seamless experience).

I've posted the Raspberry Pi based controller source here. It requires splicing the HDMI-CEC wires in an HDMI cable to GPIO pins. The COTS HDMI breakout boards I could find severely degrade HDMI video signal to the point that they are unsuitable for a home theater.

[KlausMu]

Ok, thanks for clarification.
It seems, such an CEC controller could mainly provide two benefits:

1. auto discovery and auto generate activities
   This would be indeed very convenient. Unfortunately currently the OMOTE remote is not able to auto generate any configuration. There is not even a GUI for defining the devices, scenes etc. So the autodiscovery would maybe only be helpful to know the addresses of new devices, and maybe some capabilities of them, if the protocol announces them. So for OMOTE, the benefit is currently limitited, I think. The firmware still had to be adjusted by the user to use the device

2. Solve the input stealing problem by breaking up the connection to the TV
   As you already have a working CEC controller based on Raspberry Pi, this approach seems to solve the problem.

I think, such a CEC controller could work well together with an OMOTE. The controller could simply be controlled via MQTT. You could extend you Raspberry Pi project to be controllable via MQTT, then it would perfectly work together with OMOTE.

A controller based on an ESP32 of course would be much cheaper and handier. But someone had to build it ...

OMOTE until now works very well with IR and BLE, with which you can achieve more or less the same as with HDMI CEC. But who knows, maybe someone is willing to build such an ESP32 based controller.