remote_transmitter: transmit_nec --> value must be at most 65535

moonraker46 commented 2 years ago

The problem

I do migrate my ESP devices step by step from Tasmota to ESPHome.

One device has an IRsender to send commands to a cheap lampion fairy light https://www.amazon.de/gp/product/B07SBZPKW9/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

This worked so far with Tasmota (I got those IR Codes with an IR Receiver and the official remote).

But using the same commands with ESPHome leads to the issue that ESPHome tells me when compiling the config: value must be at most 65535.

I guess this is because the ESPHome NEC IR command wants to use a 16Bit command but I do have a 32bit command.

How can this be fixed?

remote_transmitter:
  pin: 16
  carrier_duty_percent: 50%

switch:
  - platform: template
    name: "mode5"
    turn_on_action:
      remote_transmitter.transmit_nec:
        address: 0x2FD09F6
        command: 0x40BF906F

INFO Reading configuration /config/lichterkette.yaml...
Failed config

switch.template: [source /config/lichterkette.yaml:68]
  platform: template
name: mode5

  value must be at most 65535.
  turn_on_action: 
    remote_transmitter.transmit_nec: 

      value must be at most 65535.
      address: 50137590
      command: 1086296175

Which version of ESPHome has the issue?

2022.4.0

What type of installation are you using?

Docker

Which version of Home Assistant has the issue?

No response

What platform are you using?

ESP8266

Board

esp8285

Component causing the issue

remote__transmitter

Example YAML snippet

remote_transmitter:
  pin: 16
  carrier_duty_percent: 50%

switch:
  - platform: template
    name: "mode5"
    turn_on_action:
      remote_transmitter.transmit_nec:
        address: 0x2FD09F6
        command: 0x40BF906F

Anything in the logs that might be useful for us?

No response

Additional information

No response

ngilles commented 2 years ago

There then was the "extended" NEC format which basically made addresses 16 bit, the messages still being 32-bit long though: | 16-bit addr | cmd | cmd inverse |.

The current ESPHome code does allow for a bit of freedom int actual values, but still respects that 32 bit message format (hence the 16-bitness for address and command.

I myself have run into an issue with a device (standing fan) that looks like it's using NEC protocol, but it actually repeats the cmd + cmd inverse parts for a total 48bits message. I'm working on PR to solve this, but your specific device seems to be even wilder.

It looks like there are a bunch of devices that are using the NEC timings/signaling, but with their own message format/length, maybe what is needed is the implementation of a "nec_generic" protocol or something, which just handles bytes (that would still exclude protocols with arbitrary bit-lengths that aren't a multiple of 8).

moonraker46 commented 2 years ago

@ngilles I guess you are right. Seems to be a extended NEC IR protocol.

Anyway..using this specific Arduino Sketch I was able to send the extended IR NEC Codes to the receiver successfully. I just had to use the decimal of the IR Command (0x40BF6897 --> 1086285975) and it worked like a charm.

https://github.com/crankyoldgit/IRremoteESP8266/blob/master/examples/IRServer/IRServer.ino

Is there a way to intergrate this extended NEC protocol into ESPHome? If not how could I use this sketch as a custom code in a ESPHome image?

Emrvb commented 1 year ago

@moonraker46 I think you've got something confused from your receiver dumps. To me it looks like 0x40BF906F is a raw Extended NEC dump with address 0x40BF and command 0x906F. You could give that a try with esphome.

Edit:

Fixed the address and command. If the above patch gets merged it will become command 0x6F.

Also, the address you used in your report, 0x2FD09F6 looks like a raw dump as well. Address: 0x02FD, command: 0x09F6. That would be 0xF6 after the patch.

Edit2:

I'm so rusty... fixed the commands...

esphome / issues