HDMI CEC - send multiple commands with precision delay

[jpmorrison]

I'm playing with HDMI CEC remote control/UI commands.

To send a remote control, you send the UI command for button down, then send a command for button released.
When I try this with HDMISendRaw, it works but the the timing is a bit tricky. Sending volume up might increase it by 2,3 or whatever.
I thought it would be handy to add this.

Another timing issue it might help with: HDMISendRaw doesn't seem to work with Backlog - if the TV wakes up the receiver doesn't wake up. It needs some delay before I can power on the receiver.

I took a shot at adding the command. I don't know the correct way to do they delay part yet. BTW the Gitpod instructions helped me get started, I've been putting this off for too long.

I added a command HDMISendRawN for testing. It simply extends HDMISendRaw.
Debugs show the parsing but it only sends the first. Maybe the delay will help.

For testing I tried:
HdmiSendRawN 4004,1000,45446D
4004 TV image view on - should wake up
1000 ms delay, placeholder for now
45446D - send power on remote control button to receiver.

void CmndHDMISendRawN(void) {
  if (HDMI_CEC_device) {
    char *tok, *p;
    int delay, send=0;

    RemoveSpace(XdrvMailbox.data);
    p = XdrvMailbox.data;
    while (tok = strtok(p,",")) {
      AddLog(LOG_LEVEL_DEBUG, PSTR("CEC: HDMI CEC SendRawN arg %s"), tok );
      p = 0;
      if (++send & 1) {
        AddLog(LOG_LEVEL_DEBUG, PSTR("CEC: HDMI CEC SendRawN sending %s"), tok );
        SBuffer buf = SBuffer::SBufferFromHex(tok, strlen(tok));
        if (buf.len() > 0 && buf.len() < 16) {
          HDMI_CEC_device->transmitRaw(buf.buf(), buf.len());
        // ResponseCmndDone();
        } else {
          ResponseCmndChar_P(PSTR("Buffer too large"));
        }
      } else {
        delay = 0;
        sscanf(tok,"%d",&delay);
        AddLog(LOG_LEVEL_DEBUG, PSTR("CEC: HDMI CEC SendRawN delay %d"), delay );
        //  TODO delay between send
      }
    }
    ResponseCmndDone();
  } else {
    ResponseCmndError();
  }
}

Debugging:

17:12:47.151 CMD: HdmiSendRawN 4004,1000,45446D
17:12:47.157 CMD: Grp 0, Cmd 'HDMISENDRAWN', Idx 1, Len 16, Pld 4004, Data '4004,1000,45446D'
17:12:47.161 CEC: HDMI CEC SendRawN arg 4004
17:12:47.163 CEC: HDMI CEC SendRawN sending 4004
17:12:47.165 CEC: HDMI CEC SendRawN arg 1000
17:12:47.167 CEC: HDMI CEC SendRawN delay 1000
17:12:47.168 CEC: HDMI CEC SendRawN arg 45446D
17:12:47.170 CEC: HDMI CEC SendRawN sending 45446D
17:12:47.175 MQT: stat/tasmota_065E9D/RESULT = {"HdmiSendRawN":"Done"}
17:12:47.349 CEC: Packet sent: 4004 ACK
17:12:47.971 CEC: Packet received: (5->0) 50 ACK
17:12:48.871 CEC: Packet received: (0->F) 0F8700E091 ACK
17:12:48.876 MQT: tele/tasmota_065E9D/SENSOR = {"HdmiReceived":{"From":0,"To":15,"Data":"8700E091"}}
17:12:50.474 CEC: Packet received: (B->B) BB NAK
17:12:50.511 CEC: Packet received: (B->B) BB NAK
17:12:50.599 CEC: Packet received: (0->F) 0F9000 ACK
17:12:50.604 MQT: tele/tasmota_065E9D/SENSOR = {"HdmiReceived":{"From":0,"To":15,"Data":"9000"}}
17:12:50.638 CEC: Packet received: (B->B) BB NAK
17:12:50.674 CEC: Packet received: (B->B) BB NAK
17:12:50.740 CEC: Packet received: (0->5) 057D ACK
17:12:50.779 CEC: Packet received: (B->B) BB NAK
17:12:50.814 CEC: Packet received: (B->B) BB NAK
17:12:50.884 CEC: Rx timeout

[s-hadinger]

This is not the right approach. Using delay() blocks the entire Tasmota and prevents any other function to work. I know it's much harder but such approach should be done in an asynchronous way, checking every_50ms if there is something more to be done.

If your device is based on ESP32, it would be much easier to use Berry scripts

[jpmorrison]

@s-hadinger there might be a problem with aa42010 (though it could be my backport)

I could not web upload new firmware - the connection would reset and restart reason showed Exception.
I unplugged from the HDMI port and I can web upgrade new firmware successfully.

[s-hadinger]

Problem of firmware is not correlated from HDMI. You must have a hardware issue, lack of power?

I have pushed the latest fix: #21287

[jpmorrison]

It looks like I can send back to back successfully now., though I don't always see the second command ACked.
I probably misunderstood your isTransmitting() snippet.

The receiver volume still changes by 2-4 points, and there might be an extra 150 ms delay. Maybe it's working and it's just the receiver. I should put a logical analyzer on it.

First command sent 154442 (s=1 dest=5)
376-288 = 88 ms = (30 bits message + 7 bits transmit delay) * 2.4 ms = 88.8 ms

19:32:10.288 CEC: HDMI CEC transmitRaw successful
...
19:32:10.376 CEC: Packet sent: 154442 ACK

Next opcode 45=button release
381-376= 5 start bit 4.5 ms?

19:32:10.376 CEC: Packet sent: 154442 ACK
19:32:10.378 CEC: HDMI CEC SendRawN arg 1545
19:32:10.379 CEC: HDMI CEC SendRawN sending 1545
19:32:10.381 CEC: HDMI CEC transmitRaw successful

582-381 = 201 ms message 20 bits = 48 ms. maybe 53 ms with start bit?

19:32:10.381 CEC: HDMI CEC transmitRaw successful
19:32:10.388 MQT: stat/tasmota_065E9D/RESULT = {"HdmiSendRawN":"Done"}
19:32:10.582 CEC: Packet sent: 1545 ACK

Unedited log.

19:32:10.274 CMD: hdmisendrawn 154442,0,1545
19:32:10.280 CMD: Grp 0, Cmd 'HDMISENDRAWN', Idx 1, Len 13, Pld 154442, Data '154442,0,1545'
19:32:10.284 CEC: HDMI CEC SendRawN arg 154442
19:32:10.286 CEC: HDMI CEC SendRawN sending 154442
19:32:10.288 CEC: HDMI CEC transmitRaw successful
19:32:10.290 CEC: HDMI CEC SendRawN arg 0
19:32:10.292 CEC: HDMI CEC SendRawN asked for delay 0 getting 0
19:32:10.376 CEC: Packet sent: 154442 ACK
19:32:10.378 CEC: HDMI CEC SendRawN arg 1545
19:32:10.379 CEC: HDMI CEC SendRawN sending 1545
19:32:10.381 CEC: HDMI CEC transmitRaw successful
19:32:10.388 MQT: stat/tasmota_065E9D/RESULT = {"HdmiSendRawN":"Done"}
19:32:10.582 CEC: Packet sent: 1545 ACK

Code. I've tried delay(1) and delay(0) in the isTransmitting() loop, and also HdmiSendRawN xxxx,0,xxxx,0

void CmndHDMISendRawN(void) {
  if (HDMI_CEC_device) {
    char *tok, *p;
    int del, send=0;
    
    RemoveSpace(XdrvMailbox.data);
    p = XdrvMailbox.data;
    while (tok = strtok(p,",")) {
      AddLog(LOG_LEVEL_DEBUG, PSTR("CEC: HDMI CEC SendRawN arg %s"), tok );
      p = 0;
      if (++send & 1) {
        AddLog(LOG_LEVEL_DEBUG, PSTR("CEC: HDMI CEC SendRawN sending %s"), tok );
        SBuffer buf = SBuffer::SBufferFromHex(tok, strlen(tok));
        if (buf.len() > 0 && buf.len() < 16) {
          bool success = HDMI_CEC_device->transmitRaw(buf.buf(), buf.len());
          if(success) {
            HDMI_CEC_device->run();
            AddLog(LOG_LEVEL_DEBUG, PSTR("CEC: HDMI CEC transmitRaw successful"));
          }
          else {
            AddLog(LOG_LEVEL_DEBUG, PSTR("CEC: HDMI CEC transmitRaw failed?"));
            ResponseCmndChar_P(PSTR("Sending failed"));
          }
        // ResponseCmndDone();
        } else {
          ResponseCmndChar_P(PSTR("Buffer too large"));
        }
      } else {
        del = 0;
        sscanf(tok,"%d",&del);
        // todo: #define a safe ms delay, using 100 ms max for now
        AddLog(LOG_LEVEL_DEBUG, PSTR("CEC: HDMI CEC SendRawN asked for delay %d getting %d"), del, (del>100)? del=100:del);
        uint8_t t = millis() + del;
        while(HDMI_CEC_device->isTransmitting()) {
          HDMI_CEC_device->run();
          while (!TimeReached(t))
            delay(1);  // wait until next ms
        }
      }
    }

    ResponseCmndDone();
  } else {
    ResponseCmndError();
  }
}

[jpmorrison]

Sorry, I missed your comment and changes in #21287

This is progress! Backlog HdmiSend {"To":5, "Data":"4441" }; HdmiSend{"To":5, "Data":"45" }

Will usually change volume by exactly one unit. Sometimes nothing happens, other times it still goes up by 2 or 3.

#21287 changes HdmiSend JSON but Hex isn't changed

[jpmorrison]

I noticed CEC key pressed/release commands are more reliable when the TV is in standby.
When the TV is on, it does more polling - sending a ping to each address. to see what addresses are used.
When the TV is in standby, there's less chatter, but playback devices poll for TV power status, and the TV broadcasts its vendor ID.

With the TV in standby, this works pretty more to change volume by one point. If I repeat the command a few times, it starts changing by two or three points. I've noticed some Rx timeouts and NAKs from the receiver. The NAK could be CEC flow control.
Since the other fixes I noticed the volume control report from the AVR to the TV. This is an optional CEC response to volume control.
 
Backlog HdmiSend {"To":5,"Data":"4441"};HdmiSend {"To":5,"Data":45"}

19:53:52.578 CEC: Packet received: (5->0) 507A24 ACK

NAK

18:06:41.426 CMD: Backlog HdmiSend {"To":5,"Data":"4442"};HdmiSend {"To":5,"Data":45"}
18:06:41.432 CMD: Grp 0, Cmd 'BACKLOG', Idx 1, Len 60, Pld -99, Data 'HdmiSend {"To":5,"Data":"4442"};HdmiSend {"To":5,"Data":45"}'
18:06:41.458 SRC: Backlog
18:06:41.462 CMD: Grp 0, Cmd 'HDMISEND', Idx 1, Len 22, Pld -99, Data '{"To":5,"Data":"4442"}'
18:06:41.559 CEC: Packet sent: 154442 ACK
18:06:41.565 MQT: stat/tasmota_065E9D/RESULT = {"HdmiSend":"Done"}
18:06:41.651 CEC: Packet received: (5->0) 507A2F ACK
18:06:41.692 SRC: Backlog
18:06:41.695 CMD: Grp 0, Cmd 'HDMISEND', Idx 1, Len 19, Pld -99, Data '{"To":5,"Data":45"}'
18:06:41.740 CEC: Packet sent: 1545 NAK

Rx timeout

18:06:03.121 MQT: tele/tasmota_065E9D/SENSOR = {"HdmiReceived":{"From":0,"To":15,"Data":"8700E091"}}
18:06:03.192 CEC: Packet received: (8->0) 808F ACK
18:06:03.256 CEC: Packet received: (B->0) B08F ACK
18:06:03.345 CEC: Packet received: (0->B) 0B9001 ACK
18:06:03.379 CEC: Rx timeout
18:06:03.385 CEC: log (3400 - 4000) actual=1503 code=0x0001 line=1 state=1
18:06:03.387 CEC: log (3400 - 4000) actual=603 code=0x0001 line=1 state=1
18:06:03.389 CEC: log (3400 - 4000) actual=603 code=0x0001 line=1 state=1
18:06:03.391 CEC: log (3400 - 4000) actual=1503 code=0x0001 line=1 state=1

[s-hadinger]

Sendraw can spoof addresses and you get a reply but won't see it without debugs turned on.

Why would you need to spoof the address in your context? Asking out of curiosity

[jpmorrison]

I wasn't seeing responses, so it was for testing.

LA=0xF (unregistered) wasn't working with some commands. CEC spec says unregistered has limitations, but it could just be my devices. I do have three playback devices connected, so it's probably why I get 0xF. I can check what other devices do.

But HdmiTtype 1 works and I get LA=1. This is what lib-cec/cec-client uses by default, so it's probably a safe choice.

I was also spoofing between TV/Audio to see if commands only work from the "right" source address.
My goal is to initiate the ARC channel so my TV sends audio back to my non-ARC receiver.

With a bit of ARC negotiation I should get SPDIF on pin 14 and be able to break that out to a co-ax digital input.
This is just simple switching, ESP8266 is too limited to decode SPDIF without extra hardware.

I think a new Hdmi command to monitor all or specific addresses, or opcodes would be useful to report to mqtt.
For example, if you report on ??47xxxxxxxx mqtt could decode Player1=Chromecast etc.
You could just poll for it, but since it's already there it might be nice to just listen.

A more short term goal for me would be to get cec-client talking to Tasmota.

[s-hadinger]

I welcome any addition for pattern filtering when receiving data. As you have seen, it can be verbose if we report every message to MQTT

[jpmorrison]

I looked some more at lib-cec/cec-client - it takes care of CEC complexity in user space or in a kernel driver.
The pulse8 adapter is USB serial, with inputattach -pulse8-cec setting up /dev/cec0

I've been thinking about HDMI CEC tcp/serial bridge to work directly with libcec. I don't know if many people use cec-mqtt-bridge but that could be something to do by supporting those commands.