Merge upstream?

[paravoid]

I think it'd be useful for the long-term maintenace of the component, to submit it for inclusion in the main ESPHome repository.

There are currently multiple components for the same functionality in the wild (see geoffdavis/esphome-mitsubishiheatpump#131). I believe all them forks of geoffdavis' work, but with various small or larger changes from it. This one seems to be the most promising: the most recently active, stable, uses ESPHome's UART, and has the fewest dependencies.

From experience, I can say that the landscape is confusing for someone that is just starting to look at connecting their devices: lots of forks that are hard to compare with each other, subtly different configuration snippets for each, French error messages, hardware incompatibilies (see my comment in #85), documentation that is lacking including the necessary hardware. If you contrast it with e.g. the equivalent Midea code, where it's upstream and super straightforward: https://esphome.io/components/climate/midea.html

I think doing the last 10% of work on this fork to clean it up (incl. the aforementioned French messages 😀), write an esphome-docs snippet, and submit it, would do wonders. I realize you're a volunteer and I'm asking you to do a bunch of extra work -- I'm saying this with a lot of respect for your work and appreciation for all the work you've done already! I'm willing to help if possible.

[paravoid]

Coincidentally, someone submitted esphome/esphome#6794 today, proposing a mitsubishi_uart component. From a first look, it doesn't look to be based on this code at all.

[echavet]

I will test it as soon as it is available. The project seems to support communication with a thermostat.
it looks very good:

• Supports adding additional ESPHome sensors as remote temperature sources
• Support for software UART
• Support for connecting a thermostat / Kumo Cloud to a second UART port (MHK2 (and probably 1) supported)
• Parity with above mentioned libraries for features (pretty much there)

https://github.com/Sammy1Am/mitsubishi-uart?tab=readme-ov-file

[Sammy1Am]

Hello there!

Someone mentioned this project over on the PR and I stopped by and saw this issue.

From a first look, it doesn't look to be based on this code at all.

Indeed, I started from scratch on mitsubishi_uart back at the beginning of 2023, so it's a separate attempt to provide support in ESPHome. Of course I was able to leverage the knowledge from the other projects, but wanted to collect all the protocol knowledge in one place and tried to gather it into a wiki (which @KazWolfe has massively expanded and organized here ).

I don't know how long the ESPHome PR process will take (this is my first one), so you're always welcome to test it out sooner using external_components.

external_components:
  - source: github://muart-group/esphome@dev
    components: [ mitsubishi_uart ]

uart:
  - id: hp_uart
    baud_rate: 2400  # Note: May be 9600 on some systems!
    parity: EVEN
    rx_pin:
      number: GPIO3
    tx_pin:
      number: GPIO1

mitsubishi_uart:
  heatpump_uart: hp_uart

I'm happy to answer any questions (you can always open issues over on the project page too of course).

I haven't had a chance to dig very deep, but it looks like this project has at least a couple features not yet in mitsubishi_uart, so hopefully those can also be rolled into ESPHome eventually as well.

[echavet]

Hello there!

Someone mentioned this project over on the PR and I stopped by and saw this issue.

From a first look, it doesn't look to be based on this code at all.

Indeed, I started from scratch on mitsubishi_uart back at the beginning of 2023, so it's a separate attempt to provide support in ESPHome. Of course I was able to leverage the knowledge from the other projects, but wanted to collect all the protocol knowledge in one place and tried to gather it into a wiki (which @KazWolfe has massively expanded and organized here ).

I don't know how long the ESPHome PR process will take (this is my first one), so you're always welcome to test it out sooner using external_components.

external_components:
  - source: github://muart-group/esphome@dev
    components: [ mitsubishi_uart ]

uart:
  - id: hp_uart
    baud_rate: 2400  # Note: May be 9600 on some systems!
    parity: EVEN
    rx_pin:
      number: GPIO3
    tx_pin:
      number: GPIO1

mitsubishi_uart:
  heatpump_uart: hp_uart

I'm happy to answer any questions (you can always open issues over on the project page too of course).

I haven't had a chance to dig very deep, but it looks like this project has at least a couple features not yet in mitsubishi_uart, so hopefully those can also be rolled into ESPHome eventually as well.

Thank you for your message.

[disruptivepatternmaterial]

@Sammy1Am I have tailed hours of data from the kumo adapters I have and dumped a lot of it on the wiki pages for this project. I am a newcomer to this effort and would not presume to have any strong opinion on this other to say the broader community solving problems and making this work easily is what it is all about!!! So in case it is not obvious feel free to take a look at those data and see if it is helpful.

That said, I am the person who created the first (one of the first) ways to control these devices in node-red with home bridge back maybe 6-7 years ago, I forget and that code and repo are long gone. I am also the person who did all the original work to decode the Balboa Spa hex protocol that people used to make those. I mention this because I am an avid reverse enerinereer of these protocols but others are better at keeping up with the latest frameworks and tools...

The thing I have been spending a lot of time on an kind of had to take a break from because it was making my head hurt is the difference between AUTO and HEAT/COOL in this context. What I have been able to find is that AUTO enables the auto feature of the unit, which is a 4C swing and the units do a great job managing the switch over from heat to cool and all that.

So I was trying to figure out if I could change the 4C range to maybe 10C which would be much more desirable for my use case here in the Pacific Northwest where we can have pretty big temperature swings, but I dont need the house to be so narrowly dialed in to a 4C range - and to not waste energy - I'd really like to make it 8C even 10C.

Because I was not able to find that 4C as a setting, I then started to work on enabling the dual set point mode and handle that in the code running on the ESP32. I am 99.5% certain that is how it works on the kumo adapter. The unit is managing AUTO, but it has no way to do HEAT/COOL so it HAS to be in the adapter. But I got stuck in trying to understand how to work with HA/ESPHome to switch back and forth from a single to dual set point mode. It just kept not working...

So for me, the main goal of where to take all this is:

• esphome make it easy because lots of people want this to work :)
• implement AUTO AND HEAT/COOL and maybe even dry mode, which is also handled in the adapter, BTW
• see if there is anyway to dig into the settings which appear to be unit specific (or much more unit specific than the rest)

Over the weekend I tried to log iSee info from my iSee units using my hacked adapter and Saleae Logic Analyzer and just need to find time to pull out the important parts. All I think I am seeing is enable/disable but much more at this point. It would be interesting to see the data it is collecting...but that is maybe we more than most people need / want!

Side note I kind of love that a group of determined "amateurs" is doing better at this than a gigantic multinational company like Mitsubishi. They should be embarrassed at how bad their adapters are...

[KazWolfe]

@disruptivepatternmaterial: If you're interested, I think we'd really welcome your presence over in the mUART Discord. I suspect there's some good information you've found (e.g. iSee toggle) that I'd like to get documented in the mUART wiki and possibly add as a feature.

Re AUTO: Yep, you're correct, that's managed completely by the head unit. There is, however, an exception to this rule. If an MHK2 is connected (and I suspect Kumo, actually), it will "steal" the auto mode and perform its own dual-setpoint logic on-chip. I'm currently unsure how the MHK2/Kumo interact with dual setpoint control, but right now it seems like the MHK2 is what actually drives it.

[disruptivepatternmaterial]

@KazWolfe yeah given how embarrassing the kumo adapter is I refused to spend money on the MHK2 in my home. I don't need more frustrating junk and personally I dont like things on the walls people can mess with...it is my experience that so many people do not understand how thermostats work so they crank them up, waste energy, and then complain it is hot and open windows...so nope not in my house! HAHAHA

So what you said above. I have started to do some probing on what the kumo adapter is doing and what I do is change setting in the UI or using the remote (ir) and then hit the kumo to get the JSON of the settings. I have never seen anything in that JSON that tells me that the kumo adapter is able to change the built in 4C spread. But it does obscure the built in AUTO, which I think means I agree with what you are seeing - but there is some language here that might be confusing people: It says AUTO in the kumo, but it is NOT the fixed setpoint (4C) AUTO, it is a dual set point called AUTO. IMHO, ideally, we'd implement both because, well HA can handle it, and it makes sense. In all my automations I put the units in fixed-4C-point-AUTO when the temps outside are in a certain range. Maybe I am one of the few...but the thing is that units are so smart about controlling multi-head conflicts and such.

I'll try to poke over at discord, but signal, whatsapp, messages, slack, etc... I just have limited cognitive load for yet another place to check for messages. I miss IRC! HAHA!

[paravoid]

Closing in favor of @Sammy1Am & @KazWolfe's mUART work & upstream PR :)