ESPHome upgrade NEC remote stopped working

Dear community, after many happy years of reading posts which have helped me solve problems, this time I’m stuck, and hoping someone can help:

I have two H802 RGBW LED controller devices, with identical code and hardware setup: H801/H802 RGBW LED controller | ESPHome Devices

Both have an IR receiver setup, and identical ESPHOME code, and have worked flawlessly for the past 1+year.

Since upgrading ESPHOME recently on 1 of them the device can no longer see NEC remote codes, and I can’t use the remote control any longer. The device can log all kinds of raw codes when setting dump to all, but no longer NEC. Same remote gives NEC codes on the sibling un-upgraded device.

(Edit)
Working device: ESPHome version 2025.11.0 compiled on Nov 23 2025
Failing Device: ESPHome version 2026.1.2 compiled on 2026-01-26

Can anyone shed any light on a backwards incompatibility that I missed, or any other help, or has anyone got anything similar still working?

Thanks a million

esphome:
  name: topfloor-light-west

esp8266:
  board: esp01_1m

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "****************************"

ota:
  platform: esphome
  password: "****************************"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  min_auth_mode: "WPA2"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Topfloor-Light-West"
    password: "****************************"

captive_portal:

remote_receiver:
  pin:
    number: GPIO2
    inverted: true
    mode:
      input: true
      pullup: true
  dump: all


light:
  - platform: rgbw
    name: topfloor light west
    id: topfloor_light_west
    red: pwm_r
    green: pwm_g
    blue: pwm_b
    white: pwm_w
    color_interlock: true
    restore_mode: ALWAYS_ON
    effects:
      - random:
      - strobe:
      - flicker:
      - pulse:
    on_turn_on: 
      then:
        - light.turn_on:
           id: topfloor_light_west
           brightness: 30%
 


output:
  - platform: esp8266_pwm
    pin: GPIO12
    frequency: 1000 Hz
    id: pwm_g

  - platform: esp8266_pwm
    pin: GPIO14
    frequency: 1000 Hz
    id: pwm_r

  - platform: esp8266_pwm
    pin: GPIO13
    frequency: 1000 Hz
    id: pwm_b

  - platform: esp8266_pwm
    pin: GPIO15
    frequency: 1000 Hz
    id: pwm_w


binary_sensor:
  #Remote Top Row
  - platform: remote_receiver
    id: "on"
    nec:
      address: 0xFF00
      command: 0xF20D
    on_press:
      then:
        - light.turn_on:
            id: topfloor_light_west
            effect: none
            brightness: 30%
    filters:
      - delayed_off: 100ms
    
  - platform: remote_receiver
    id: "off"
    nec:
      address: 0xFF00
      command: 0xE01F
    on_press:
      then:
        - light.turn_off:
            id: topfloor_light_west
    filters:
      - delayed_off: 100ms
  
  - platform: remote_receiver
    id: brightness_up
    nec:
      address: 0xFF00
      command: 0xF609
    on_press:
      then:
        - light.dim_relative:
            id: topfloor_light_west
            relative_brightness: 10%
            
  - platform: remote_receiver
    id: brightness_down
    nec:
      address: 0xFF00
      command: 0xE21D
    on_press:
      then:
        - light.dim_relative:
            id: topfloor_light_west
            relative_brightness: -10%

Post the raw log for your button press.

Same button (off) pressing it twice on the failing device (dump: all)

[20:04:26.321][I][remote.pronto:231]: Received Pronto: data=
[20:04:26.325][I][remote.pronto:239]: 0000 006D 0001 0000 000C 66DB 
[20:04:26.351][I][remote.pronto:231]: Received Pronto: data=
[20:04:26.351][I][remote.pronto:239]: 0000 006D 0001 0000 000E 01E6 
[20:04:26.436][D][remote.beo4:086]: Beo4: n_sym=60
[20:04:26.437][I][remote.pronto:231]: Received Pronto: data=
[20:04:26.437][I][remote.pronto:239]: 0000 006D 001E 0000 0024 0050 0008 001F 000C 001A 0011 0015 0017 0014 0017 0015 0016 0013 0019 004E 0008 0045 0012 003B 001C 0031 0026 004E 0009 0044 0013 003A 001C 0031 0026 004D 000A 0043 0013 003A 001D 0030 0027 004C 000A 001D 
[20:04:26.455][I][remote.pronto:239]: 000F 0017 0014 0015 0016 0013 0019 0014 0017 0051 0006 0020 000B 0042 0015 0038 001F 0657 
[20:04:26.471][I][remote.pronto:231]: Received Pronto: data=
[20:04:26.471][I][remote.pronto:239]: 0000 006D 0001 0000 0015 0192 
[20:04:26.561][I][remote.pronto:231]: Received Pronto: data=
[20:04:26.561][I][remote.pronto:239]: 0000 006D 0001 0000 0021 0E72 
[20:04:26.562][I][remote.pronto:231]: Received Pronto: data=
[20:04:26.573][I][remote.pronto:239]: 0000 006D 0001 0000 0017 0190 
[20:05:04.772][I][remote.pronto:231]: Received Pronto: data=
[20:05:04.772][I][remote.pronto:239]: 0000 006D 0001 0000 0023 606F 
[20:05:04.773][I][remote.pronto:231]: Received Pronto: data=
[20:05:04.777][I][remote.pronto:239]: 0000 006D 0001 0000 000C 01E8 
[20:05:04.798][D][remote.beo4:086]: Beo4: n_sym=66
[20:05:04.798][I][remote.pronto:231]: Received Pronto: data=
[20:05:04.809][I][remote.pronto:239]: 0000 006D 0021 0000 0021 0015 0016 0027 0005 0021 000A 001D 000F 0018 0014 0014 0017 0016 0015 0013 0019 0051 0006 0047 000F 003E 0019 0033 0023 0050 0006 0047 0010 003D 001A 0033 0023 0050 0007 0046 0010 003C 001A 0033 0024 004F 
[20:05:04.933][I][remote.pronto:239]: 0007 001F 000D 001A 0011 0015 0016 0013 0019 0014 0017 0015 0016 0028 0004 0023 0008 0045 0012 003A 001C 0031 0025 0603 
[20:05:04.937][I][remote.pronto:231]: Received Pronto: data=
[20:05:04.937][I][remote.pronto:239]: 0000 006D 0001 0000 0012 0195 

Same button, twice, on working device (Dump: nec)

[20:06:52.165][D][binary_sensor:041]: 'off': New state is ON
[20:06:52.195][I][remote.nec:097]: Received NEC: address=0xFF00, command=0xE01F command_repeats=1
[20:06:52.272][D][binary_sensor:041]: 'off': New state is OFF
[20:07:00.527][D][light:091]: 'topfloor light east' Setting:
[20:07:00.539][D][light:142]:   Transition length: 1.0s
[20:07:00.540][D][binary_sensor:041]: 'off': New state is ON
[20:07:00.558][I][remote.nec:097]: Received NEC: address=0xFF00, command=0xE01F command_repeats=1
[20:07:00.633][D][binary_sensor:041]: 'off': New state is OFF

Thats not raw, it’s pronto…

So dump: nec doesn’t output anything? Try to adjust the tolerance, like 50%.
If you still don’t get anything, use dump: raw and post what you got.

Yep that was Dump: All … it had pronto and Beo4…

Here is Dump: Raw… same button (off) pressed twice:

[21:05:15.695][C][mdns:177]:   Hostname: topfloor-light-west
[21:05:38.084][I][remote.raw:041]: Received Raw: -668
[21:05:38.222][I][remote.raw:028]: Received Raw: -230, 770, -364, 636, -500, 549, -567, 572, -563, 514, -626, 544, -571, 994, -137, 863, -274, 1726, -517, 1483, -766, 4234, -276, 1724, -523, 1477, -791, 4209, -285, 1715, -546, 1454, -792, 4207, -309, 1691, -551, 516, -623, 548, -568, 569, 
[21:05:38.222][I][remote.raw:041]:   -563, 1062, -79, 921, -190, 810, -324, 676, -462, 548, -568, 1422, -842, 2158, -88, 1912, -336
[21:05:38.222][I][remote.raw:041]: Received Raw: -810
[21:05:49.948][I][remote.raw:041]: Received Raw: -129
[21:05:49.949][I][remote.raw:041]: Received Raw: -712
[21:05:49.949][I][remote.raw:028]: Received Raw: -276, 724, -411, 589, -547, 550, -566, 573, -561, 514, -623, 2066, -183, 817, -319, 1681, -563, 1437, -812, 2192, -75, 1922, -322, 1677, -570, 1430, -838, 2162, -82, 1918, -329, 1671, -597, 1403, -840, 2159, -90, 1910, -356, 1644, -598, 
[21:05:49.961][I][remote.raw:041]:   516, -624, 547, -568, 597, -536, 1014, -123, 877, -239, 761, -372, 628, -510, 548, -565, 1377, -890, 2110, -134, 1866, -382
[21:05:50.512][I][remote.raw:041]: Received Raw: -856

I’ll add tolerance to 50% and put it to nec/all/raw and see if anything… and post back shortly. Note: the identical working device does not have tolerance set.

edit: Setting Tolerance to 50% makes no difference to behavour/outputs.

Just tried using the raw codes from this config, because this is the identical remote I’m using with the H802 device: MagicHome RGBW ZJ-WFMN-A V1.1 LED Controller | ESPHome Devices

Unfortunately to no avail.

What gets me with the dump:raw, and the dump:all, is that the same button on the remote never gives consistent output.

But back to the original problem: Why can’t ESPHOME give me NEC any longer. I’ve just tried upgrading a similar device (a ‘magichome’ device as per the link above) and same behaviour. Got NEC output before, and now upgraded, no NEC codes. :frowning:

It might be related to the ESP8266 efficiencies that have been introduced in ESPHome 2026.1. There is also a new IR related component. ESPHome 2026.1.0 - January 2026 - ESPHome - Smart Home Made Simple

I have just updated an ESP32 with IR receiver component to ESPHome 2026.1.2 and I am still seeing NEC codes.

16:37:30.180][D][remote.beo4:086]: Beo4: n_sym=68
[16:37:30.181][I][remote.jvc:049]: Received JVC: data=0x5EA1
[16:37:30.181][I][remote.lg:054]: Received LG: data=0x5EA1F807, nbits=32
[16:37:30.182][I][remote.nec:097]: Received NEC: address=0x857A, command=0xE01F command_repeats=1
[16:37:30.182][I][remote.pioneer:149]: Received Pioneer: rc_code_X=0x5E1F
[16:37:30.182][I][remote.pronto:231]: Received Pronto: data=
[16:37:30.186][I][remote.pronto:239]: 0000 006D 0022 0000 0159 00AC 0016 0015 0017 0040 0015 0015 0016 0040 0016 0040 0017 003F 0016 0040 0016 0015 0017 0040 0015 0015 0016 0040 0015 0015 0016 0015 0017 0015 0016 0015 0016 0040 0015 0040 0017 003F 0016 0040 0016 0040 
[16:37:30.200][I][remote.pronto:239]: 0016 003F 0016 0015 0017 0015 0016 0015 0016 0015 0017 0015 0016 0015 0016 0015 0017 0015 0016 0040 0016 0040 0016 0040 0016 0181 
[16:37:30.225][I][remote.pronto:231]: Received Pronto: data=
[16:37:30.245][I][remote.pronto:239]: 0000 006D 0002 0000 0159 0056 0016 0181 

Edit: additional info, a link, and version detail

1 Like

Best idea is probably to roll back to a working version, confirm that fixes the issue, then log a ticket on GitHib.

1 Like

The signal looks quite bad and theres no NEC header present at all…
Are you 100% sure your receiver needs
inverted: true
??

Iamjosh- Thanks for checking ESP32 - good news that’s looking okay. And thanks for pointing out all the 8266 changes, makes interesting reading

Zoogara - good call on rollback and retest. Over the next week I’ll figure out how to install a separate ESPhome install somewhere (probably my Ubuntu box) and roll that device back until it starts working again.

Karosm - thanks for checking the raw code, quite impressive- I had no idea that was even a possibility. I’m not convinced that an ESPhome update needs me to change the inversion when it was working before, and when a number of other older ESPhome version (8266) devices still work… I’ll be proved wrong though, so I will check!

Neither am I.
But that signal you posted would not be valid NEC for any version of esphome so something else is going on…
Nec signal would look like 9000, -4500, 560, -560, 560, -1120, 560, -560…
(with certain tolerances of course).

If it wasn’t update issue I would suggest to set
inverted: false
filter: 250us

You can pick whatever version you want.

For me this hints at a possible hardware issue.

I can’t really see how it could be config / software related (but could well be wrong).

I don’t know the power or reciever set-up for these devices but I have found in the past that some of my ir recievers were touchy about power supply and wiring/soldering.

So I would double check all relevant connections and maybe try swapping power supplies (if that is relevant).

And maybe put a fresh battery in your remote?

1 Like

Thanks for the thinking on this Mahko_Mahko. 2x setups, Identical harware, identical power supply, and using the same remote control to test both setups: one works (pre-update), and one doesn’t (post-update). I’ve gone down the ESPHome Version avenue… update to follow

EDIT: Both setups working fine for +1yr, until I upgraded 1 of them. Both setups hardwired into separate rooms.

Brilliant, appreciated, that made it easy to roll-back ESPHome for the device in question. Thanks so much for sharing

Okay; team of helpful people, thanks so much for sharing your time with me; Karosm, Mahko_Mahko, zoogara, Brooksben11, iamjosh

UPDATE: Rolling back to ESPHome version 2025.11.5 brought NEC remote back to life.

Additional note, using “dump:all”, it seems to have also brought back to life JVC, LG, & Pioneer. :thinking:

[13:42:51.418][D][light:091]: 'topfloor light west' Setting:
[13:42:51.431][D][light:104]:   State: OFF
[13:42:51.432][D][light:142]:   Transition length: 1.0s
[13:42:51.432][D][binary_sensor:049]: 'off': ON
[13:42:51.432][D][remote.beo4:086]: Beo4: n_sym=68
[13:42:51.443][I][remote.jvc:049]: Received JVC: data=0x00FF
[13:42:51.443][I][remote.lg:054]: Received LG: data=0x00FFF807, nbits=32
[13:42:51.444][I][remote.nec:097]: Received NEC: address=0xFF00, command=0xE01F command_repeats=1
[13:42:51.455][I][remote.pioneer:149]: Received Pioneer: rc_code_X=0x001F
[13:42:51.455][I][remote.pronto:229]: Received Pronto: data=
[13:42:51.477][I][remote.pronto:237]: 0000 006D 0022 0000 015B 00AF 0014 0018 0014 0017 0013 0019 0014 0017 0015 0017 0013 0019 0017 0014 0014 0017 0014 0043 0015 0042 0014 0042 0013 0043 0015 0042 0014 0042 0013 0044 0015 0042 0014 0042 0013 0044 0015 0042 0016 0041 
[13:42:51.522][I][remote.pronto:237]: 0013 0043 0015 0017 0013 0019 0014 0017 0015 0018 0014 0017 0014 0018 0014 0018 0012 0019 0014 0042 0013 0043 0014 0043 0014 0181 
[13:42:51.522][I][remote.pronto:229]: Received Pronto: data=
[13:42:51.523][I][remote.pronto:237]: 0000 006D 0002 0000 015B 0058 0015 0181 
[13:42:51.531][D][binary_sensor:049]: 'off': OFF

I will try and raise a GitHub issue, and see where that takes me… unless anyone suggests an alternative course of action, I’m still not ruling out user error in my configuration. Often the problem can be between keyboard and chair :slightly_smiling_face:

Interesting.
Can you post the receiver code and RAW dump

Yea, sure thing Karosm. Same button on the remote as before (“Off”), pressed twice.

remote_receiver:
  pin:
    number: GPIO2
    inverted: true
    mode:
      input: true
      pullup: true
  dump: raw
[16:54:36.123][D][light:091]: 'topfloor light west' Setting:
[16:54:36.167][D][light:104]:   State: OFF
[16:54:36.168][D][light:142]:   Transition length: 1.0s
[16:54:36.168][D][binary_sensor:049]: 'off': ON
[16:54:36.168][I][remote.raw:028]: Received Raw: 9056, -4511, 552, -563, 572, -563, 511, -624, 552, -562, 575, -588, 485, -652, 550, -560, 551, -561, 514, -1732, 575, -1691, 552, -1692, 547, -1708, 593, -1668, 552, -1692, 516, -1734, 574, -1691, 580, -1664, 516, -1731, 577, -1692, 548, 
[16:54:36.168][I][remote.raw:041]:   -1694, 517, -1733, 578, -556, 515, -621, 578, -561, 581, -559, 486, -657, 518, -564, 575, -558, 516, -622, 553, -1690, 516, -1733, 574, -1691, 552
[16:54:36.169][W][component:454]: remote_receiver took a long time for an operation (53 ms)
[16:54:36.212][W][component:457]: Components should block for at most 30 ms
[16:54:36.213][I][remote.raw:041]: Received Raw: 9075, -2227, 578
[16:54:36.213][D][binary_sensor:049]: 'off': OFF
[16:54:52.275][D][light:091]: 'topfloor light west' Setting:
[16:54:52.287][D][light:142]:   Transition length: 1.0s
[16:54:52.288][D][binary_sensor:049]: 'off': ON
[16:54:52.299][I][remote.raw:028]: Received Raw: 9054, -4513, 549, -592, 548, -590, 464, -673, 522, -590, 549, -589, 464, -674, 522, -588, 548, -590, 465, -1779, 549, -1723, 522, -1724, 464, -1778, 550, -1721, 521, -1725, 465, -1778, 554, -1718, 521, -1725, 464, -1780, 549, -1721, 523, 
[16:54:52.309][I][remote.raw:041]:   -1722, 465, -1779, 550, -589, 464, -673, 520, -591, 548, -590, 486, -656, 516, -590, 548, -591, 464, -673, 520, -1726, 463, -1779, 551, -1720, 521
[16:54:52.315][I][remote.raw:041]: Received Raw: 9044, -2277, 550
[16:54:52.378][D][binary_sensor:049]: 'off': OFF

That’s clean solid signal with valid NEC headers (9000,-4500).
I’m really wondering what’s going on…
It’s not decoding issue. It’s signal receiving issue.
And what is weird is that your previous bad quality signal was actually inverted from this, starting with negative and all spaces as positive.

1 Like

Ah right I missed they were on different firmware. So yeah, this would lead me to suspect software related issue.