Hey all, there is so much great info in this thread. I’m getting a couple of ducted air handlers installed in the next few weeks (SVZ-KP units) and looking at my control options. This project seems like fun and it seems like it’ll save a ton of money over the Kumo Cloud the dealer was pushing. I would like the option to have a physical controller for each unit, so I had been considering the PAC units with Nests, but would also consider using the PAR-CT01MAU-SB controller if it would not conflict with this device. The PAR connects with the 2 wire TB15 port on the control board of the air handler. I can’t find any experiences with anyone else on whether these units might work with HA controlling over wifi as well. Any thoughts? Thanks in advance!
I don’t think you can hook a Nest adapter to the Wemos D1’s and have them act as a local passthrough. The newer Kumo adapters do support this function (they have an extra CN105 port on them).
What you could do is install the Nest’s in a dummy thermostat configuration where they think they are controlling an HVAC unit, but it’s actually not wired to anything. Then you use the Nest integration to read the local temp from the Nest and set that as the remote temp for the D1’s control of the indoor unit, and then also track changes in the Nest’s target temp and pass them on through D1 control interface to the indoor unit.
This does require HA to be up and running, but cheaply integrates the Nest into the Mitsubishi system without their adapter, and has the win of sending a true Delta-T value to the heat pump which is more effective than just 2 zones of on/off like the normal adapter does.
I am thinking about doing the same thing in fact…
I’m going to have another crack at this, but use the ESP01 method. I’ve got the wiring diagram, however I would appreciate if anyone has images of there actual setup.
About to start doing this too. I see in OP that a wemos pro was used without any modification. However at post 147 it seemed a resistor from the wemos need to be removed. Is anyway to tell why some needed it cut while op does not need to?
From what I remember, the need to remove the resistor or not has to do with different versions and/or clones of the board. The ones that I used are extremely cheap clones, and it just happened that I didn’t have to modify them at all.
Ended up trying with wroom 32u for the external antenna. I tried a few wemos d1 pro but couldn’t get any to connect to my wifi.
For the wroom32, I am unable to use uart0 for the heat pump. The issue is that if I either set logger baud rate to 0 or set to uart1/2 for logger the esp would not boot. It is able to boot without including the climate component (with baid rate 0 or using uart1/2). The only way to get it to boot is to leave logger as default and use uart2 for heat pump but I am not getting any signal back from heat pump and some older post suggest only uart0 worked for heat pump on esp32.
Probably will end up just using esp01. Will report back
For folks who originally deployed theirs with the mitsubishi mqtt sketch, have any of you tried switching to the esphome driver? @grrr posted about it earlier this year: https://github.com/geoffdavis/esphome-mitsubishiheatpump
I was thinking to try it out. My boards have been very reliable the last 6 months, but needed frequent resets before that… they were randomly losing connectivity to mqtt.
I guess I’m wondering if anyone has a step-by-step to wipe the boards and reflash them for esphome 
I’d rather avoid disassembling all my ACs to go wired again.
I’ve just tried to use an ESP32 and have had no luck with it talking to the AC (it happily ignores it). On connecting a serial console I get ten repetitions of the text below before it goes into fallback mode waiting for new firmware. It’s timing out in the connect function and doing a watchdog reset after a couple of seconds.
Are there any special tricks to get the ESP32 to work?
Are the IO pin drivers different in the ESP32 vs the ESP8266? Or is this possibly a serial port selection bug in the drivers?
I have seen a couple of negative comments in this thread about the ESP32… has anyone at all had it working with UART2? I don’t want to butcher a perfectly good esp32s board to try and use a different UART.
Thanks!
[I][app:029]: Running through setup()...
[I][MitsubishiHeatPump:063]: ESPHome MitsubishiHeatPump version 2.4.0
[C][MitsubishiHeatPump:416]: Setting up UART...
[C][MitsubishiHeatPump:428]: Intializing new HeatPump object.
[C][MitsubishiHeatPump:455]: hw_serial(0x3ffc19c0) is &Serial(0x3ffc19f8)? NO
[C][MitsubishiHeatPump:457]: Calling hp->connect(0x3ffc19c0)
E (10265) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (10265) task_wdt: - loopTask (CPU 1)
E (10265) task_wdt: Tasks currently running:
E (10265) task_wdt: CPU 0: IDLE0
E (10265) task_wdt: CPU 1: IDLE1
E (10265) task_wdt: Aborting.
abort() was called at PC 0x401530ec on core 0
ELF file SHA256: 0000000000000000
Backtrace: 0x4008882c:0x3ffbf840 0x40088aa9:0x3ffbf860 0x401530ec:0x3ffbf880 0x40086f69:0x3ffbf8a0 0x40170c2b:0x3ffbc160 0x401549f7:0x3ffbc180 0x4008b269:0x3ffbc1a0 0x40089aba:0x3ffbc1c0
Rebooting...
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
[I][logger:243]: Log initialized
[C][ota:461]: There have been 10 suspected unsuccessful boot attempts.
[D][esp32.preferences:114]: Saving preferences to flash...
[E][ota:468]: Boot loop detected. Proceeding to safe mode.
Marcus, I can’t help you out with ESP32 as I use the $2 ESP8266’s I mentioned earlier. I know some folks do use the ESP32s successfully, so hopefully someone else can answer. If you look at Geoff’s documentation he specifically mentions specifying a different UART on the ESP32
If it is activating the UART but not communicating, you might need to level shift from 5v to 3.3v. My boards were very forgiving and I didn’t need to do that here, but I did need to do it on the Mr. Cool in my garage. 
But I can answer my own question from yesterday:
Can you go from the gysmo38 custom arduino sketch with a website directly to an ESPHome implementation managed by the official ESPHome Addon, using geoffdavis’s implementation?
Yes. Yes, you can.
From the ESPHome addon, create a new device and set up the configuration. Choose “Install”, then “Manual download” then “Modern format”
Take the bin file that gets built and log into your minisplit’s web browser and choose the “Firmware Upgrade” option and push in the bin file there, wait and watch the magic happen.
If you’re using a version of the custom sketch without the firmware upgrade option, you’re probably out of luck, time to pull out the screwdrivers and usb extension cables.
Here’s my configuration:
substitutions:
name: mrslim-reflashtest
friendly_name: Test Heatpump
esphome:
name: ${name}
esp8266:
board: d1_mini
# Enable logging
logger:
baud_rate: 0
# Enable Home Assistant API
api:
encryption:
key: "privateprivateprivate"
ota:
password: "privateprivateprivate"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: "${friendly_name} Fallback Hotspot"
password: !secret fallback_password
captive_portal:
climate:
- platform: mitsubishi_heatpump
name: "${friendly_name}"
# 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
Guess I have a little tweaking to do… fan and angle modes don’t match from one implementation to the other:
I finally got it to work with the ESP01S and breakout board. Unfortunately with motsubishi2mqtt there is a 3-5 second delay before HA register the state change and it makes it hard to know if a command is accepted without the beeping sound as I have set up controls from other rooms. So back I go to esphome with immediate response.
Initiailly, the ESP01s would not connect to HVAC. The only thing that I had to “make” was the pigtail, where I bought both the JST HA header, terminals and crimps. Just coincidentally, the premade cable I ordered from Aliexpress finally came. I decided to give it a go to swab out the table and that fixed the issue. I did test with multimeter to make sure the cable was good from the CN105 header on the AC to breakout board. So I am not quite sure why it didn’t act as it should. The only thing that I miss from the remote is the confirmatory “beep” sound that is now missing with this set up.
I played around a bit and have the control looking how i want it, using esphome. 100% agree about the mqtt delay making it tough to know if things worked right.
I modified the component to use different names for the fan speed and swing mode so that things show up in the control in the right order and i can adjust the vertical angle (just 2 positions plus auto and swing, instead of all 5 positions), then i used the simple thermostat HACS component to rename things so it looks like this.
Haven’t picked an icon for swing yet…
disadvantage is that under the hood, climate thinks the fan mode is wrong… i used low for quiet, medium for 1, high for 2, focus for 3, and diffuse for 4, because they need to be in the right order, as originally written it showed up low, medium, high, middle, diffuse, which maps to 1, 2, 4, 3, quiet, which is dumb
When I call the climate.turn_on service, it defaults to heat_cool, instead of whatever mode it was before. Currently I have automation to set hvac state based on its previous operating state but I am wondering if this is the expected behavior.
I find this behavior infuriating… i wonder if i disable heat_cool what it will do? It seems to be another home assistant limitation…
EDIT: This is a workaround in homeassistant:
# Fake turn on
for mode in (HVACMode.HEAT_COOL, HVACMode.HEAT, HVACMode.COOL):
if mode not in self.hvac_modes:
continue
await self.async_set_hvac_mode(mode)
break
I think I will just get in the habit of reflashing my esphome modules to only allow the modes that I want to be available that time of year, which will never include HEAT_COOL.
The real solution would be to update the underlying code to have the turn_on attribute, as this is what it looks for: if hasattr(self, "turn_on"):
Regarding the voltage issue on the Wemos D1 mini… I think the ESP8266 operates at 3.3v. However, the board’s input voltage range is 4.5v to 10v. I’m not an expert, but I think these boards should work just fine. If you look at the photos posted by @Skipjack (#10), you’ll see that he connected to 5v pin, not the 3.3v one. This is consistent with what I’ve seen else where (Hacking A Mitsubishi Heat Pump Part 1 - Chris Davis’ Blog).
The board’s uart operates at 3.3v (All of the IO pins run at 3.3V), but as you say the input side of the uart appears forgiving of significantly more. At least the Mitsubishis I have here all are willing to listen to 3.3v as well, so the wemos sending at 3.3v and the Mitsubishi sending at 5v works fine.
I use the same board in a Mr. Cool that also operates at 5v, but on that one it ignores the 3.3v signal and I needed to level shift the Wemos to 5v i/o.
So, I’d say the input range is more like 2.58-5.something
I have automation to set it back to the previous operating mode. It does have a strange behavior where it would then set to the default mode (heat_cool) after a few seconds ocassionally, requiring a second automation check to set it back. This will then stick. This doesn’t happen all the time, maybe 80% of the time, so I can’t figure out why there is this mode switching. This results in a fairly big flow in nodered. I am really leaning towards just flashing it with cool mode only since that is what we use 99% of the time.
I flashed mine with just cool, dry and fan_only and now turn_on does exactly what i want!
I’ll have to decide when to put heat back in there.
I could probably set up automation to flash them with heat, cool, dry, fan_only on september 1, and heat, fan_only on october 1, and then back again in the spring
Found a good solution to the default mode with climate.turn_on. Instead of using climate.turn_on, I now use climate.set_hvac_mode and combining with an input_text helper that retained the last operating setting, I am able to set it to the previous operating mode.
I just got started with Home Assistant so that I could control my heat pumps. I have been trying for several days to get an ESP to communicate with the heat pump without any success. I can get everything looking good in homeassistant, but , I don’t get any communication, TX or RX with the unit. I have tried a clone D1 mini (don’t know the version/variant), as well as a NodeMCU 1.0 ESP8266-12E, and a NodeMCU-32S (ESP32 WROOM). None of them had any glimmer of communication which leads me to believe that there is something else that I am doing wrong. On the D1 I tried it with and without pullups on the tx/rx lines, and I had the 10k pullups to 5V on for the other two boards. I have been trying the standard example scripts one geoffdavis’s site. I have also tried the arduino scripts from the swicago repo (the AP was really hit and miss, but even when I could access it, there wasn’t any communication). Any further troubleshooting thoughts are very welcome.