[PROPOSAL] Kumo Emulation Mode

[KazWolfe]

It seems likely that users would use this project as a replacement to a Kumo Cloud unit, seeing as any integration created by the community would likely be (a) cheaper, (b) better, and (c) more supported. As such, it would be nice if the library could provide other Kumo-related comfort features, including:

• Dual setpoints in auto mode
• Blocking the MHK2 from creating schedules
• Humidity/Battery Reporting

To that end, the project will need some ability to emulate a Kumo Cloud device.

Detecting a Kumo Cloud

Kumo Emulation Mode should not operate fully when an actual Kumo Cloud is connected. As such, it is imperative that Kumo Emulation Mode only be active when an MHK2 is connected and no upstream Kumo is found.

To detect the presence of an MHK2, we only need to check for an Identify packet coming from the configured thermostat UART.

To detect the presence of a Kumo Cloud, we need to forward the identify packet to the upstream device. If the device responds with a 0x61 response, we know that there's an upstream Kumo device and that we should not attempt to replicate all features, or make certain behavioral choices (e.g. resolving auto mode requests). In this mode we will likely need to forward most packets as-is, but some changes may be necessary to handle things like passing the aforementioned dual set-point on for resolution.

If a Kumo Cloud is not detected, then we have free reign to emulate one fully and handle any such responsibilities accordingly.

[Sammy1Am]

I think to keep things from getting too complex too quickly, feature sets like this can be broken down into two groups:

• Always-on features (stuff supported by the ESP no matter what)
• Interactions with other devices (Kumo / MHK2)

And when possible, keep the second group as passive interactions.

Relatedly, there are the four basic hardware setups that I can think of (in increasing order of complexity):
A) Heat pump <-> ESP
B) Heat pump <-> ESP <-> MHK2
C) Heat pump <-> Kumo <-> ESP <-> MHK2
D) Heat pump <-> ESP <-> Kumo <-> MHK2

---

In setup A, we can implement any features like dual setpoint directly into the ESP code; I think this should be the starting point since, as you said, the goal here is to provide a cheaper, better Kumo, rather than.... "enhance?" existing Kumos.

Setup B seems fairly likely as well, since having a "dumb" wall thermostat is probably common and provides a ready-made physical interface for the system. For this scenario, the goal is to emulate a Kumo just enough to convince the MHK2 to give up extra information (like humidity / battery reporting), and give it useful information (like a timestamp maybe if that's helpful?).

I question the usefulness of including a Kumo in the chain at all: what does it bring to the table that isn't already provided by the ESP/MHK combo?

Setups C and D don't actually require any significant logic changes as we can just leech off the passing packets between the Kumo and MHK2 in setup C, and just act like a normal heat pump in D (though to do this automatically would require determining if the Kumo also sends an identify packet, and what it does if it thinks there's another
Kumo upstream).

If a user needs some Kumo functionality not supported by the ESP, it should still work as long as our default behavior is to just transparently forward packets.

tl;dr: I think focusing on setups A and B should significantly reduce the complexity of the ESP logic, and C and D should still basically work as long as we're forwarding packets by default. And rather than trying to cover all the edge cases (e.g. what if someone makes a schedule on the MHK2 and in Home Assistant) I think as long as nothing breaks in those cases, we just let whatever interactions happen, and write guidance in the README. Again, for example, the schedule in the MHK2 would still work via the ESP, and if there was also a schedule in HA, that would also happen; nothing's broken, that's just exactly the behavior the user asked for.

[KazWolfe]

This makes enough sense, Setup A and B seem to be by far the most common. Setup C we can at least detect and shove the ESP into passive mode, though I have a feeling that depending on how this project develops we could do some interesting (though probably not-worth-supporting) things.

I suppose a lot of this will just come with building out the feature set at least, but maybe worth keeping things in mind.

[paravoid]

@KazWolfe wasn't the PR for this merged a while ago? Is there anything left to do here?

[KazWolfe]

This isn't fully enabled yet since there's still quite a bit we don't know about the Kumo protocol, but I am happy enough to close it. Resolved in #30.