AirZone has a splitter for this but its pricey (~$75). AZX6ACCSPLMEL
Anyone here have this working with the MLZ series purchased recently?
I’m looking at getting these installed at my place and I definitely don’t want to use mitsubishi’s wifi control system. I also want to avoid using IR blasters (which is what I currently use) as they’re ugly, can’t read true state of the A/C.
I’m in NZ if it matters.
I found this video but its from 2019.
Not sure what you are asking…he shows you how to do it - exactly.
I will say that I replaced my 6 kumo units with these last night and FINALLY after years they JUST WORK.
I’ve been trying to get this working with a MSZ-GS06NA and having little to no success. I could use a bit of guidance from others. I’m pretty familiar with ESPHome and Home Assistant at this point, having created multiple ESP sensors with custom components, and the standard Sonoff S31 esphome flashing.
My setup:
- I have it wired to the mini split, I think properly. I have CN150 5V to VCC, CN105 ground to ground, and the CN105 vs ESP tx and rx pins swapped. Specifically CN105 TX = ESP UART2 RX (16), CN105 RX = ESP UART2 TX (17)
- I removed all pull-up resistors to avoid causing any confusion, since I see others saying they don’t have them. I haven’t had any difference with or without pull up resistors
- ESP32 powers up, and is visible in ESPHome, including the wifi signal and all the other stuff
- I am not using MQTT, I don’t see anything in the docs saying you need to, and the first hint that maybe I need to I’m seeing in this post, so I’m not sure if that’s a requirement
- my board is a standard ESP32 DEVKIT
- I’ve tried
baud_rate2400, 4800, 9200, no change - I’ve tried
loggerbeing normal orbaud_rate: 0, no change
What I’m seeing:
- Device shows up in Home Assistant. I can update over wifi. I can get logs. I can see it as a device with the entities that are expected.
- The climate device always shows up as off after a restart
- When I flip the climate device into heat mode, it doesn’t let me set a target temperature. I can force it to have a target temperature setting in dev tools’ services
- Changing settings on the climate setting has no effect on the actual mini split. Heat vs off, fan mode, vertical movement, none have any affect
Any pointers? My assumption is the UART connection isn’t working, but I have no idea why. I’ve rechecked my wiring 500 times.
Here’s my full config:
substitutions:
name: office-mini-split
friendly_name: Office Mini Split
esphome:
name: office-mini-split
friendly_name: ${name}
esp32:
board: esp32dev
framework:
type: arduino
external_components:
- source: github://geoffdavis/esphome-mitsubishiheatpump
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: <CUT>
ota:
password: <CUT>
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Office-Mini-Split"
password: <CUT>
captive_portal:
# Sync time with Home Assistant.
time:
- platform: homeassistant
id: homeassistant_time
# Text sensors with general information.
text_sensor:
# Expose ESPHome version as sensor.
- platform: version
name: ${name} ESPHome Version
# Expose WiFi information as sensors.
- platform: wifi_info
ip_address:
name: ${name} IP
ssid:
name: ${name} SSID
bssid:
name: ${name} BSSID
# Sensors with general information.
sensor:
# Uptime sensor.
- platform: uptime
name: ${name} Uptime
# WiFi Signal sensor.
- platform: wifi_signal
name: ${name} WiFi Signal
update_interval: 60s
climate:
- platform: mitsubishi_heatpump
name: "${friendly_name}"
# ESP32 only - change UART0 to UART1 or UART2 and remove the
# logging:baud_rate above to allow the built-in UART0 to function for
# logging.
# https://i0.wp.com/randomnerdtutorials.com/wp-content/uploads/2018/08/ESP32-DOIT-DEVKIT-V1-Board-Pinout-36-GPIOs-updated.jpg?quality=100&strip=all&ssl=1
hardware_uart: UART2
# tx_pin: 17
# rx_pin: 16
update_interval: 500ms
# baud_rate: 9600
# baud_rate: 4800
baud_rate: 2400
supports:
mode: ['HEAT_COOL', 'COOL', 'HEAT', 'DRY', 'FAN_ONLY']
fan_mode: ['AUTO', 'DIFFUSE', 'LOW', 'MEDIUM', 'MIDDLE', 'HIGH']
swing_mode: ['OFF', 'VERTICAL']
visual:
min_temperature: 15
max_temperature: 31
temperature_step: 1.0
switch:
- platform: restart
name: "Office Minisplit - Restart"
- platform: safe_mode
name: "Office Minisplit - Restart (Safe Mode)"
Also, editing in one more question: is this supposed to allow one to still use their remote? The reason I’m going the esp32 route versus using the IR repeater I have is I was expecting the esp32 route would let me see the current temperature and allow me to use the remote still. For instance, I’d update the target temp to 70°F with the remote, and I’d see it in HA. Is that correct?
I can’t help you with your core problem. There could be a number of things that went wrong… but it sounds like the issue is not with the ESP32 device itself. If I had to guess, you might have a soldering issue. This project was my first soldering job and I think I threw out one or two boards that didn’t turn out of the 5 I ended up making.
Yes - you can continue to use your legacy remote with this.
Update: no idea what was going on with that previous attempt. Today I switched to a different ESP32 board style (mini D1) and gave it another try and it is now connecting. 
. It shouldn’t have been the board or connectivity, because that previous ESP was being directly plugged into the cables, but who knows with these cheap ones.
Seems to have quite a bit of lag at the moment, but I’ll look into that when I have more time. Might have just been an artifact of my testing.
Has anyone looked into managing the on mini split scheduling? While I know I can do automations and scheduling in HA, and I likely will as part of presence based automations, I’d like the option of using the native scheduling on the device.
Also, should the remote update with the states you set directly? Eg if I set the temperature to 70° on the remote, and then switch it to 65° via HA, can I get the remote to show 65°?
1 Like
ESP8266 to control MSY-GE13VA Mitsubishi air con from its CN105 board
As the title suggest, im trying to control an mitsubishi air con with just an ESP32 from its CN105 board on the inside of the air con. I want to see if this is possible before attempting. Any help would be much appreciated 
here is my YAML code:
substitutions:
name: hptest
friendly_name: Test Heatpump
esphome:
name: ${name}
platform: ESP8266
board: nodemcuv2
# Boards tested: ESP-01S (ESP8266), Wemos D1 Mini (ESP8266); ESP32 Wifi-DevKit2
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
# Note: if upgrading from 1.x releases of esphome-mitsubishiheatpump, be sure
# to remove any old entries from the `libraries` and `includes` section.
#libraries:
# Remove reference to SwiCago/HeatPump
#includes:
# Remove reference to src/esphome-mitsubishiheatpump
captive_portal:
# Enable logging
logger:
# ESP8266 only - disable serial port logging, as the HeatPump component
# needs the sole hardware UART on the ESP8266
baud_rate: 0
# Enable Home Assistant API
api:
ota:
# Enable Web server.
web_server:
port: 80
# Sync time with Home Assistant.
time:
- platform: homeassistant
id: homeassistant_time
# Text sensors with general information.
text_sensor:
# Expose ESPHome version as sensor.
- platform: version
name: ${name} ESPHome Version
# Expose WiFi information as sensors.
- platform: wifi_info
ip_address:
name: ${name} IP
ssid:
name: ${name} SSID
bssid:
name: ${name} BSSID
# Sensors with general information.
sensor:
# Uptime sensor.
- platform: uptime
name: ${name} Uptime
# WiFi Signal sensor.
- platform: wifi_signal
name: ${name} WiFi Signal
update_interval: 60s
external_components:
- source: github://geoffdavis/esphome-mitsubishiheatpump
climate:
- platform: mitsubishi_heatpump
name: "${friendly_name}"
# ESP32 only - change UART0 to UART1 or UART2 and remove the
# logging:baud_rate above to allow the built-in UART0 to function for
# logging.
hardware_uart: UART0the original melcloud controller is also reporting the power consumption, is it also possible with a wemos esp?
It is hard to test every unit for compatibility because there are so many, but generally speaking all units with a CN105 port that are compatible with the Kumo Cloud Wifi adapter from Mitsubishi will also be compatible with the Swicago library and the associated configurations people are using here. In some cases there won’t be 100% functionality, but as far as I can tell, temperature, mode and fan speed are supported with every unit, and things like vane control and compressor frequency being more limited.
The MSY-GExxx series does appear to be supported:
EDIT: Actually it looks like only some submodels are supported by the kumo cloud adapter, and that the GE13VA may not be… Open up the indoor unit control board area - is there a 5 pin port labeled CN105?
yes there is ive installed the geoffdavis/esphome-mitsubishi github onto my esp8266 and manage to get the output
but it doesnt control it, is it because i need to have the air conditioner’s cover and planes on ?
can i ask does ur unit work when the cover or planes are off ?
Hmm, I think mine does work with the doors open, but you could test by setting a mode using the remote.
Your config looks ok, but it doesn’t look like the D1 is receiving communications from the indoor unit. I’d expect you to at least be getting a Current Temp reading in your climate entity, like this:
What do the logs say? Either when you open the ESP device’s IP in the browser directly, or by using the ESPhome addon “Log” button? You should see the unit periodically updating values.
Does anyone know if the mod is compatible with Mitsubishi Ecodan Heatpump system such as a PAC-IF062B-E (Flow Temp Controller)? It has a CN105 port and connecting to Melcloud using a MAC-567IF-E Wi-Fi Card. Thanks
i manage to get it to work in terms of on/off cool/hot and all but it doesnt seem to update status when i use my remote to manually on is there a reason for that?
I’d say it will work. I have two climates with this controller and two with different model (MAC-577IF2-E) and all climates work like a charm, even without level converter. Only difference between 567 and 577 is different connector and power supply: 577 model has 12V available, not 5V, as a result suggested LM1117 gets quite hot, so i replaced it with small switch-mode LM78xx-like model (from aliexpress). I used pull-ups to 3.3V (just in case). As connector goes: i didn’t have one, so i just cut the wires of existing interface😜
I didn’t explore if there’s 5V available on connector of newer climate, since wall is near and it’s hard to see pcb… but it’s smaller red one.
1 Like
Thanks for reply. Good to know.
My main unit is a heat pump controller and not a AC Unit so I might try and research further. I did try and plug in a D1 mini in before… it powered up ok but I could not get any readings off it 
If the Melcloud does not get any better, I might try and have a go again! Thanks
What did you end up doing to get yours to work? My logs look just like yours and there isn’t any indication that communication between my esp8266 and the heat pump is actually happening. It doesn’t receive any data, or turn on the unit.
Just a side note: when updating ESPHome FW it happens quite frequently that i get state=off, but no temperatures shown when module connects for the first time after upgrade. For this i have to reboot module and then it always connect to climate correctly. So, i programmed a routine into ESPHome yaml which checks that and reboots esp by itself.
And, we get “a bonus” with this local module: we can set external temperature sensor as a reference for climate, which is extremly usefull when heating with climate. Better, more accurate.