MHK1 settings changes not passing through to heat pump

[sle118]

There seems to be an issue with passing through settings requests from the thermostat and I am not sure if this is a bug or a new feature for which I am missing a bit of configuration. The issue is here:

esphome/esphome/components/mitsubishi_itp/mitsubishi_itp-packetprocessing.cpp

Line 248 in 5751221

void MitsubishiUART::process_packet(const SettingsSetRequestPacket &packet) {

Where the code is as follow

void MitsubishiUART::process_packet(const SettingsSetRequestPacket &packet) {
  ESP_LOGV(TAG, "Passing through inbound %s", packet.to_string().c_str());

  // forward this packet as-is; we're just intercepting to log.
  alert_listeners_(packet);
}

when other packet types have the following line:

route_packet_(packet);

which routes the packet instead of passing it to (in this case) inexistant listeners.

Am I supposed to enable enhanced mhk mode, and if so, does it support the mhk1 ?

[Sammy1Am]

I'll take a look, but I think you're correct that route_packet_(packet) should be included there as with other similar packets. Fairly sure I tested this as working at some point, so I must have accidentally removed the line during some changes at some point.

[sle118]

I was scratching my head, going over the python code generator piece and the cpp code to figure out if there was a listener somewhere that might have routed the packet, but I could not find any so I'm not crazy after all 😅

For now I went with the following

void MitsubishiUART::process_packet(const SettingsSetRequestPacket &packet) {
  ESP_LOGV(TAG, "Passing through inbound %s", packet.to_string().c_str());

  // forward this packet as-is; we're just intercepting to log.
  route_packet_(packet) ;
  alert_listeners_(packet);
}

And the MHK1 is able to control the heat pump again.

What's on the roadmap for this project, aside from being officially merged into esphome?

[Sammy1Am]

Awesome! If you wouldn't mind submitting a PR I'll get that merged ASAP; that looks like the correct change. (The comment even says it's forwarding the packet, but it's clearly not. If I had to guess I'd say it used to be only route_packet, but I needed to alert a listener somewhere and I replaced the line instead of adding it. Regardless, thanks for catching this!)

I've sort of given up on getting merged into ESPHome anytime soon. There's been no traction on the PR other than them initially saying they wanted a smaller PR, but after I shrunk it down there's been nothing.

Roadmap-wise there's not really anything planned from me. There's some small improvements (like preferences handling mentioned in #60), but for the most part because everything's been working great at my house I don't have any big pressing features to work on. @KazWolfe has a few unfinished goals with the Enhanced MHK mode I think, but as-is it's been stable in my experience so that's not pressing either.

Long-term there's been talk of:

• Breaking out the serial communications/packet handling into its own library. Either Mitsubishi-specific, or as a generic serial-packet-handling library for ESPHome with Mitsubishi-extensions.
• Support for Ecodan units (same basic protocol, but different enough messaging that stuff would need to be added).
• The 2-wire protocol seems to have a lot of potential, but it's a lot less accessible and less is known about it. This would prooobably end up as a separate library/component anyway.

[sle118]

Haven't had a chance to test yet. If anyone confirms it works, we can close this.

Thank you!