Replies: 1 comment 7 replies
-
|
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 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? |
Beta Was this translation helpful? Give feedback.
-
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.
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.
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.
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.
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? |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thanks, this makes it clearer. I have some questions about the routing of messages:
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
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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.
Yes, the TV will get broadcasts and messages addressed to it.
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thanks for clarification.
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. |
Beta Was this translation helpful? Give feedback.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions