Unable to build in 2025.11, using remote_transmitter.transmit_raw. Error: could not convert 'keycode' from 'const esphome::FixedVector<int>' to 'std::vector<int>'

ESPHome
1

I’ve got ESPHome on several IR bridges in different areas of the house, and some of my remote-controlled devices physically move around between the areas.

For a while I’ve been successfully running with yaml that exposes a service on each IR Bridge, allowing for Home Assistant to pass a single variable containing the IR code list to any of the bridges. Upon receipt of the code from Home Assistant (typically via front-end button), the bridge will then perform the transmit_raw action and transmit the code to the remote-controlled device. This configuration allows me to physically move the remote-controlled devices around and/or add new remote codes without having to recompile ESPHome on each device every time.

Here’s the original post that I found when looking to implement this configuration: Request: will any user successfully using ESPhome as a remote IR transmitter please post their yaml - #61 by Rikels

This is my currently-working code (able to build this as-is up through ESPHome 2025.10.5):

api:
  services:
    - action: send_ir
      variables:
        keycode: int[]
      then:
      - remote_transmitter.transmit_raw:
          code: !lambda 'return keycode;'
          carrier_frequency: 38kHz

The issue I’m having is that all bridges are currently stuck on ESPHome 2025.10.5 due to the fact that the following error message appears whenever I try to build for any 2025.11+ versions:

error: could not convert 'keycode' from 'const esphome::FixedVector<int>' to 'std::vector<int>'

I’m not certain whether this is a new bug, or something has changed in the way that the variable placeholders are handled - I understand that the 2025.11 ESPHome update brought about many changes so it would not surprise me if some additional configuration or data type manipulation would be required to be able to build again. I looked up the error message and also made a handful of attempts at trying to change data types, but have not yet found a solution that allows me to successfully compile in ESPHome 2025.11+.

If you’ve got any insight on this error and/or you are able to test locally to recreate the compile issue, please feel free to reach out directly or reply to this post.

Thanks,
Chris

2

I’d call that a bug. ESPHome should handle the conversion, especially if it did last time. Meanwhile - you could convert yourself:

    - action: send_ir
      variables:
        keycode: int[]
      then:
        - remote_transmitter.transmit_raw:
            code: !lambda |-
              std::vector<long int> sv_keycode;
              for (int i = 0; i < keycode.size(); ++i) {
                sv_keycode.push_back(keycode[i]);
              }
              return sv_keycode;
            carrier_frequency: 38kHz
2 Likes
3

I’ll give this a go at next opportunity and post an edit with the results. Much appreciated!

-Chris

EDIT 29 NOV:

This didn’t quite work as-is, but I was able to change std::vector<long int> to std::vector<int> which allowed me to compile.

I’m unable to test in person at the moment, which is required for confirmation on any of my remote-controlled devices. While I may opt for the second potential solution in interest of smaller footprint, I’ll still run this live and share the testing results.

4

This will do it:

1 Like
5

This change also allows for compile without errors. I’ll do some further testing when I can next monitor/confirm device status in person.

I’m curious as to what changed in ESPHome such that we now need to manually iterate… seems to be a loss of functionality from previous versions.

Thanks very much for sharing this workaround!

6

Ah - so instead of trying to match types by copying, just read out the vector as the transmit_raw data. Much smarter…

7

I’m looking forward to testing both approaches in-person and posting back with results. Without knowing exactly why this configuration now requires our manual intervention in 2025.11+, I think there’s possibility for more surprises. Plus if a future update caused a break in begin() or end() it would be nice to have another known-working method documented.

8

The reason for the failure is that parts of ESPHome code were converted from using std::vector to a custom class FixedVector which offers savings in RAM and flash. The api component has been converted, remote_transmitter evidently not.

The underlying data is the same, just wrapped in an incompatible class, so the fix I showed just creates a std::vector from the data.

The ultimate solution is 1) to provide a class method that automatically converts between the types, and likely 2) convert the remote_transmitter to accept FixedVector. The first one is essentially done, and might be in the next point release. The second will take longer.

1 Like
9

Fantastic explanation, I now have a much better understanding of the change in behavior and the reason that the workarounds are so effective.

The improvements that FixedVector and the like bring to ESPHome are especially noticeable to me when it’s time for updates… ~40 total nodes, so I appreciate every bit of savings there. RAM/Flash size was a consideration that led me to call the API rather than store IR codes on the ESPHome devices.

Thanks for taking the time to educate on these changes, and for linking your PR.

10

Borne of sad experience, I always click the change log url and read very carefully, especially the breaking changes section, pause to contemplate if it will affect my setup, before I press the update button.

11

This is great advice for any release, and especially one as large as this! I unfortunately did not spot the change that was affecting my bridges during review, both before and after compilation had failed. I’ve got a much better grasp on it now and I’m confident that I’d spot this type of breaking change in the future if/when the ESPHome team implements additional custom classes to improve efficiency. If anyone else is curious about the begin() and end() methods in the workaround posted by clydebarrow, I found this link helpful: Vector begin() in C++ STL - GeeksforGeeks

ESPHome supports such a wide selection of sensors and configurations, and I’m learning a little more with each release and each new device that I set up. So far I’ve not seen any devices end up in an unusable condition by way of updates… it’s not a huge deal to me if some of my devices might just need to hang back on an older version for a couple patch releases while I figure out how to correct their configuration.

12

Cutting edge, not bleeding edge! :wink:

13

Solution marked, and I also confirmed that both approaches will work without issues.

Thanks,
Chris