hardware_settings for Thermal Off Fan (codes 125/127) not working on SEZ ducted units

[pfbns]

hardware_settings for Thermal Off Fan (codes 125/127) not working on SEZ ducted units

Summary

The hardware_settings feature returns only zeros on my SEZ-KD25VAQ ducted unit, preventing configuration of thermal off fan behavior (function codes 125/127). However, this functionality definitely exists via CN105 since Mitsubishi's own MHK1/MHK2 controllers use the same CN105 connector to configure these exact settings.

Hardware

• Indoor Unit: SEZ-KD25VAQ (ducted)
• ESP Device: M5Stack NanoC6
• ESPHome Version: 2025.12.x
• MitsubishiCN105ESPHome Version: Latest from main branch

The Problem

When I add hardware_settings to my configuration:

climate:
  - platform: cn105
    id: ac_clima
    name: "AC Sala/Cozinha"
    uart_id: HP_UART
    update_interval: 6s
    
    hardware_settings:
      update_interval: 24h
      list:
        - code: 125
          name: "Fan during Thermo-OFF (Heat)"
          options:
            1: "Extra Low (Default)"
            2: "Stop"
            3: "Set Speed"
        - code: 127
          name: "Fan during Thermo-OFF (Cool)"
          options:
            1: "Set Speed (Default)"
            2: "Stop"

The component returns zeros and disables polling, as documented. However, this is not a unit limitation.

Evidence that CN105 supports Function Settings on ducted units

1. Official Mitsubishi Documentation

Mitsubishi's Application Note 3048 ("How to turn off the indoor unit fan when set point is met") explicitly lists SEZ series as compatible with Method 1: Function Settings via controllers like MHK1/MHK2.

PDF: http://enter.mehvac.com.s3.amazonaws.com/DAMRoot/Original/10006/Application%20Note%203048%20ME%20-%20How%20to%20turn%20off%20indoor%20unit%20fan%20when%20set%20point%20is%20met.pdf

The document shows:

• Code 125 - Thermal Off Fan Operation (Heat Mode): 1=Extra Low, 2=Stop, 3=Set Speed
• Code 127 - Thermal Off Fan Operation (Cool Mode): 1=Set Speed, 2=Stop, 3=Extra Low

2. MHK1/MHK2 use CN105

The MHK1 and MHK2 wireless controllers connect via the same CN105 connector and can configure these settings:

• Hold Fan + Up Arrow for 3 seconds
• Navigate to FS 125 or FS 127
• Select option 2 for "Stop"

This proves the protocol supports reading/writing function settings - the MHK1/MHK2 are doing exactly this over CN105 serial.

3. Community Confirmation

Multiple sources confirm this works on ducted units:

• https://www.greenbuildingadvisor.com/question/mitsubishi-minisplit-secret-advanced-settings
• Handling of Function Settings SwiCago/HeatPump#126

Request

Could someone with an MHK1/MHK2 controller help capture the actual UART packets when reading/writing function settings 125/127? This would allow proper implementation in the library.

Alternatively, if anyone has documentation on the packet format for function settings (likely using command bytes different from the standard 0x41/0x42), please share.

Workaround

Currently using a Home Assistant automation that turns off the AC when compressor frequency reaches 0 Hz. This works but is not as elegant as native thermal-off support:

automation:
  - alias: "Stop Indoor Fan When Compressor Idle"
    trigger:
      - platform: numeric_state
        entity_id: sensor.ac_compressor_frequency
        below: 1
        for: "00:01:00"
    condition:
      - condition: state
        entity_id: climate.ac_unit
        state: ['cool', 'heat']
    action:
      - service: climate.turn_off
        target:
          entity_id: climate.ac_unit

Questions

1. What packet format does the library currently use to query function settings?
2. Has anyone successfully captured MHK1/MHK2 traffic when configuring function settings?
3. Is there a different command byte or packet structure needed for ISU (Installer Setup) settings vs. normal operation settings?

Thank you for this excellent project! Happy to help test any fixes on my SEZ-KD25VAQ unit.

[echavet]

Hi @pfbns,

Thank you very much for the detailed report and the evidence you provided (especially the Mitsubishi Application Note 3048). This is very helpful for moving this forward.

After reviewing your logs and comparing them with official protocol documentation and other community projects (like MHK2 captures), we (Gemini and I) have identified two main reasons why hardware_settings are currently failing on your SEZ unit:

Handshake Privileges: By default, this library connects using the standard 0x5A handshake (the "Remote Controller" mode). However, SEZ and other P-Series units often require the 0x5B handshake (the "Installer/Service" mode) to unlock the visibility and write-access of Function Settings (ISU). Without this, the unit often returns "masked" values (zeros).

Over-restrictive Detection Logic: Our current implementation has a bug: it automatically disables the feature if it receives zeros during the initial scan. We now realize that a "zero" doesn't mean the unit is incompatible; it often just means the value is "null" or "default" because of the standard handshake mentioned above.

What we are working on: We are currently implementing a fix that includes:

A new installer_mode option: You will be able to toggle this in your YAML configuration. When enabled, the ESP will connect using the 0x5B packet, signaling the indoor unit that it is an authorized service tool.

Improved Support Detection: We are rewriting the logic so the component won't disable itself as long as the unit returns valid function headers, even if the values are currently zero.

I am finalizing the code changes with the help of Cursor and Gemini. I should be able to provide a test version very soon.

Thank you for your patience and for helping us make this library compatible with ducted units!

[echavet]

Hey @pfbns

I can't test the 0x5B installer mode handshake because my MSZ unit does not support it. I have no reply from my heatpump to this code.

I need someone to test it!!
Could you please?

logger:        
  hardware_uart: UART0
  level: DEBUG
  logs:
    esp32_ble_client: INFO
    EVT_SETS : DEBUG
    WIFI : INFO
    MQTT : INFO
    WRITE_SETTINGS : INFO
    SETTINGS : DEBUG
    STATUS : INFO
    CN105_CONN: DEBUG
    CN105Climate: WARN
    CN105: INFO
    climate: INFO
    sensor: WARN
    chkSum : INFO
    WRITE : WARN
    READ : DEBUG
    ACK : INFO
    Header: INFO
    Decoder : INFO
    CONTROL_WANTED_SETTINGS: INFO    
    control: INFO    
    UPDT_ITVL: DEBUG
    CYCLE: DEBUG
    OPERATING_STATUS: DEBUG
    HEAT_COOL: DEBUG  
    DUAL_SP: DEBUG   
    TEMP_SENSOR: INFO
    REMOTE_TEMP: DEBUG
    FUNCTIONS: DEBUG
    HardwareSelect: DEBUG

external_components:
 - source: 
    type: git    
    url: https://github.com/echavet/MitsubishiCN105ESPHome.git
    ref: DEV                           # <-----      DEV branch

...

climate:  
  - platform: cn105      
    name: Climatisation Chambres
    id: "heatpump_chambres"    
    uart_id: HP_UART     
    installer_mode: true        # <-----      new feature test

[pfbns]

Hi @echavet,

Many thanks for this,

I tested the DEV branch with installer_mode: true on my SEZ-KD25VAQ ducted unit. Here are the results:

Configuration Used

external_components:
  - source:
      type: git
      url: https://github.com/echavet/MitsubishiCN105ESPHome.git
      ref: DEV

climate:
  - platform: cn105
    id: ac_unit
    uart_id: HP_UART
    update_interval: 6s
    installer_mode: true

Test Results: 0x5B NOT Supported

The SEZ-KD25VAQ does not respond to the installer mode handshake (0x5B):

[15:48:58.872][I][CN105_CONN:026]: Envoi du paquet de connexion en mode Installateur (0x5B)...
[15:48:58.873][D][CN105_CONN:353]: FC 5B 01 30 02 CA 01 A7

... (10 second timeout, no response) ...

[15:49:08.875][E][CN105_CONN:040]: --> Heatpump did not reply: NOT CONNECTED <--
[15:49:08.877][W][CN105_CONN:046]: No reply to installer handshake (0x5B). Falling back to standard handshake (0x5A).

Fallback Works Correctly

The automatic fallback to standard mode (0x5A) works perfectly:

[15:49:08.883][I][CN105_CONN:026]: Envoi du paquet de connexion en mode Standard (0x5A)...
[15:49:08.892][D][CN105_CONN:353]: FC 5A 01 30 02 CA 01 A8
[15:49:08.929][D][READ:353]: FC 7A 01 30 01 00 54
[15:49:08.936][I][CN105_CONN:489]: --> Heatpump did reply: connection success (User, 0x7A)! <--

Additional Finding: Power/Standby (0x09) Not Supported

The SEZ-KD series also doesn't support the Power/Standby query (0x09). After 3 failed attempts, it's correctly disabled:

[15:49:15.272][D][CYCLE:060]: Sending Power/Standby (0x09)
[15:49:15.777][W][CYCLE:089]: Soft timeout for Power/Standby (0x09), failures: 1
...
[15:49:29.367][W][CYCLE:093]: Power/Standby (0x09) disabled (not supported)

Happy to run more tests if needed!

[echavet]

Great
Thanks.
It looks like this was a dead end. And what about the function codes ?
I have changed the disable conditions. My unit only replies with zero codes.
But yours is supposed to support them.
⚠️I've read somewhere that the unit power had to be off to write function codes.
😔I'm disappointed about all these failures !!

[pfbns]

Function Codes Test Results - SEZ-KD25VAQ

I tested hardware_settings with codes 125/127 on my SEZ-KD25VAQ. Unfortunately, my unit also doesn't respond to 0x20/0x22 commands.

Test Results

Tested with AC both OFF and ON (compressor running 14-38 Hz):

[16:11:44.618][D][FUNCTIONS:060]: Sending Functions Part 1 (0x20)
... (13 seconds, no response) ...
[16:11:57.366][W][CN105:009]: Cycle timeout, reseting cycle...

[16:12:47.786][D][FUNCTIONS:060]: Sending Functions Part 1 (0x20)
... timeout ...

[16:13:06.747][D][FUNCTIONS:060]: Sending Functions Part 2 (0x22)
... timeout ...

Command	AC OFF	AC ON	Result
0x20	Tested	Tested	No response (timeout)
0x22	Tested	Tested	No response (timeout)

Conclusion

The SEZ-KD doesn't even acknowledge 0x20/0x22 - it's not returning zeros like your MSZ, it's returning nothing at all.

This suggests SEZ ducted units may use a completely different protocol for function settings. Could the MHK1/MHK2 be sending different commands to access codes 125/127?

Would love to help more - is there anything else I can test?

[echavet]

Yes it is probably be the case: we did not decode the whole protocol.
I don't have any of MHK1/MHK2 device. And even if I had one, it wouldn't help for other units than mines.
The only way to solve this is to build and program another ESP to setup a man in the middle for people who own official devices, and to gather the packets on a centralized server... complicated !

[pfbns]

I’d really like to find a solution to this problem. I’ve searched for MHK2 prices, and they are incredibly expensive. The documents indicate that my unit supports this, so I’ll likely purchase one second-hand and join you in trying to solve this issue, at least in what I can contribute, with the ducted units. If there’s another solution that doesn’t involve the MHK2 expenses, that would be even better.

[disruptivepatternmaterial]

Somewhat related...on all of my units the codes more or less work, there are no errors. But the settings are not reflected in esphome or HA. Meaning if I change the temp source to external the logs make it look like it worked, but if I refresh the web page the setting is reverted to default.

What does this mean?

[echavet]

Somewhat related...on all of my units the codes more or less work, there are no errors. But the settings are not reflected in esphome or HA. Meaning if I change the temp source to external the logs make it look like it worked, but if I refresh the web page the setting is reverted to default.

What does this mean?

How do you make the change for the temp source?
With IR or with HA?
I think the functions code changes must be done with the unit off. Could you try?

[disruptivepatternmaterial]

Somewhat related...on all of my units the codes more or less work, there are no errors. But the settings are not reflected in esphome or HA. Meaning if I change the temp source to external the logs make it look like it worked, but if I refresh the web page the setting is reverted to default.
What does this mean?

How do you make the change for the temp source? With IR or with HA? I think the functions code changes must be done with the unit off. Could you try?

Temp source is coming from HA. Interesting on the power thing, that was not the case with the kumo and I just tested it and the settings throw no error but do not persist.

12:19:54	[I]	[CYCLE:052]	
6: Cycle ended in 0.8 seconds (with timeout?:  NO)
12:19:55	[I]	[FUNCTIONS:238]	
Hardware setting change: Code 125 -> 3 (Set Speed)
12:19:56	[I]	[CYCLE:039]	
1: Cycle start

[disruptivepatternmaterial]

Somewhat related...on all of my units the codes more or less work, there are no errors. But the settings are not reflected in esphome or HA. Meaning if I change the temp source to external the logs make it look like it worked, but if I refresh the web page the setting is reverted to default.
What does this mean?

How do you make the change for the temp source? With IR or with HA? I think the functions code changes must be done with the unit off. Could you try?

Temp source is coming from HA. Interesting on the power thing, that was not the case with the kumo and I just tested it and the settings throw no error but do not persist.

12:19:54	[I]	[CYCLE:052]	
6: Cycle ended in 0.8 seconds (with timeout?:  NO)
12:19:55	[I]	[FUNCTIONS:238]	
Hardware setting change: Code 125 -> 3 (Set Speed)
12:19:56	[I]	[CYCLE:039]	
1: Cycle start

So I am seeing nowhere in the logs or anything from what I can tell that has the code querying the status of those settings. They are all just set to default.

[j9brown]

I encountered a similar issue with my PEAD-A24AA4 ducted units and have observed slightly different behavior worthy of note.

1. After configuring the functions_sensor and functions_get_button, I noticed that when I push the button while the equipment is operating (not idle), the request silently fails, the list is not populated, and the equipment transitions to the idle state! If the equipment is idle, then the request succeeds and the information seems correct.

2. When I configure the hardware_settings, the unit transitions to idle every time the settings are polled. So that's not actually usable during normal operation.

Given that my equipment seems to have the side-effect of turning itself off when the settings are queried or changed, I'd prefer if the hardware settings feature was implemented differently without polling.

Maybe there could be buttons to read / write the settings. Or it would be sufficient for me if I could put the settings I want to write into YAML and have them be applied the next time the device becomes idle.

[giovanni-berlanda]

Hi @echavet,

I have a SEZ-KD15NA4 and I also would like to configure the Thermal Off Fan.
I have tryed the DEV branch above and I also do not get the response at the 0x5B command from HA:

[21:45:49.356][I][CN105_CONN:027]: Envoi du paquet de connexion en mode Installateur (0x5B)...
[21:45:49.371][D][CN105_CONN:449]: |FC 5B 01 30 02 |->[CA 01 ](A7) <CONN_INST>
[21:45:59.368][E][CN105_CONN:041]: --> Heatpump did not reply: NOT CONNECTED <--

However my unit seems to properly respond when handshaked with the 0x5B command from a PAC-US444CN-1 thermostat interface:

name    data
PAC-US444CN-1    0xFC    0x5A    0x01    0x30    0x02    0xCA    0x01    0xA8
SEZ-KD15NA4      0xFC    0x7A    0x01    0x30    0x01    0x00    0x54
PAC-US444CN-1    0xFC    0x5B    0x01    0x30    0x01    0xC9    0xAA
SEZ-KD15NA4      0xFC    0x7B    0x01    0x30    0x10    0xC9    0x03    0x00    0x20    0x00    0x0A    0x07    0x05    0xE4    0x05    0xA6    0xBC    0x94    0xB8    0xA6    0xB8    0x4D
PAC-US444CN-1    0xFC    0x41    0x01    0x30    0x10    0x1F    0x06    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x59
SEZ-KD15NA4      0xFC    0x61    0x01    0x30    0x10    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x5E
PAC-US444CN-1    0xFC    0x41    0x01    0x30    0x10    0x21    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x65    0x00    0x00    0x00    0x00    0xF8
SEZ-KD15NA4      0xFC    0x61    0x01    0x30    0x10    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x5E
PAC-US444CN-1    0xFC    0x42    0x01    0x30    0x10    0x02    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x7B
SEZ-KD15NA4      0xFC    0x62    0x01    0x30    0x10    0x02    0x00    0x00    0x00    0x08    0x1A    0x00    0x05    0x00    0x00    0x00    0xAB    0x00    0x00    0x00    0x00    0x89
PAC-US444CN-1    0xFC    0x42    0x01    0x30    0x10    0x03    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x7A
SEZ-KD15NA4      0xFC    0x62    0x01    0x30    0x10    0x03    0x00    0x00    0x0B    0x00    0x00    0xAA    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0xA5

I'm happy to capture more traces if that could help.