Mitsubishi climate

[Danny-Dunn]

What does this implement/fix?

This new component implements communication with Mitsubishi Electric Heat Pumps via the RedLINK communication interface(UART).

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Other

Pull request in esphome-docs with documentation (if applicable): esphome/esphome-docs#3131

Test Environment

• ESP32
• ESP32 IDF
• ESP8266
• RP2040

Example entry for config.yaml:

#uart config included because the specific baud rate and parity config is important
uart:
  tx_pin: 1
  rx_pin: 3
  baud_rate: 2400 #9600 on some units
  parity: EVEN
  id: uart_0

climate:
  - platform: climate_mitsubishi
    uart_id: uart_0
    name: Heat Pump
    compressor_frequency:
      name: Compressor Frequency
    fan_velocity:
      name: Fan Velocity
    conflicted:
      name: Conflict
    preheat:
      name: Preheat
    inject_enable:
      name: Inject Enable
    control_temperature:
      name: Control Temperature
    remote_temperature:
      name: Remote Temperature
    temperature_offset:
      name: Temperature Offset
    vertical_airflow:
      name: Vertical Airflow

Checklist:

• The code change is tested and works locally.
• Tests have been added to verify that the new code works (under tests/ folder).

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated in esphome-docs.

[probot-esphome]

Hey there @Danny-Dunn,
Thanks for submitting this pull request! Can you add yourself as a codeowner for this integration? This way we can notify you if a bug report for this integration is reported.
In __init__.py of the integration, please add:

CODEOWNERS = ["@Danny-Dunn"]

And run script/build_codeowners.py

_{^{(message by NeedsCodeownersLabel)}}

[probot-esphome]

Hey there @martgras, @sjtrny, mind taking a look at this pull request as it has been labeled with an integration (scd4x) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[probot-esphome]

Hey there @trvrnrth, mind taking a look at this pull request as it has been labeled with an integration (bme680_bsec) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[Danny-Dunn]

I've very much looking forward to this being available directly in ESPHome! If there's anything I can do to help test once the PR is ready, let me know.

Yes, there are a few things I would like help testing with:

• The model I have doesn't have motorized horizontal airflow direction controls, need someone to test that feature who has access to a unit with such capability.(will add this as an experimental capability soon)
• The communication protocol supports two formats for the target temperature setting; one that supports full degree increments, and one that supports half degree increments. The status quo seems to be that the resolution that the unit supports is indicated by the resolution present on the supplied remote control. In my testing even my units(which only support full degree increments on the remote) support the half degree format, and can switch between the two formats on the fly, just depending on what you send it, which leads me to assume that all models support half degree increments regardless of the remote. I have removed the requirement for the component to receive a high precision temperature before it switches to sending them. Would like testing on other units that only support full degree on the remote, if there are no issues I will leave this behaviour as is.

In general, the full extent of the capabilities of the protocol are still unknown. The main parts of the protocol: settings, room temp, status, etc. come from previous reverse engineering efforts(see SwiCago's HeatPump Arduino library, and it's predecessors), but I have discovered a few more capabilities: actual fan speed(different from the speed setting), and loop flags(direction conflict and preheat). I believe there is yet more that the protocol can do. I am going to try accessing more status information, I hope to gain access to the coil temperature sensors, as well as the outdoor ambient temperature sensor.

[kpfleming]

I'll be happy to help, but my testing will be very different from yours as I have ducted air handlers (PVA-A24AA7 and PVA-A30AA7), so that means there are no vanes and thus no vane control. I've also just installed a CN105 splitter device on one unit (and will install one on the other unit) so I'll have the ESPHome devices connected at the same time as MHK2s on both units. I have no idea yet how the units will react to two controlling devices being connected at once, but the splitters are sold with the intention of them being used to connect 'cloud integration' devices and I'm expecting them to operate just fine.

In addition to the things you've mentioned, I've learned that there is an 'energy delivered' report from some units on a daily basis, and I'm very interested in getting those reports so that I can compute energy efficiency (I'm already measuring energy input into the systems).

[Danny-Dunn]

I have ducted air handlers (PVA-A24AA7 and PVA-A30AA7), so that means there are no vanes and thus no vane control.

do these units have similar settings to the wall-mounted units?

how the units will react to two controlling devices connected

I suspect it won't work(or at least not very well). The protocol relies on polling for status updates. In my testing, when a request is sent, then a second request is sent before the unit can respond to the first request, the unit drops both requests and does nothing. There may be bus collisions between the two devices if they both try a request at the same time. Also not sure if it would work electrically, as the MHK units may pull the bus to one rail while the esphome device tries to pull it to another. Interested to see how it turns out though! A possible solution in this case would be to just monitor the bus, without actually sending the requests, and then just relying on the other connected device to send the request, and parsing the response.

there is an 'energy delivered' report from some units on a daily basis, and I'm very interested in getting those reports

Very interested in this also, if I'm not mistaken I saw it as part of a reverse engineering effort on a Mitsubishi water heater? I'm going to try and find that project again, see if we can get those values out of the units. There seem to be many Mitsubishi climate control systems all operating on the same protocol.

[kpfleming]

do these units have similar settings to the wall-mounted units?

Yes, I've used them previously with the SwiCago library (via the esphome-mitsubishiheatpump external component).

I suspect it won't work(or at least not very well). The protocol relies on polling for status updates. In my testing, when a request is sent, then a second request is sent before the unit can respond to the first request, the unit drops both requests and does nothing. There may be bus collisions between the two devices if they both try a request at the same time. Also not sure if it would work electrically, as the MHK units may pull the bus to one rail while the esphome device tries to pull it to another. Interested to see how it turns out though!

The splitter I'm using isn't just a passive cable, it's got logic inside to handle two 'accessories' connected at once. I don't know what its behavior will be, but given the way the manufacturer intends it to be used I'm quite hopeful that it will work properly with an ESPHome component too.

[Danny-Dunn]

Yes, I've used them previously with the SwiCago library (via the esphome-mitsubishiheatpump external component).

do you have access to a logic analyzer?

The splitter I'm using isn't just a passive cable

In that case, seems like it'll work.

I've learned that there is an 'energy delivered' report from some units

I tried requesting status values 0xA1 and 0xA2 on my units and they didn't respond. Doesn't seem like they support that report.

The easiest way to probe additional status values for debug is to add a request_info_(uint8_t type) call to the status rotation in the loop. Any status request responses with an unknown type are dumped into the log. Beware that continuously requesting types which the unit will not respond to can cause the request queue to fill up as polling sends requests faster than the timeout.

edit: see the mitsubishi_protocol::InfoType enum for known info types

[henrykuijpers]

I'm a (relatively) happy user of the (I believe) SwiCaGo implementation on ESPHome for my Mitsubishi airco units (SRK 50ZS-W) - The main thing I noticed was that most of the capabilities are optional and therefore not always easily enabled/available.

For example, with the current esphome flash I'm using, I have no control over the horizontal/vertical vanes - I can only configure the fan speed and the mode (cooling/heating/off/...). I also can't configure the unit to be in silent mode, etc.

I would be happy to contribute to this PR and/or other branches etc, or do some testing with the various options/settings. I'd love to have a more feature-rich air conditioning device available in my Home Assistant. :)

[kpfleming]

do you have access to a logic analyzer?

Yes, I have an 8-channel Salae Logic clone, and I'm somewhat familiar with using PulseView.

[Algram]

@Danny-Dunn Thanks so much for working on this! I am also happy to help, although I am using the Ecodan Air to water heatpump model with the FTC6 controller. There is already code for communicating with it here: https://github.com/rbroker/ecodan-ha-local

I think the protocol is the same, so maybe it would make sense to add it to this lib as well?

[kkopachev]

@Danny-Dunn Horizontal vane control does not work. Selecting any horizontal direction resets Vertical vane direction to Auto. Console reports sending 'Horizontal Airflow': Sending state Swing (index 6) regardless of the value requested. Also, it is not swinging.

[Danny-Dunn]

I think the protocol is the same, so maybe it would make sense to add it to this lib as well?

I will look at implementing this in a separate PR, as the systems are dissimilar enough that it could warrant a new component.

[Danny-Dunn]

I'm a (relatively) happy user of the (I believe) SwiCaGo implementation on ESPHome for my Mitsubishi airco units (SRK 50ZS-W)

For example, with the current esphome flash I'm using, I have no control over the horizontal/vertical vanes - I can only configure the fan speed and the mode (cooling/heating/off/...).

Vertical vanes are working in my testing, and @kkopachev just submitted a suggestion to hopefully resolve an issue with horizontal vane control.

I also can't configure the unit to be in silent mode, etc.

Could you specify exactly what silent mode this is? The units I have feature a fan speed called 'silent' but we may be thinking of different features.

[Danny-Dunn]

In terms of testing I have done, this component has been running on 5 ESP8266 boards connected to 3 MSZ-GE09NA and 2 MSZ-GE12NA units for the past two months. I use remote temperature injection and offsets for certain units(temperature is passed in through a home assistant automation, not ideal but wanted to try using the native API exclusively).

[kkopachev]

@Danny-Dunn Setting horizontal vane is mostly working now. I don't know if it's my unit or general problem, but options Swing and <> for horizontal vane does nothing on my unit (MSZ-FS06NA)

Additionally, reading value of horizontal vane does not work. It does not match any cases in the switch statement. I am reading through code to see what's going on.

C to F conversion is a bit annoying, but maybe it's expected on ESPHome? My HA is using F and I can adjust by 0.5 degree, but obviously it converts to C for the unit and then next read from the unit gets converted again to F and it's a little of from what I just set. For example, starting point 75.2 F, next step is 75.7, but value read from the unit and converted to F shows as 75.5 (for example).

[Danny-Dunn]

@Danny-Dunn Setting horizontal vane is mostly working now. I don't know if it's my unit or general problem, but options Swing and <> for horizontal vane does nothing on my unit (MSZ-FS06NA)

Does your unit have these options available on the remote control/wall thermostat?

C to F conversion is a bit annoying, but maybe it's expected on ESPHome? My HA is using F and I can adjust by 0.5 degree, but obviously it converts to C for the unit and then next read from the unit gets converted again to F and it's a little of from what I just set. For example, starting point 75.2 F, next step is 75.7, but value read from the unit and converted to F shows as 75.5 (for example).

Hmm, the component(and units) work in C and I use HA in C so never noticed this. Seems that any temp conversion is being performed by home assistant, and it seems to be aware that the temperature is in C, and is converting it for the actual value, but not for the step? The temperature step on the units is 0.5C, and sounds like its just taking that without converting it. Seems like a HA bug.

[kkopachev]

Does your unit have these options available on the remote control/wall thermostat?

Figured that swing actually works fine, it's just so slow I didn't notice. And my unit does not have split mode.

[henrykuijpers]

So nice to see progress on this! Can I be of any assistance with my units? SRK-xx-ZS(X)-W are my units.

[kkopachev]

Suggested change

	switch (mode) {
	switch (mode > 0x08 ? mode - 0x08 : mode) {

For devices with iSee sensor and when it is enabled, then mode is shifted by 0x08.

[tiltec]

I'm also interested in this component! So far I'm using https://github.com/geoffdavis/esphome-mitsubishiheatpump to integrate it with ESPHome.

On an experiment today, I put this component on the ESP32-WROOM that is connected to the AC. Unfortunately, it always tells me that there was a timeout waiting for a response. I tried different baud rates (4800 which I used before) and different TX/RX pin definitions (I am using GPIO16/17), but the AC unit doesn't seem to reply. So I switched back to the old component.

Anyway, I noticed compilation warning, maybe that could be fixed?

src/esphome/components/climate_mitsubishi/climate_mitsubishi.cpp: In member function 'std::__cxx11::string esphome::climate_mitsubishi::ClimateMitsubishi::horizontal_vane_to_horizontal_airflow_select_(uint8_t)':
src/esphome/components/climate_mitsubishi/climate_mitsubishi.cpp:139:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

@henrykuijpers your units are most likely Mitsubishi Heavy (MHI) ones, this component is about Mitsubishi Electric (MEL). I noticed you mentioned https://github.com/SwiCago/HeatPump but you are probably using another library - the MEL communication format seems very different from MHI.

[Danny-Dunn]

I tried different baud rates (4800 which I used before) and different TX/RX pin definitions (I am using GPIO16/17), but the AC unit doesn't seem to reply. So I switched back to the old component.

Have you made sure that you are using even parity on the serial port? If that doesn't work and you have a logic analyzer lying around, you can attach it to the serial lines to see what's going on.

[tiltec]

I had another closer look and finally made it work. Most likely I had a bad physical connection. For level shifting I have a 10k resistor between 5V and RX (aircon side) and a 1.5k resistor in series for TX, to limit the current that is flowing into the protection diodes of the ESP32. I wonder how long that will last, might be better to get a proper 3.3V-5V level shifter!

My device doesn't report the compressor frequency (MSZ-HR50VF), but the rest seems to work.

Also, I wondered if there is more data that could be retrieved - some hints are in SwiCago/HeatPump#39 (comment)

[github-actions]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.