Mitsubishi AC with Wemos D1 Mini Pro

Was a typo.

My question was how to implement the code that the esp to use the temperature from a pin input instead of the unit, but not through ha or mqtt, , I am looking that the esp to handle it on its own

Not sure what your aim is here.

I found what I was looking in the original post see post # 190 https://nicegear.nz/blog/hacking-a-mitsubishi-heat-pump-air-conditioner/

You can get temperature form any sensor and send it over with the setRemoteTemperature function

Just a warning, this is likely to break in 0.96 as there are breaking changes for the climate component.

I have the very same problem.
I believe that the configuration is correct.
The D1 mini correctly connects to the wifi. I think that the error is in the configuration of the custom component or in the custom component itself, but I am not able to fix it

This is my configuration:

climate:
  - platform: melcloud
    email: !secret melcloud_mail
    password: !secret melcloud_pw

  - platform: mitsubishi_mqtt
    name: "condizionatore_salotto"
    command_topic: "condizionatore_salotto/set"
    temperature_state_topic: "condizionatore_salotto/status"
    state_topic: "condizionatore_salotto"

this is the error that I get:

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 365, in _async_add_entity
    await entity.async_update_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 225, in async_update_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 248, in _async_write_ha_state
    state = self.state
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 192, in state
    if self.current_operation:
  File "/config/custom_components/mitsubishi_mqtt/climate.py", line 173, in current_operation
    return me_to_ha[self._current_operation]
KeyError: None

Confirmed with the update to version 0.96 has stopped working

Update breaking change for 0.96 is now on the GitHub page :+1:

1 Like

There is an alternative way to integrate pointed out to me on gitter by @kmdm - you can use MQTT and avoid the custom component aspect for the Mitsubishi heatpump. See https://gist.github.com/kmdm/29f740e5f36036fb23daba8f2109c359

I’ve done this and it works reliably. The only thing I had to do was change the sketch to interface with MQTT in Fahrenheit units (I’m in the US) since the MQTT climate interface reports whatever is sent in the serial protocol. If you use Celsius, no sketch change is necessary.

1 Like

Thanks for this post. I was able to strip it down to get it working with just one heat pump. It was nice to get rid of the custom component that appears to breaking with HA version changes.

I just saw this thread today.
The sketch SwiCargo wrote was not designed for Home Assistant, he uses his own system for automations. The MQTT works flawlessly though. All the configuration is done in the accompanying mitsubishi_heatpump_mqtt_esp8266_esp32.h file that should load in the Arduino IDE along side the sketch. Both should be in the same folder.
The Custom Component integration likely wont be updated any longer and as far as I know it will only work with HA versions 0.96.x in its current format. I know a few alternatives are around, or at least being worked on, to use native components, some more reliable than others.
The sketch itself is really rock solid. It only dies when the power dies.
Be aware of one thing. Mitsubishi units use TTL, which means 5V logic. This may work for a time with ESP8266 chips, but Espressif specifically have stated that ESP8266 Chips are not 5Volt tolerant. From my experience, I had it working and it worked for 6 months then both ESP8266 chips died so my advice is to use a logic shifter or protection resistors on the Tx and Rx lines.
I ended up using ESP-01 and the little ESP-01 adaptor used to connect them to 5Volt arduino boards. Works well and havent had the failure issue.
These little break out boards have the logic shifter and power regulators on board so they make a neat little package. SwiCargo’s github suggests using them as well from memory.
Anyway, just my little bit of input.

1 Like

@Tomdoc
You won’t need to use the Melcloud integration if you use SwiCargo’s sketch.
It is all local via MQTT. Melcloud is only for if you use the Mitsubishi genuine WiFi control box. Using an ESP8266 is totally local and used via MQTT only.

Just additional: If you check https://github.com/SwiCago/HeatPump/issues/138 (issue 138) there is some work on a full modification for auto-discovery happening.

If you look at the gitter conversation pointed to somewhere on swicago’s GitHub there is conversation about alternative implementations. However I found it a little difficult to follow. Worth a look though.

1 Like

That might be a similar conversation as in that “issue” that I posted actually.
It is confusing at the moment and I am sticking to HA 0.96.x and the custom component until it becomes clearer. For me, there is nothing extra in 0.97 that would warrant an immediate upgrade :slight_smile:.

I can see why kmdm’s yaml is confusing. He is using scripting to use less yaml to control 3 heatpump units. If you only have one, it would be a lot simpler than that.

Edit: Yes it is basically same conversation. @unixko started the work and @kmdm is also working on things. The fork from @unixko looks good as it seems to have the full integration in his “native” solution, meaning full auto-discovery via MQTT and it will show up in the Integrations section of HA. It does still seem to have a couple of glitches though

1 Like

Hey all,

I’ve been holding off upgrading Hass.io since the breaking change, but finally got around to it today. Thanks @kmdm for the code and @yang3535 for updating the thread. I have multiple units and so I didn’t strip it down (I implemented as-is), and it’s working fine. One observation after getting this into MQTT - I noticed that when I tap on the icon to send the instruction to the A/C unit (turn off, on, etc), the A/C unit will immediately respond, but the ‘state’ information in my browser / app will take 5+ seconds to update. It’s particularly noticeable because prior to the breaking chance, the state would also immediately update. I’m not a MQTT (or any form of) guru - any thoughts on how to make that happen quicker?

@brendan mentioned he had been using ESP8266 chips on 5V for 6 months before they died. I’ve had 4 x A/C units using this setup for six months with issues yet, but I’ll let you know if they die.

I still need to do the conversion from C to F. Not sure how to do that yet, but it’s the next project.

One final question - is anyone using a different card - something different to the generic Lovelace thermostat card? Keen to hear it if you think there’s something better.

Skip.

Hello, I am really excited to start this new project, I have done a lot of research but before I buy the components I need, cab anybody clarify which components are better:

  • For the connectors, is it a JST PAP-05V-S ? with 2mm between pins?
  • For the board, is the WEMO Mini 3v better or the ESP8266 5v?
    Thanks

I finally got it working without the component, using the kmdm “https://gist.github.com/kmdm/29f740e5f36036fb23daba8f2109c359
I only have an issue: the on command does not work, although if I click the hot or cold, the a/c goes to on. All other buttons work fine and I can turn it off, any suggestion?

I’ve just installed https://github.com/unixko/MitsuCon (built on top of the SwiCago library) and they share the same “feature”. “On” is not a command that can be used to turn the unit on to it’s last state. You need to specify one of the modes to turn it on.

Thank you Michal, I suspected that much… :slight_smile:

In your opinion, is Unixko better than the kmdmi use?