HVAC Modes incorrectly detected

[tmchow]

One of my units does not have it's HVAC modes correctly detected. In HA it's showing as only cooling and off:

hvac_modes:
  - 'off'
  - cool
min_temp: 45
max_temp: 95
fan_modes:
  - superQuiet
  - quiet
  - low
  - powerful
  - superPowerful
current_temperature: 70
temperature: 68
fan_mode: auto
hvac_action: heating
filter_dirty: true
defrost: false
friendly_name: Main
supported_features: 9

The unit definitely supports more modes than that. What's weird is that heat is missing, but hvac_action=heating which clearly shows it's in heating mode.

This is my kumo cloud app which shows that all the modes are supported (and work if I use the app):

And because of this, I end up in situation where I can only choose from cool or off in modes:

If it helps, I'm also seeing in logs, a bunch of errors for that specific unit:

Timeout issuing request http://192.168.1.145/api: HTTPConnectionPool(host='192.168.1.145', port=80): Max retries exceeded with url: /api?m=0e4855223b459efc64277b00666d714356d6a51128769f7dadaf6ccd6af4f67e (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7f3ec2323e90>, 'Connection to 192.168.1.145 timed out. (connect timeout=0.5)'))
Error retrieving profile
Timeout issuing request http://192.168.1.145/api: HTTPConnectionPool(host='192.168.1.145', port=80): Max retries exceeded with url: /api?m=70d72f9d651a0a65ff7d170901585eaf123d1282eef491520a32f25fd59db957 (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7f3ec1d2c950>, 'Connection to 192.168.1.145 timed out. (connect timeout=0.5)'))
Error retrieving adapter profile

Error retrieving sensors
Timeout issuing request http://192.168.1.145/api: HTTPConnectionPool(host='192.168.1.145', port=80): Max retries exceeded with url: /api?m=0e4855223b459efc64277b00666d714356d6a51128769f7dadaf6ccd6af4f67e (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7f3ec0803ed0>, 'Connection to 192.168.1.145 timed out. (connect timeout=0.5)'))
Error retrieving profile
Timeout issuing request http://192.168.1.145/api: HTTPConnectionPool(host='192.168.1.145', port=80): Max retries exceeded with url: /api?m=70d72f9d651a0a65ff7d170901585eaf123d1282eef491520a32f25fd59db957 (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7f3ec0755b10>, 'Connection to 192.168.1.145 timed out. (connect timeout=0.5)'))
Error retrieving adapter profile

[dlarrick]

Interesting. It's possible your unit returns a profile that the code doesn't parse correctly. How are your Python skills? Could you fire up an interactive Python shell and issue some commands?

For the timeouts, you can set the "connect_timeout" value in your configuration.yaml to a higher value. You might give it 5.0 (5 seconds) (which is huge, 10x the default value) and see if that makes the messages go away.

[tmchow]

I’m fairly technical but don’t know python. But can figure out how to get the terminal up to issue commands. So fire away.

I will try upping the timeout and see what happens.

[tmchow]

Interestingly I changed it to 1.0 and the errors seem to have gone away completely and now all hVAC modes show up.

I wonder if 1.0 or higher should be default?

[dlarrick]

Aha! I suspect your WiFi is somewhat poor in that location. For me, I get occasional timeouts at 0.8 seconds but retry usually succeeds. I guess we can't complain given the minimal compute power on these adapters but that's fairly ridiculous. I'll plan to bump up the default on the next release.

[tmchow]

One other thing I noticed, which may be timeout related, is that if I make changes to the target temp I don’t see it reflected accurately in both side.

That is, if I change it in kumo cloud app from 70 to 69F, and go to HA app, the thermostat card says it’s 70F still. If I refresh both the Ha app and kumo cloud app they don’t match.

Same thing happens Vice versa: change in Ha then go to kumo cloud.

What is the refresh delay? What could be causing this?

[dlarrick]

Yes, that's expected. Both HA and the Kumo app are polling because the unit's own API is pretty simple and doesn't support any sort of push.

My code considers any data newer than 5 seconds "fresh" to avoid overtaxing the unit's API (see "minimal compute power") and that's compounded by whatever HA's refresh interval is for climate components. I'm sure the Kumo app also polls at an interval. HA does update its own state when it drives a change, so that part feels quicker. It's just the cross-app updates.

My advice: keep the Kumo app around only for debug purposes (and the magic installer-only settings). But I guess I'm biased.

[dlarrick]

I increased the default connect timeout to 1.2 seconds and also decreased the "freshness" threshold to 2 seconds since I reworked the API calls that do polling. Can we close this Issue?

[tmchow]

I increased the default connect timeout to 1.2 seconds and also decreased the "freshness" threshold to 2 seconds since I reworked the API calls that do polling. Can we close this Issue?

I was getting timeouts at 1.0, then I tried 2.0 and still getting them. I increased to 2.5 to see how it’s doing.

But we can close this issue and revisit if I still have issue.

[dlarrick]

The "Retrying" messages are not a big deal so long as they're not followed by a "Timeout issuing request" message. It tries a total of 3 times each poll, if needed. Even the "Timeout" are not a big deal if they're occasional. But if you see those consistently I'd check into the WiFi signal strength near your indoor unit, perhaps reposition the adapter inside -- it's got a tiny little antenna. You could even leave it dangling by its cord for a while (pending spousal approval) to see if that helps. I also wonder if running HA and the Kumo app at the same time might overtax the poor little thing.