Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Idle" State Appears Nonexistent #126

Open
KazWolfe opened this issue Nov 5, 2023 · 2 comments
Open

"Idle" State Appears Nonexistent #126

KazWolfe opened this issue Nov 5, 2023 · 2 comments

Comments

@KazWolfe
Copy link

KazWolfe commented Nov 5, 2023

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
Copy link
Owner

dlarrick commented Nov 5, 2023

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: dlarrick/pykumo#7

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

  • fan speed in Auto fan mode
  • vane direction in Auto vane mode
  • whether heating or cooling (or neither) in Heat/Cool mode
  • whether calling for cooling / heating from the outdoor unit
  • if so, what stage / how many BTUs / what percent of full capacity

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
Copy link
Author

KazWolfe commented Nov 5, 2023

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants