4 ms·
I think a major problem with HDMI-CEC from the perspective of folks who want to say control everything with Home Assistant is that it's not "make all the device
by scottlamb 2y ago
I think a major problem with HDMI-CEC from the perspective of folks who want to say control everything with Home Assistant is that it's not "make all the devices on the bus controllable by my home automation setup" but "allow each device on the bus to talk to each other". With no particular standardization about what one device does in response to another or how that's configured, and possibly the vague expectation that the TV drives everything.
As a tiny example, by default when I turn off my AV receiver, my TV notices and turns itself off too. (Or maybe it's the reverse, or both. Don't remember.) This behavior is controlled by a poorly-named item deep in the TV's menu, and by enabling/disabling CEC on the receiver. (The latter is what I chose because it still passes CEC signals through source<->TV and has a better-defined automation protocol of its own.) Who knows if some other TV has the same default or has any way to control it, much less a way I can describe without getting into the specifics of each model.
To make it really useful for a well-controlled HA setup, I think at least I'd have to have some sort of device has a bunch of HDMI in and out ports and intercepts all the HDMI-CEC signals so the devices no longer talk with each other but instead with something I control. That takes it from an O(devices^2) interop problem to an O(devices) problem. Even then I'm not sure it's really tractable. There needs to be more standardization.
- pathartl 2y agoThere needs to be more configuration, which I don't know that CEC supports. I think it's fine to have a mode where it fits 80% of scenarios where your STB remote can control your TV and sound bar, but doing anything other than that is so limited.
- 15155 2y agoAn FPGA HDMI switchbox implementing programmable CEC for all ports is 100% doable.
- scottlamb 2y agoI don't think you even need an FPGA. I believe the article is correct that "CEC merits its own special pin", so you wouldn't have to do anything fancy with the high-data-rate lines. But it still means building something (I looked a while ago and didn't find one being sold) to achieve less than what you'd get out of the box if the protocol were properly designed for this use case. So in my personal project idea list, it's firmly below a bunch of other stuff I'm also probably never going to find the time for.
- tadfisher 2y agoBack in the day, I installed 3 CEC breakout boxes in-line with a TV, a receiver, and a PS3, plugging them all into a Raspberry Pi (first-gen). The Pi easily handled dispatching between them, and I used an existing Rust crate to build a simple REST service to control the devices over the network (from my phone). A bonus was that my TV didn't support CEC; it had one of those mini-audio-jack-looking RS232 connectors, and there happened to also be a Rust crate which spoke the protocol.
- scottlamb 2y agoI chuckled because I also wrote my own home theater controller controller (in Go) "back in the day"—which in my case means before Rust reached 1.0 much less had nice existing crates for this kind of stuff. But quibbling about that phrase aside, I'm glad to hear about your positive experience doing this. 3 CEC breakout boxes = 1 for the PS3 + 1 for the receiver + 1 for what, given that the TV didn't support CEC? Did the receiver and PS3 have other automation options? In theory I'd like the idea of "just implement CEC and you're done". If that were really viable, I would have released my home theater controller in a form useful to people who don't happen to have the exact same media components I do. But my experience is the proprietary APIs are generally better. Some exceptions. My (ancient by now) Bluray player's REST interface has something like 200 ms latency. As a hint to why: the URLs contain `.cgi`. It's awful.