Support full (>460 char) dumps of Pronto IR commands

[rpaskowitz]

What does this implement/fix?

Currently Pronto IR messages get truncated, this allows them to be fully logged

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Other

Related issue or feature (if applicable): esphome/issues#3557 (comment)

Test Environment

• ESP32
• ESP32 IDF
• ESP8266
• RP2040
• BK72xx
• RTL87xx

Checklist:

• The code change is tested and works locally.
• Tests have been added to verify that the new code works (under tests/ folder).

[optimusprimespace]

Can you provide a way to test this? I followed this https://esphome.io/guides/faq.html#how-can-i-test-a-pull-request. I want to test the receiver and the transmitter part of this as well. But i don't know if it's a true external component and can be tested this way or i have to compile it myself. Thanks in advance. 😀

[rpaskowitz]

I set up a full development environment, so I compiled and tested via that. I'm not familiar with external components, but the docs seem to indicate you an override even 'internal' components, so pulling in the remote_base component from my PR aught to work?

I think the yaml would look like:

external_components:
  - source: github://pr#6040
    components: [ remote_base ]

Note that this PR only touches receiving code, and not transmitting. I did however notice when trying to transmit the received commands I still encountered issues. I traced this back to the received command containing one extra tailing set of bits. This caused it to fail the consistency check, resulting in the error Inconsistent data being logged and no command emitted. When I discovered that the length was wrong, I simply took the last set of bits off the received command and tried again, and that worked fine -- it was a guess that it was the final bits out of place.

I have not tracked down whether the remote is actually emitting those bits, or if there is a separate bug causing them to be printed. If they are actually emitted, then there may be a different bug in the consistency check, or the remote itself is emitting invalid (but functional commands).

I may update the 'Inconsistent data' error to provide more detail about in what way the command is failing the check. In any event, I wouldn't have reached that stage without first getting the untruncated command printed, as the commands were quite lengthy.