Support for HDMI CEC

[anishsane]

I recently came across a great library at https://github.com/s-moch/CEC/.

With a simple connection (connect ESP-01 GPIO3 pin to pin 13 of the HDMI connector and ground to ground), I could send and receive the CEC messages over HDMI CEC.
Using this, we can control HDMI-enabled devices over the network. I was able to control my TV, raspberrypi and a firestick from the same esp01-based device over the network.

Tasmota already has a great support for IR tx/rx using ESP8266IR library.
We can use the IR+CEC combination as IR-blaster extension.

What can CEC do that IR TX cannot do:

1. It can check the current state (powered on/off), currently active source (HDMI 1/2/3/4) etc.
2. It can also monitor the CEC traffic and thus has the potential for some automation/query over the network.
3. It can also control the devices with unknown IR protocols or devices with bluetooth/RF controls, so long as they support CEC.

The proposal from the new addition POV:

1. New type in the template to configure a GPIO pin as CEC (The same pin can be used for tx and rx.)
2. Commands - cec_configure {json data to be saved}, cec_tx raw:cec:message:to:be:sent
3. Automatic answering of specific requests - e.g. osd_string, manufacturer name, logical/physical address etc with values configured via cec_config.
4. MQTT support: Send the raw data received/sent to mqtt server
5. rules support: on cec_received#raw_data do endon

Of course, the MQTT and rules support is only for automation purposes.

Note: the code from the link works as-is. I only added the network connectivity to the code from the above link.

[pkkrusty]

I fully support this idea. Lots of use-cases. I will be on the sidelines cheering on the coders doing the real work.

[s-hadinger]

Wow. I love it. I'm just concerned by the physical aspect. HDMI connectors are so tiny. Is there a way to nicely isolate the CEC pin on an hdmi connector?

[sfromis]

In general, the ESP8266 works fine with 150 mA current (doing that when flashing and debugging), and normally workable below that (likely with weaker Wifi coverage).

[s-hadinger]

The work for doing a PR should be similar to ir-full. It's about defining a new GPIO type and deciding what json payload are needed for sending and receiving

[barbudor]

But if the esp is powered by the TV, doesn't it means that it needs the TV to be on?
Doesn't it miss some use cases then like being able to power the TV?

[sfromis]

Well, the TV won't react to CEC signals unless already being on to some extent, basically sleeping on vampire power. My starting guess would be that if it listens to CEC, it would also provide power, but that's of course not a solid assumption.

Of course, if the use case is to send a signal to a relay cutting on/off mains power to the TV ....

[s-hadinger]

Enabling CEC disables low-power mode on my TV. So I suppose that 5V would still be present.

[anishsane]

One note for whoever implements this:

The code from the above link has a logic to force the "SENDER" device's logical address to yourself. I.e. You cannot pretend to be another sender connected to another HDMI port. (Use Transmit function vs TransmitFrame)
We may want to skip that logic if we want to send a raw frame that the user asked for.

Others, add more of such caveats to this thread as they are found.

[s-hadinger]

I just tried connecting an ESP8266 to HDMI CEC, and it works. Good news is that you can directly connect a GPIO to HDMI CEC, no need for any transistor. Voltage is correct.

Now the bad news is that the library is half baked. Like many Arduino libs, it expects to be called continuously at least every millisecond, and was not designed to coexist with anything else.

So currently, the only way to make it work is to use Sleep 0. This way at least it gets all messages.

Example:

00:00:00.101 Project tasmota - Tasmota Version 13.1.0.1(tasmota-4M)-2_7_4_9(2023-08-23T17:26:12)
00:00:00.102 CEC: HDMI CEC initialized on GPIO 2
00:00:00.144 CEC: Packet sent at 215: 44 

00:00:01.010 CEC: Packet sent at 1597: 88 NAK
00:00:01.011 CEC: Device ready, Logical address assigned: 8
00:00:01.157 CEC: Packet sent at 1744: 8F84200004 

[Later - sniffing communication between Apple TV and SONY TV]

18:05:01.114 CEC: Packet received at 57702: 45 NAK
18:05:01.152 CEC: Packet received at 57739: 45 NAK
18:05:01.197 CEC: Packet received at 57785: 45 NAK
18:05:01.302 CEC: Packet received at 57890: 4F9040 NAK
18:05:01.385 CEC: Packet received at 57973: 4F9000 
18:05:08.443 CEC: Packet received at 65030: 44 NAK
18:05:08.481 CEC: Packet received at 65069: 44 NAK
18:05:08.576 CEC: Packet received at 65163: 40 NAK
18:05:08.615 CEC: Packet received at 65203: 40 NAK
18:05:08.655 CEC: Packet received at 65243: 40 NAK
18:05:08.710 CEC: Packet received at 65297: 45 NAK
18:05:08.745 CEC: Packet received at 65333: 45 NAK
18:05:08.782 CEC: Packet received at 65369: 45 NAK
18:05:08.954 CEC: Packet received at 65542: 4FA606105610 
18:05:09.076 CEC: Packet received at 65663: 4F8C NAK
18:05:09.286 CEC: Packet received at 65874: 4F85 
18:05:09.390 CEC: Packet received at 65977: 4F9000 
18:05:09.445 CEC: Packet received at 66033: 45 NAK
18:05:09.481 CEC: Packet received at 66068: 45 NAK
18:05:40.048 CEC: Packet received at 96635: 44 NAK
18:05:40.086 CEC: Packet received at 96674: 44 NAK
18:05:40.143 CEC: Packet received at 96730: 40 NAK
18:05:40.182 CEC: Packet received at 96770: 40 NAK
18:05:40.224 CEC: Packet received at 96811: 40 NAK
18:05:40.281 CEC: Packet received at 96869: 45 NAK
18:05:40.317 CEC: Packet received at 96905: 45 NAK
18:05:40.353 CEC: Packet received at 96941: 45 NAK
18:05:40.710 CEC: Packet received at 97298: 4F84200004 
18:05:40.787 CEC: Packet received at 97374: 4F85 
18:05:40.897 CEC: Packet received at 97484: 4F9000 
18:05:40.957 CEC: Packet received at 97545: 45 NAK
18:05:40.993 CEC: Packet received at 97581: 45 NAK

[anishsane]

Yes. You are right.
I integrated the files into tasmota code.
But I faced the same issue.

The library is polling-based. We have to call the run function the arduino.ino's loop function.
The fast loop (xdrv function type FUNC_LOOP) in tasmota is not fast enough. In my experience it gets called approx at 50 ms interval on esp8266.

I think we need to convert the logic to interrupt-based (similar to IRremoteESP8266). I have not made any progress on this approach.

[anishsane]

I did not know about sleep 0. I will try it with my local changes.

[s-hadinger]

From what I understand, the protocol is very slow. So it should run entirely as interrupt driven, like some serial drivers below 9600 bauds. But that's some decent work.

I2C looks similar, so maybe we can copy some good ideas.

[s-hadinger]

I took a deeper look. Actually the code is already asynchronous for Tx/Rx. So I'm optimistic that it should be easy to turn it into interrupt/timer driven while keeping most of the state machine code.

I'm still new in HDMI CEC, but I understand that Physical Address discovery requires also access to EDID, which means configuring I2C and reading device address 0x50.

Do you know to what extent the discovery of physical address is important?

I plugged my ESP8266 on the same HDMI as Apple TV. Is it possible to have 2 physical addresses on the same HDMI port?

[sfromis]

For "easy" HDMI connectors, pkkrusty also recommended this breakout board: https://www.aliexpress.com/item/1005004343592426.html

[anishsane]

I think the prime reason I like ESP-01 is its 2.54mm pitch - I can use it easily on any general-purpose PCB.
Especially if I need to drive just 1-2 relays from it, it is sufficient and I got it cheaper locally than the other form factors.

Having said this, now I feel that we cannot connect 2 devices (streaming device like apple tv and tasmota) on the same port, if we want to use I2C.

[sfromis]

What do you mean by that? I2C is designed for devices to coexist on the same bus, as long as all parties behave properly. Not sure how well it would work with more than one device acting as master.

[s-hadinger]

I2C and CEC are very similar electrically. There is no problem in having 2 I2C bus masters on the same line. HDMI supports it.

If you want a small form factor, this one looks nice (ESP32C3)
https://fr.aliexpress.com/item/1005005780020590.html

[anishsane]

When I connect the ESP8266 and a display source (RPi or Amazon Firestick) on the same HDMI port of the (LG) TV, the picture keeps blinking.
Probably my TV does not like 2 CEC capable devices connected to the same HDMI port.
That's unfortunate.
It could be LGTV-specific.

[s-hadinger]

Hi, I have now a version that is interrupt-ready. It uses a small ring buffer to pass messages from the Interrupt Driver to the Tasmota code. Let me now try with Timer interrupts.

[anishsane]

Oh, I thought we would use the CEC pin going low/high as edge triggered interrupt (similar to IRrecv in IRremoteESP8266).

[s-hadinger]

I have good news. Actually all the work I did for interrupt was a dead-end. I backtracked to a much simpler version.

Now there's only a simple interrupt to detect the first falling edge. Then during Receive and Transmit, I force the equivalent of Sleep 0 and come back to normal behavior when there is no CEC traffic. This means much simpler code and no IRAM impact.

A first version should be available shortly.

[s-hadinger]

Gosh... It's way harder than I anticipated. I opened a huge can of worms.

It appears that relying on fast event loop is very unreliable. For example, when I sent a request, while Tasmota logs the command details to the console, it already misses the beginning of the answer.

I need to get back to Receive being purely driven by interrupts, and Transmit being in a blocking loop. This is basically the way TasmotaSerial does in software. It creates some short pauses during Transmit, but those are rare events anyways.

[s-hadinger]

Good news, I have made big progress. I'm about to release a first low-level working version this week-end.

[s-hadinger]

HDMI CEC is not available in the development branch. It is tested on ESP8266 and is very reliable.

Documentation: https://tasmota.github.io/docs/HDMI_CEC/

[s-hadinger]

I just cut the IRAM consumption by half. I mistakenly put the Transmit code to IRAM which was not necessary. It is now 1453 bytes.

[sduponch]

Hi, with my ESP32 S2 Mini it seems that the ISR interupt is not triggered when my TV send something on the bus, but i can send some HDMI commands like 36 or 04 that turn off and on my TV.

Here you can find a capture of what my TV is sending, but i have no log in tasmota console. i tried to add some debug in the code but it seems that the ISR is triggered only One time at start while the ESP32 is transmitting on the bus (5ms/div).

00:00:00.001-136/18 HDW: ESP32-S2FNR2 v0.0 (PSRAM)
00:00:00.015-134/17 UFS: FlashFS mounted with 304 kB free
00:00:00.026 CFG: Loaded from File, Count 153
00:00:00.032 QPC: Count 1
00:00:00.033 CFG: CR 418/699, Busy 0
00:00:00.038 I2C: Bus1 using GPIO39(SCL) and GPIO40(SDA)
00:00:00.042 TFS: File 'mcp23x.dat' not found
00:00:00.043 MCP: Invalid template
00:00:00.043 TYA: Active=0
00:00:00.056 ROT: Mode 1
00:00:00.068 BRY: GC from 3692 to 3492 bytes, objects freed 4/20 (in 1 ms) - slots from 36/61 to 28/61
00:00:00.102 CFG: No '*.autoconf' file found
00:00:00.109 BRY: GC from 5852 to 4446 bytes, objects freed 6/40 (in 0 ms) - slots from 64/91 to 41/91
00:00:00.109 BRY: Berry initialized, RAM used 4446 bytes
00:00:00.119 BRY: No 'preinit.be'
00:00:00.121 SRC: Restart
00:00:00.125 Project tasmota - Tasmota Version 13.3.0.1(tasmota32)-2_0_14(2023-12-25T18:28:50)
00:00:00.127 CEC: trying to read physical address
00:00:00.152 CEC: successfully read EDID 256 bytes, extensions count 1
00:00:00.153 CEC: EDID: 00FFFFFFFFFFFF004D10FD0F00000000FF11010380522E782A1BBEA25534B326144A52AFCE00A940D1C0904081800101010101010101023A80D072382D40102C458034CC3100001A662150B051001B304070360000000000001E000000FC0053484152502048444D490A2020000000FD00314C0F4B11000A20202020202001BE02032E72509F9020140513041203110216071506012309070183010000E30503016C030C0010008022C011111919023A801871382D40582C450034CC3100001E011D80D0721C1620102C258034CC3100009E011D8018711C1620582C250034CC3100009E011D00BC52D01E20B828554034CC3100001E00000000000000000073
00:00:00.153 CEC: physical address found: 0x1000
00:00:00.166 SHT: Sensor did not ACK command
00:00:00.547 BRY: No 'autoexec.be'
00:00:00.595 CEC: Packet sent: 44 NAK
00:00:00.596 CEC: HDMI CEC initialized on GPIO 1, Logical address 4, Physical address 0x1000
00:00:00.739 CEC: Packet sent: 4F84100004 ACK
00:00:00.846 WIF: Checking connection...
00:00:00.846 WIF: Attempting connection...
00:00:01.189 WIF: Connecting to AP1 DSKlub Channel 1 BSSId 8A:2A:A8:C1:87:62 in mode 11n as tasmota-59942A-5162...
00:00:02.654 WIF: Checking connection...
00:00:02.654 WIF: Attempting connection...
00:00:03.430 WIF: IPv4 10.66.66.109, mask 255.255.255.0, gateway 10.66.66.254
00:00:03.610 WIF: Checking connection...
00:00:03.610 WIF: Connected
00:00:03.864 HTP: Web server active on tasmota-59942A-5162 with IP address 10.66.66.109
00:00:04.107 NTP: Sync time...
00:00:04.199 WIF: DNS resolved '2.pool.ntp.org' (162.159.200.1) in 91 ms
00:00:04.222 RTC: UTC 2023-12-25T18:36:07Z, DST 2023-03-26T02:00:00, STD 2023-10-29T03:00:00
19:36:07.000 RTC: Synced by NTP
19:36:07.630 MQT: Attempting connection...
19:36:07.631 WIF: DNS resolved '192.168.1.160' (192.168.1.160) in 0 ms
19:36:08.858 MQT: Connect failed to 192.168.1.160:1883, rc -2. Retry in 10 sec
19:36:10.124 QPC: Reset
19:36:12.144 APP: Boot Count 105
19:36:12.406 CFG: Saved, Count 154, Bytes 4096
19:36:19.703 MQT: Attempting connection...
19:36:19.704 WIF: DNS resolved '192.168.1.160' (192.168.1.160) in 1 ms
19:36:20.708 MQT: Connect failed to 192.168.1.160:1883, rc -2. Retry in 20 sec
19:36:28.238 WIF: Checking connection...
19:38:35.888 CMD: HDMISend 36
19:38:35.889 SRC: WebConsole from 40.188.252.63
19:38:35.890 CMD: Grp 0, Cmd 'HDMISEND', Idx 1, Len 2, Pld 36, Data '36'
19:38:35.895 RSL: RESULT = {"HdmiSend":"Done"}
19:38:35.987 CEC: Packet sent: 4036 ACK

With HDMISend 36 Successfuly turn off.

[sduponch]

I found out, on ESP32 each times pinMode is called it reset the setted interupt.

bool IRAM_ATTR CEC_Device::setLineState(bool state, bool check)
{
  static bool curstate;
  // Using the following states, we can connect directly the GPIO to CEC pin without any transistor:
  //   - for high, configure as input + pullup, there is also a pull-up in the TV
  //   - for low, configure as output and drive low
  if(curstate != state) {
    if (state) {
      pinMode(_gpio, INPUT_PULLUP);
      delayMicroseconds(CEC_MAX_RISE_TIME);     // wait for the line to fall
    } else {
      digitalWrite(_gpio, LOW);
      pinMode(_gpio, OUTPUT);
      delayMicroseconds(CEC_MAX_FALL_TIME);     // wait for the line to fall
    }
    enableISR();
  }
  curstate = state;

I am now able to received packets, yay !

21:00:33.164 MQT: Connect failed to 192.168.1.160:1883, rc -2. Retry in 20 sec
21:00:45.275 CEC: Packet received: (0->4) 044401 ACK
21:00:45.429 CEC: Packet received: (0->4) 0445 ACK
21:00:45.534 CEC: Packet received: (4->0) 40004500 ACK
21:00:52.015 CEC: Rx timeout
21:00:52.019 CEC: log (3400 - 4000) actual=1398 code=0x0001 line=1 state=1
21:00:52.020 CEC: log (3400 - 4000) actual=498 code=0x0001 line=1 state=1
21:00:52.022 CEC: log (3400 - 4000) actual=498 code=0x0001 line=1 state=1
21:00:52.026 CEC: log (3400 - 4000) actual=1506 code=0x0001 line=1 state=1
21:00:52.215 CEC: Packet received: (0->4) 0445 ACK
21:00:53.959 MQT: Attempting connection...
21:00:54.964 MQT: Connect failed to 192.168.1.160:1883, rc -2. Retry in 30 sec
21:01:13.252 CEC: Packet received: (0->4) 044430 ACK
21:01:13.380 CEC: Packet received: (0->4) 0445 ACK
21:01:15.262 CEC: Packet received: (0->4) 044431 ACK
21:01:15.588 CEC: Packet received: (0->4) 0445 ACK
21:01:17.946 CEC: Packet received: (0->4) 044431 ACK
21:01:18.098 CEC: Packet received: (0->4) 0445 ACK

i found this :
espressif/arduino-esp32#6695

[s-hadinger]

As said in the documentation, ESP32 was not tested. This is awesome news. Can you please make a PR ?

[sduponch]

Yes :)