search

dlarrick / hass-kumo

Home Assistant module interfacing with Mitsubishi mini-split units
MIT License
98 stars 21 forks source link

"Idle" State Appears Nonexistent #126

Open KazWolfe opened 11 months ago

KazWolfe commented 11 months ago

Full disclaimer: I'm very aware that the Kumo Cloud API may not even expose this information to end users for any purpose. This may very well be a rant post against the API, but I'm also hoping someone may know something that I don't.

After an air handler reaches the target setpoint, I'd expect Home Assistant to report that the system has a current hvac_action of idle. This, however, does not appear to actually be set and the system will perpetually report itself with an hvac_action of heat until the setting is manually changed. This makes it difficult to track what state the air handler is actually in, meaning some automations do not have enough information to decide what is going on.

It may be possible to derive an hvac_action of idle if the current temperature is above (or below) the appropriate setpoint, but this is guesswork at best and may not actually be indicative of what the heater is actually doing. For example, my own observations seem to show that the heater continues to run at a low fan speed even at the setpoint. For posterity I do have the Thermal Off setting set to Extra Low in Heat, which may be throwing off my observations.

Per a quick read of the code, it looks like the idle state is set when the system is in auto mode but not actively calling for heat (autoHeat) or cool (autoCool) - although it doesn't appear like the API will ever return auto. The idle state will also be set if the API reports that r["indoorUnit"]["status"]["standby"] is true, but I'm not certain under what conditions this field is set.

Is there something in the API I'm missing to extract current device state?

dlarrick commented 11 months ago

Pedantic note: the Kumo integration gets its data directly from the indoor unit. The only reason it communicates with the Kumo Cloud API at all is to gain the address and credentials required for local communication.

See also: https://github.com/dlarrick/pykumo/issues/7

The operational status in the unit's API leaves much to be desired. It would be useful to know things such as:

But I have never been able to find a difference in the payload returned by the indoor unit to provide any of this information. There is an "operation" LED on my indoor units that seems to come on when the unit is doing significant work, but again, I don't see this reflected in the API status.

I would love to be proved wrong here. Pull requests or technical discussion (over at the pykumo repo, please) would be welcomed.

Alternatively, it would be possible to do as you suggest, and have the integration manufacture an "Idle" state if the current temperature satisfies the setpoint(s). I would consider a PR for such a change.

KazWolfe commented 11 months ago

Alternatively, it would be possible to do as you suggest, and have the integration manufacture an "Idle" state if the current temperature satisfies the setpoint(s). I would consider a PR for such a change.

I would have considered making such a change, but the extra-low fan mode makes this a tad annoying. I'm not sure if that should be reported as fan or not. Part of me thinks "yes" because the fan is actually running, but another part disagrees because the fan is running at such a low speed to not really be meaningful. Not to mention the fact that the air still feels warm, which I suspect is just leftover heat, but it still adds a layer of confusion that would be resolved if the HVAC API just told us what the HVAC was actually doing...

As an aside in general, is there anywhere you're collecting random tidbits of API-related findings or information? There's a few things like r["mhk2"]["connected"]["thermostatBattery"] that might be interesting to track. (Or the fact that even with an MHK2 connected, the API can call for/set auto mode even though the app claims that this is impossible.)