Actual status of this component and the forks out in the wild

[Bascht74]

In addition to this great original, several forks have now made it into the wild. I have compiled a list of the versions I have found and why they exist:

A.) https://github.com/wrouesnel/esphome-mitsubishiheatpump

@wrouesnel has made the following extensions:

1. packet logger (set VERBOSE logging, this will tell you if you have your serial port settings right)
2. fix crash on fan mode change (simple printf format problem) (see also: https://github.com/geoffdavis/esphome-mitsubishiheatpump/pull/122)
3. horizonal and vertical vane select entity, allows you to select the different modes for the vane. (see also: https://github.com/geoffdavis/esphome-mitsubishiheatpump/pull/109)
4. rx-pin and tx-pin are customizable on ESP32 (I need this, so I use this version)
5. better implementation for external temperature sensors (e.g. via Bluetooth, Home Assistant) remote_temperature_operating_timeout_minutes, remote_temperature_idle_timeout_minutes, remote_temperature_ping_timeout_minutes Disadvantage: Uses older version of SwiCago/HeatPump (from August 2022)

B.) https://github.com/echavet/MitsubishiCN105ESPHome

@echavet has made the following enhancements: He removed all delays from the esphome loop. That prevent data loss and component lag.

Why: the swicago lib does not fit the esphome requirements: The lib requires a delay each time a packet is written so as the read process only starts when it is sure the response packet is complete, and it can read it in a single loop. Like it is done in the Firmata project the main loop must always read packets from the input UART and write when needed. This way, we don't loose packet, and the component matches the esphome requirements (no delay). Disadvantage: It is the first version which has not entirely been tested. The adapted library is directly integrated in the code.

C.) https://github.com/dark-nico/esphome-mitsubishiheatpump

@dark-nico has made the following enhancements:

1. Activate the external update (sadly fixed setting, not as an esphome yaml option)
2. Bumped the library to the last version. Why: He spent some time diving the code and the library code and found what is causing the following issue https://github.com/geoffdavis/esphome-mitsubishiheatpump/issues/112 (Target temperature can go crazy)

It would be helpfull if someone could merge these different extensions/improvements together of if @geoffdavis allows some people to do the merges of those pull requests as he doesn't have much free time right now (understandable).

BTW:
I'm currently using it with an M5-Atom Lite, only with the GROVE cable. I cut the plastic of on end of the GROVE Cable and insert the extracted pins into a JST PAP-05V-S housing... -> cable can go directly to the Lite and on the other side into the CN105-Port.

I am really thankful that I don't need to use the Mitsubishi cloud integration (so slow, extra APP). Togehter with an https://esphome.io/components/sensor/xiaomi_ble#mho-c401 (18 Euro on Amazon, set with two) this is unbeatable! So thx everybody again for the great work!

Sebastian

[geoffdavis]

Sebastian,

Thanks for putting this list together. I can't remember if the develop branch has the remapable tx/rx pins or not. I haven't done a release because a default changed in one of the pull requests and I haven't had a chance to back it out. It's been so long (and this now month long cold has eaten so many brain cells) that I don't recall what the blocker is. (EDIT: blocker is GH-109)

With echavet's modified event loop, it might be worth trying to get this merged into the mainline ESPHome code base, as many folks have requested (see GH-5).

[phidauex]

Thanks for compiling the list, there have been some good improvements out there but we are a bit scattered. I'm assuming the temp timeout additions to @wrouesnel's fork are from this pull request from @donutsoft? https://github.com/geoffdavis/esphome-mitsubishiheatpump/pull/98

Just wanted to give credit where due / make sure we don't have two versions of that same enhancement floating around. I see that as the most valuable change right now because it provides critical redundancy in case the external temperature sensing is being used, but the sensor source (Home Assistant) stops updating.

I'm not very experienced with this, but is there anything that we can help with in terms of organizing the changes or rebasing the code? Even an intermediate release that included a few of these improvements would be a nice touch for folks while the more complex changes get worked on (swicago library, event loop changes, etc.).

[Bascht74]

@phidauex probably the pull request. I might have missed that because I found it in the documentation of @wrouesnel fork. Sorry about that.

[disruptivepatternmaterial]

This is very helpful because I was started to get confused! It looks like some of this is in the develop brach, but I am finding a lot of compile errors in that branch and just started to fix them and realized I am likely replicating work others have done...I am well aware we are all doing on in our free time (it is Saturday morning here, so muffin in hand...I'm fixing compilation errors HAHA) but is there some idea of a plan to beat this into shape? How can I help? I see a lot of issues being opened for things that are not related to the project specifically, even just closing those or something might help...

[disruptivepatternmaterial]

So I've gone ahead and put the @wrouesnel version in use. I am not sure I understand why it is implemented as h/v swing when the most common swing is vertical, but hey it works so so so much better than the embarrassing Mitsubishi ones. Randomly I am not curious what the other 3 connectors do on the stock wifi devices...seems they can be used for something. Anyhow, I just wanted to report to anyone who comes here I have MSZ-GL units (5) and they like the 2400 baud. I have one unit with iSee, going to see what I can figure out there and share...

[Bascht74]

you should give this component a try: https://github.com/echavet/MitsubishiCN105ESPHome

I switched to it and right now a lot of advantages... (some minor things are still missing, but it is much faster and stable for me) It might support ESP8266 and ESP32, Arduino and ESF-IDF as well as the standard UART from ESPHome...

[Bascht74]

External sensors are working as well...

sensor:
- platform: pvvx_mithermometer
mac_address: "A4:C1:38:XX:XX:XX"
temperature:
name: Thermometer
id: temperature
device_class: temperature
state_class: measurement
filters:
throttle_average: 90s
on_value:
then:
- lambda: 'id(hp).set_remote_temperature(x);'

You can find information about it here: https://github.com/echavet/MitsubishiCN105ESPHome/blob/fa3dbdc0755fd5bdde8ab6d803b0650e515987c7/esp32-test.yaml#L45

[Bascht74]

Right now I can say that all my needs are now fulfilled with the integration from @echavet here: https://github.com/echavet/MitsubishiCN105ESPHome

The only things missing are supporting the config of both vanes and a strategym if external sensors fail. He said he will implement these in a future version. Big plus is the support for ESP-IDF if you are using external bluetooth temp sensors...