-
Notifications
You must be signed in to change notification settings - Fork 23
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
Comments
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:
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. |
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 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 |
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
ofidle
. This, however, does not appear to actually be set and the system will perpetually report itself with anhvac_action
ofheat
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
ofidle
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 inauto
mode but not actively calling for heat (autoHeat
) or cool (autoCool
) - although it doesn't appear like the API will ever returnauto
. Theidle
state will also be set if the API reports thatr["indoorUnit"]["status"]["standby"]
istrue
, 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?
The text was updated successfully, but these errors were encountered: