mitsubishi_cn105 climate component

[nagyrobi]

Component name

mitsubishi_cn105

Link to component documentation on our website

https://next.esphome.io/components/climate/mitsubishi_cn105/

Describe the enhancement

Discussion follow-up from esphome/esphome#14979

Use cases

Apart from Farenheit special mapping which has already a PR, here a couple of more useful thoughts:

• Swing options

• Add just a function to be able to override the A/C unit's internal temp sensor with a value from ESPHome. This is supported through CN105 connection using factory wired thermostat.
  It would be enough to just have a lambda way to update this value, which we could call from an interval. It's very easy because if there's no repeated update through this channel the heapump falls back to its own sensor. There's no need for a full-blown implementation with selcts etc. as this is an advanced topic anyway. Just a note in the doc that there's a lambda to override the internal sensor.
  Use case is very simple: use a BLE temp sensor placed optimally in the room, which could be forwarded to the A/C unit through ESPHome directly. Not even necessarily to involve HA.

• A filter reset button: the units have an internal time counter to clean the filter. It is possible to reset the warning through CN105. An accompanying diagnostic binary_sensor to show if the warning is active.

• A diagnostic text_sensor with error code for any case to read if the unit encounters any issue.

Anything else?

No response

[crnjan]

Add just a function to be able to override the A/C unit's internal temp sensor with a value from ESPHome. This is supported through CN105 connection using factory wired thermostat.
It would be enough to just have a lambda way to update this value, which we could call from an interval. It's very easy because if there's no repeated update through this channel the heapump falls back to its own sensor. There's no need for a full-blown implementation with selcts etc. as this is an advanced topic anyway. Just a note in the doc that there's a lambda to override the internal sensor.
Use case is very simple: use a BLE temp sensor placed optimally in the room, which could be forwarded to the A/C unit through ESPHome directly. Not even necessarily to involve HA.

esphome/esphome#15558

[nagyrobi]

SLZ-M35FA works OK with this feature like below:

sensor:
  - platform: ...
    ...
    id: my_temp
    update_interval: 10s
    accuracy_decimals: 1
    force_update: true
    filters:
      - filter_out: nan  # occasional NaNs are OK
      - timeout: 1800s  # sent value will be NaN after this amount of time to guard from sensor failures
    on_value:
      - if:
          all:
            - select.is:
                id: sel_temp
                options: "External"
            - lambda: return (!isnan(x));
          then:
            - lambda: id(ac).set_remote_temperature(x);
          else:
            - lambda: id(ac).clear_remote_temperature();


select:
  - platform: template
    name: "Temperature Source"
    id: sel_temp
    optimistic: true
    options:
      - Internal
      - External
    restore_value: true
    initial_option: "Internal"
    on_value:
      - if:
          condition:
            select.is:
              id: sel_temp
              options: "Internal"
          then:
            - lambda: id(ac).clear_remote_temperature();

[nagyrobi]

It wrould probably be worth to pre-set from py the default visuals for the climate component to match the capabilities of the Mitsubishi units.

Can be set manually with:

climate:
  - platform: mitsubishi_cn105
    ...
    visual:
      temperature_step:
        target_temperature: 0.5
        current_temperature: 0.5

which unveils a bug: in HA, in the climate popup, if I press the "+" icon to select for example "20.5", it will jump to "21" after a moment. Seems like it doesn't like ".5" values. If I press the "-" icon I can set ".5" values. Broken only with "+".
I can set ".5" values from the wall panel of the unit so it definitely supports those.

[crnjan]

Currently values are being rounded so only ... 19, 20, 21, ... are allowed.

Can you try esphome/esphome#15488 where this was changed and values are rounded to 0.5? (no need to set or use use_fahrenheit)

[nagyrobi]

That fixes it!
(Can't test together with set_remote_temperature though as only one PR can be effectively imported in external_components targetting the same component.)

[crnjan]

Great, thx for confirming - when both PRs are merged it should work as expected.

[nagyrobi]

Tested working on Mitsubishi SLZ-M35FA / SUZ-M35VA and MSZ-HR35VFK / MUZ-HR35VF.

[paravoid]

Posting this here for the lack of a better venue:

I really appreciate the renewed interest, effort as well as the fact this was merged super quickly (in less than two weeks!) and is even part of the 2026.4 release now. I can't help but feel a bit bummed however by the fact that this started completely from scratch, ignoring the efforts of #7289, without even a mention or comment there, or any considerable progress (or really, any feedback for literally years - the PR is still open to this day even!).

Among other issues, the mUART group is an ESPHome-native project has gone into great lengths to reverse engineer and properly document in https://muart-group.github.io/ - efforts that are IMHO superior to SwiCago in its understanding of the protocol. Worth noting that mUART themselves have examined and credited alternative implementations (including the plethora of them that exist for ESPHome).

I understand the need for smaller bite-sized chunks that are easier to review, but consider the ultimate goal of this to be code quality and reliability. I feel that ignoring a battle-tested implementation that has been in production across dozens of users, multiple models of heat pumps and thermostats, for literally thousands of hours over the past 2 years, and instead writing brand new code that has seen limited testing in the real world, goes against that ultimate goal. I'm sure the kind folks would have split up the code further if this was asked of them, too. ( (#7289 was after all a smaller version of #6794 specifically to ease review & upstreaming).

To be clear: I am not affiliated with the mUART group in any way. I am just someone that has been running their code on 5 entirely different units, from different decades, in different homes, with different ESP boards, for a couple of years now (I was using echavet's code even before that). It's been running flawlessly, and kept up-to-date with newer ESPHome versions. The documentation was great and community was also super responsive on their Discord and multiple developers helped me with a couple of issues at the time.

[nagyrobi]

Well unfortunately #7289 appears to be abandoned. In the last 6-8 months ESPHome development practices changed a lot and it looks like that PR didn't get the love it desired.
Even now it "has conflicts that must be resolved" you can't expect ESPHome devs to fix those instead of the submitter.

I've been using the muart version for 1.5 years until now but I really felt that focus decreased lately. Some radical changes appeared in ESPHome codebase lately which cause the component to fail after a new ESPHome version was released, some of us had to draw the component devs attention to that - luckily the external component was not abandoned yet.

I've been using ESPHome and HA for about 7 years now, seen many external component being developed and abandoned after some time. There's nothing better than using components built-in, which are supported on long term. It really makes sense, when one starts developing a component, to target it as a native component from the first step, rather than play around with it as an external first, and then having to re-do most of it to pass the reviews when trying to submit it later.

Now I'm trying my best to help @crnjan in his work to make it in the main codebase. I did that with muart's PR too (my comments on those PRs prove that), but it seems that interest decreased from the devs to continue maintaining it to ESPHome's rigurous reqirements to be accepted.

[samphonic]

some of us had to draw the component devs attention to that
it seems that interest decreased from the devs to continue maintaining it

You can just @ me, I'm here in the discussion already 😜😜

you can't expect ESPHome devs to fix those instead of the submitter

Fair, but it also seems unreasonable for me to perpetually maintain the mergability of a PR that isn't going to be merged. #7289 was the second PR addressing feedback from the first one (#6794), but it never received any significant response from the ESPHome team. After a few months of unsuccessfully attempting to either address concerns or get feedback I felt it was better to focus on helping users with bug fixes and new features in the external component, rather than chasing the PR.

There's nothing better than using components built-in

On this we can agree, which is why I put so much effort into trying to get the mITP component merged with ESPHome. This is also why I was unable to proactively catch any of the breaking changes ESPHome rolled out until after they were rolled out; no testing is done with external components so if something is broken without a deprecation notice, there's no opportunity for these to get fixed before release (to be clear: not a complaint per se, that's just the nature of allowing plugins). It's much better for everyone if the component is built-in to ESPHome.

The mitsubishi_cn105 component is built-in now, so this is indeed where effort should be focused. I don't want the lack of success of the previous PRs to be confused for a lack of interest on my part. As time (and PR approvals) permit, I will try to migrate features from mITP to mitsubishi_cn105.

[samphonic]

Some brief comments within the scope of this being a features request:

tl;dr

It would be nice to eventually bring this implementation up to feature-parity with the mature/full-featured implementations already out there:

• https://github.com/muart-group/esphome-components
• https://github.com/echavet/MitsubishiCN105ESPHome

Remote Temperature Sensors

(A)

It would be enough to just have a lambda way to update this value, which we could call from an interval. It's very easy because if there's no repeated update through this channel the heapump falls back to its own sensor. There's no need for a full-blown implementation with selcts etc. as this is an advanced topic anyway.

Using remote sensors is actually a very common use case (the internal sensor is notoriously unhelpful) so it's probably worth supporting it properly. It's also handy for automations where you may want to e.g. use the bedroom sensor at night, but livingroom sensor during the day. You can reference our implementation here as an example if it's helpful.

(B)

Once implemented, a big issue will be that a lot of Mitsubishi equipment expects a temperature report every <60s, but most remote sensors (especially battery operated ones) report very infrequently. We have two strategies for addressing this; one of them is just to use a push-service called by HA, but the echo implementation is very commonly used as well

MHK2 Support

Another really commonly used feature is the ability to daisy-chain an MHK2 (or similar) thermostat to the ESP32 so that both can be used to control the heat pump (additionally the thermostat's temperature can be used as a remote temperature sensor; it's usually already placed in a good location in the house).

This is a heavier lift, so might warrant its own feature request; I don't know if this discussion is meant to be a collection, or just a jumping-off point. (Fahrenheit support also gets a little complicated but we have an implementation for that too.

Additional Sensors

There are a handfull of additional sensors exposed by the ITP protocol that are useful for keeping tabs on the system; it would be nice to see those exposed here as well.

(Only-kind-of-a-feature) Packet Logic

Not a "feature" per se, but wanted to at least float the idea of separating the packet-parsing logic from the climate-logic. If it's easy to switch out now while the component is small, pulling in the itp-packet library for handling packets might save a lot of effort re-implementing all the various packet types and byte getters/setters. It also keeps this component small and focused on the HA/Climate implementations without having to muck about in Mitsubishi's weird proprietary things.

---

I'm biased 😉, but I can vouch for the MITP Component implementation to be stable and consistent if that can be a useful source of examples for additional features.

Also, I'm more than happy to help however I can getting these features implemented here (and as @paravoid mentioned there's a ton of experience among the users in the Discord server as well).

[nagyrobi]

For Remote Temperature Sensors the lambda approach is perfect imho. It gives best flexibility for anyone needing that, without having to tie it down to specific implementations. The example above implements it with a template select, and handles repetition of temperature reads too. One might want not to use select but something else etc. One may want to experiment with specific heatpumps behavior and having a lambda exposed to that allows for individual/specific/custom use cases without having to leverage the devs to implement them. Any use case can be covered with these lambdas and existing other, standard ESPHome helper components. More flexible on long term and easier to maintain.
I don't have any issue with the muart approach either, as that one also worked well for me.

[samphonic]

Lambdas can interact with select components, and a select component could leverage API functions to work, so this doesn't need to be an either-or situation. Lambda-only support is a fine place to start, but I think it would be nice for users who don't want to lambda everything together to have an (even if it's not as flexible) easy option. Adding a select menu might be an easy PR for me to attempt while I learn the new codebase.

[crnjan]

I can’t really comment on how the review/merge process itself is handled, but I’d like to address the “from scratch” point specifically.

The functionality that was added to ESPHome is actually based on work I originally did back in 2020 for ESPEasy (https://espeasy.readthedocs.io/en/latest/Plugin/P093.html#p093-page). At the time I was using openHAB and chose ESPEasy as an off-the-shelf firmware that integrated well with it. So the core logic here isn’t new — it’s effectively been battle-tested in real-world setups for over 6 years now.

When I later migrated to Home Assistant, I also started moving from ESPEasy to ESPHome. My initial PR essentially adapted that existing ESPEasy implementation to ESPHome, but it was quite large and would likely not have been reviewed in that form. Based on the feedback to submit smaller, more reviewable chunks, I took that as a challenge and split things up into multiple PRs. In the process I rewrote the code, improving structure and overall quality along the way with the help of reviewer feedback.

Also worth mentioning — I wasn’t aware of the other PR implementing similar functionality at the time. I only came across it later when someone referenced it, so there was no deliberate attempt to overlook existing work.

This also means the implementation here wasn’t meant as a “start from scratch” effort in the sense of reinventing everything — nor as a competition with other approaches. It was more about iterating toward something that fits ESPHome’s standards and review process, while also being a fun learning experience.

Because of that incremental approach, what’s currently merged is still fairly minimal feature-wise, and there’s more already in progress:

• [mitsubishi_cn105] Add Fahrenheit support esphome#15488
• [mitsubishi_cn105] Add C++ API for setting/clearing remote room temperature esphome#15558
• [mitsubishi_cn105] Add basic swing support esphome#15653

At the end of the day, everyone is free to use whatever approach or implementation works best for them. Hopefully, all of these efforts bring something useful, and everyone can benefit from them. And thanks to everyone for the feedback, collaboration, and all the hard work that helped add and extend the functionality across so many projects, allowing us to control so many aspects of our ACs.

[samphonic]

At the end of the day, everyone is free to use whatever approach or implementation works best for them. Hopefully, all of these efforts bring something useful, and everyone can benefit from them.

I think everyone benefits most from a built-in component so I'd like to focus on contributing to mitsubishi_cn105 rather than maintaining separate alternatives for the same functionality.

Mostly I want to make sure the user experience is good, and we don't lose any of the little quirky edge cases we've addressed in mITP (legacy and modern temperature bytes, energy usage, MHK2 support, etc.)

[kpfleming]

I wasn’t aware of the other PR implementing similar functionality at the time. I only came across it later when someone referenced it, so there was no deliberate attempt to overlook existing work.

As noted above it had been open for many months, and a previous PR had been open for many months before that. A search for CN105 would have found it very quickly.