2025.10 Thermostat with Auto mode

kltye · October 8, 2025, 1:20am

I have an Econet-based heatpump water heater, and I’ve been successfully controlling it with the esphome-econet integration. It only has two operating modes, “Off” and “Auto”. With the 2025.10 update, in “Auto” mode, I can’t set the temperature:

I have to set the mode to “Off”, before the temperature slider comes back and I can then set the temperature. Am I doing something wrong, is the integration doing something wrong, or is there a bug in the thermostat card?

karwosts · October 8, 2025, 3:44am

The behavior of the thermostat is generally governed by the attributes of the entity.

Can you share your entity id and attributes when it is in this state?

Is it implemented as a climate or a water_heater?

disruptivepatternmat · October 10, 2025, 6:25am

[thermostat] General clean-up, optimization, properly support "auto" mode by kbx81 · Pull Request #10561 · esphome/esphome · GitHub some one named kbx81 made this change it is unclear why. It has really caused issues for people in the Mitsubishi world. It essentially breaks the Auto mode built into these units (they have no dual set point, that has to be “faked”).

@kbx81 seems to be here as well…perhaps he can explain the thought process behind removing this mode. It used to be described as something about AI and such in the older docs, now it just says automation and explicitly removes the set point. My guess he didnt know we were using it this way.

Please see: Auto mode shows no target temperature · Issue #401 · echavet/MitsubishiCN105ESPHome · GitHub

disruptivepatternmat · October 10, 2025, 6:35am

now
auto_mode (Optional, [Action]): The action to call when the climate device is placed into “auto” mode (it may both cool and heat as required). This mode is different from heat_cool_mode (above) in that it takes control of the set points away from the user; it’s generally intended for exclusive use by automations.

vs

used to be
auto_mode (Optional, [Action]): The action to call when the climate device is placed into “auto” mode (it may both cool and heat as required).

so looks like we can no longer use this in the same way…which is kind of confusing. I am not sure why this “fixed” but ideally we can revert or have some idea on how to move forward from @kbx81

kbx81 · October 10, 2025, 8:50am

As you’ve noted in the documentation, “auto” mode is for on-device control/automation of the set point(s); this behavior is now consistent with other integrations in Home Assistant.

I gather that, in the past, heat_cool and auto modes have often been conflated; we identify them as two unique modes of operation for the climate component.

To have two user-controllable set points in the UI, a component should use heat_cool mode, not auto mode; see the documentation. If the ESPHome component was (incorrectly) using “auto” mode for “heat/cool” mode, the component should be patched to use heat_cool mode which will permit user control of both set points in the UI.

If there is a specific ESPHome component that needs to be patched, please create an issue, identify the specific component which needs patching and tag me on it. I’m happy to do a patch. For external components, the external component author will need to update their component accordingly. If it’s just a matter of swapping in heat_cool mode for auto and the component isn’t doing something particularly unusual under the hood, the change is quite trivial (it’s just a flag).

disruptivepatternmat · October 10, 2025, 5:19pm

So the problem is that the millions and millions of Mitsubishi pumps that use the cn105 protocol do not support dual set point - we have to fake it. They have modes that are heat/cool/fan/off and auto. They have built in logic that makes auto take 1 set point and for a +/-2C around it. This allows them to negotiate with multi head systems and make some heat up/cool down choices.

This is why we long ago (and I mean years now, I started working on this 7 years ago) implemented Auto as we did to match the way the pumps worked. For about 3 years now this Auto mode has been working exactly as we needed it to.

You have made a change in the framework that has broken the way we use this in real life because the documentation stated clearly the auto mode in esphome/ha was for… you guessed it auto mode; that is why I pasted the documentation above. None of us are understanding why you did this…

Can you explain why you removed this capability? Did you consult with any of us using it per the documentation? What is the process to have this rolled back to be useable? Who wanted this reduction in capability?

We have implemented dual setpoint heat/cool but now we have no way to use the primary working mode that Mitsubishi implemented in these devices. This seems really strange… and it was exactly per the documentation which existed for years.

disruptivepatternmat · October 10, 2025, 5:36pm

github.com/esphome/esphome

AUTO Mode Change in ESPHome Breaks Millions of cn105 units built in control

opened 05:34PM - 10 Oct 25 UTC

disruptivepatternmaterial

### The problem A strange and dubious change was in the framework around thermo…stat/climate which we use extensively in the heat pump world. For years the documentation stated: **_auto_mode (Optional, [Action]): The action to call when the climate device is placed into “auto” mode (it may both cool and heat as required)._** And these devices made by Mitsubishi do not support HEAT_COOL they only have fan/off/auto/heat/cool (and some not even heat or cool, but all have auto). The auto mode in these units is documented as a single setpoint which the device lets span 2 degrees around +/-. This allows it to manage load in a multi head setup and other inbuilt energy management and warmup/cool down actions. For years we have used this per the documentation pasted above. In a recent change for some unknown reason (the PR is very vague as to why this change was even needed) that ability to use this has changed and we can no longer use this mode as a single set point in the UI in HA and other uses. We have implemented dual set point, but that is a true dual set point and ignores auto mode. It uses the ESPHome thermostat to switch the split unit to modes in the esp not on the controller built into the unit. It is essentially faking a heat cool mode that doesn't natively exist. I wrote this code and I wrote the code to enable the AUTO mode 3 ish years ago. I also wrote 3 other prior versions of controlling these units going back 7 years. I am guessing no one realized how many people were using this per the documentation and made this change thinking it was an improvement (otherwise why do it?) but it is not and we need auto mode to return, especially since we cannot have single and dual set point in the same ESPHome setup. We have the same issue with the dry mode, but it is less important than auto given how much auto is used. So...the hardware we are attempting to control has worked as expected for years until this change was made in ESPHome. We either need to know how the code owner expects us to handle the fact that AUTO and HEAT/COOL are important and distinct things in these units or we need this returned to how it worked per the documentation for years. https://github.com/esphome/esphome/pull/10561 is where this change was made. ### Which version of ESPHome has the issue? 2025.9.3 ### What type of installation are you using? Docker ### What platform are you using? ESP32 ### Component causing the issue climate/thermostat ### YAML Config ```yaml https://github.com/echavet/MitsubishiCN105ESPHome for full details. ``` ### Anything in the logs that might be useful for us? ```txt no ``` ### Additional information https://www.mitsubishielectric.com.au/homeowner/support/heat-mode-vs-auto-mode/ DIFFERENCE BETWEEN HEAT MODE VS AUTO MODE HEAT MODE HEAT mode The unit purely operates in heating mode. The indoor unit will blow warm air into the room until the set temperature is reached. Once the temperature is reached, the inverter compressor in the outdoor unit will slow down and eventually stop. The indoor fan will effectively stop when the indoor unit cools down to avoid a draught. When the temperature in the room falls heating will resume. When summer comes you will need to manually change the mode to COOL or AUTO (recommended). AUTO MODE (Auto changeover mode) AUTO mode remote control symbol In this mode, the unit will run on HEAT or COOL depending on the room and set temperatures. Simply set the desired temperature and the inverter compressor will speed up and slow down to maintain temperature. Once the temperature is reached, the outdoor unit will slow down and eventually stop. The indoor fan will effectively stop when the indoor unit cools down to avoid a draught. When the temperature in the room falls during winter, heating will resume. If the room temperature is 2ºC above the set temperature in winter, the unit will automatically switch to COOL to maintain temperature. During summer, the unit running on AUTO mode will automatically switch to cooling to maintain temperature. For convenience, AUTO mode is recommended. Just set and forget.

We would like this rolled back/fixed or a carry forward plan because as I have written there, heat/cool/auto are very purposefully distinct things in the heat pump world.

kltye · October 10, 2025, 7:14pm

Just to close the loop here, I discovered that the esphome-econet folks have fixed this problem in their component. I also do not agree with this reduction in features in the “Auto” mode, but at least for the water heater issue for me, it’s been solved.

kbx81 · October 10, 2025, 9:38pm

I want to be sure I understand the issue correctly:

The Mitsubishi pumps only natively support a single set point.
The external component is designed to support a dual set point mode–in which the two set points are “faked”–which you access by setting the component to use “auto” mode.

Is this correct?

We have implemented dual setpoint heat/cool

What I do not understand is the difference between the Mitsubishi “auto” mode and the heat/cool mode you mention here? Is this anything more than cosmetic? (By “cosmetic” I mean you see/select “auto” mode in the UI but it’s really just doing what we define as “heat/cool” mode behind the scenes.)

Home Assistant defines “heat/cool” mode and “auto” mode as different things. The change I made simply brought the thermostat component to parity with that definition.

kbx81 · October 10, 2025, 10:29pm

I read through the issue & linked documentation and I think that answered my questions above. I left a comment. We’ll get this sorted out.