Kumo Emulation Mode

[KazWolfe]

Caution

This code is not production ready. Certain values are hardcoded to observed states with no knowledge on what those hardcoded values actually mean or do.

This code has only been tested with two specific units (MSZ-FS06NA and SVZ-KP30NA) on MHK2 firmware version 01.00.01.

As such, I have included a disabled-by-default flag to the config to explicitly enable this mode for interested users.

This pull request aims to add Kumo emulation support to the mUART stack, and expose some Kumo specific information.

• Send appropriate responses to A? packets sent by an MHK. Slot in known data when we have it.
• Process and expose certain data from the MHK units.
  • Adds sync for low/high setpoints (even though this does nothing for now)
  • Add humidity and battery state sensors for the thermostat.
• Add a requirement for a time source if an MHK is connected.
  • Required for time syncing between ESP and MHK. I don't want to deal with edge cases with invalid time.
• Fix the thermostat hello decoder, which had endianness issues.

This PR still needs:

• Additional documentation on what certain fields do (or setting them to zero if safe)
• (Possibly) Some way to expose the model/serial/version info
• More RE work to try to catch extra fields.

If desired, we can strip out all the sensors/set functionality and stub everything out for just protocol level support. This would make MHK mode effectively transparent, though I suspect we'd still need to report some parameters.

[Sammy1Am]

I think this is the case, but just want to clarify: the goal with this PR is to convince the MHK2 that it's connected to a Kumo (and thereby squeeze some extra functionality out of it) not emulate the upstream behavior of a Kumo, right? I.e. this should only be changing how we communicate with thermostats, rather than changing behavior of the ESP itself.

[KazWolfe]

Broadly speaking, yes. There are certain things that I'm running into that will require behavioral changes to the library to some degree, but I'm still trying to evaluate what they are and how they work (with priority being given to "make everything work from the user perspective as it did before").

For example, there's some oddity with setpoints now where the MHK and Home Assistant will seemingly disagree, since the setpoint fields in packets 0xA8 and 0xA9 seem to have additional meaning and we need to track what's being sent to the MHK. This is especially obvious when using auto mode, since the MHK still attempts to claim control unexpectedly, leading it to somehow desynchronize with itself.

At present, this entire branch should be treated as proof-of-concept and more of an experimental reverse engineering project than it is a proper proposal.

[Sammy1Am]

Minor naming things mostly.

[Sammy1Am]

Other than that one change, looks great. Going to flash it on one of my controllers now.

Could you also please run the ESPHome linting/formatting scripts so this doesn't immediately break the CI tests over on the PR?

(I don't fully understand how the tests are meant to be run, unfortunately. script/fulltest will run all of them though. It'll suggest changes to files in other components, just ignore/discard those.)

[Sammy1Am]

Needs time added to AUTO_LOAD, but also with a new understanding of what DEPENDCIES are, probably:

AUTO_LOAD = [
    "climate",
    "select",
    "sensor",
    "binary_sensor",
    "button",
    "text_sensor",
    "time",
]
DEPENDENCIES = [
    "uart",
    "climate",
]

[Sammy1Am]

Testing CI