Kumo http-80 interface failures

[kris2k2]

There seems to be a bug in the connection handling with the Kumo controller, that causes the port-80 HTTP interface on the controller to slow down, and eventually become un responsive to any HTTP commands.

I've noticed the degradation come in two symptoms:

1. Increase in delay in setting-up the TCP socket, before being able to accept + respond HTTP client requests (suggesting, an accumulation of sockets on the controller, due to unclean shutdown by the consuming client) 2.The TCP socket opens in a timely manner (less than 500ms), ready to respond HTTP client requests, but fails to respond to any HTTP verb (all input IO is ignored).

As a result, while my controller is confirmed behaving like symptom-2 today (I used netcat to confirm, and also the Kumo mobile app to confirm that the split still responds to commands from Kumo Cloud), in the debug process, I decided to clean-up my Kumo installation from HASS, reboot, re-install, and rebind using the UI.

What I got was:

1. Hass-kumo was able to connect to Kumo cloud (and obtain the kumo_cache.json)
2. Hass-kumo was able to identify my ductless split system, and prompt me to enter the IP address (which I provided)
3. Hass-kumo created the Device entity, the wifi strength entity, but nothing else.
4. Hass-kumo reported failure after 2 hours with the following. `Logger: homeassistant.config_entries Source: custom_components/kumo/init.py:97 Integration: Kumo (documentation) First occurred: 1:49:28 PM (1 occurrences) Last logged: 1:49:28 PM

Error setting up entry kristopher@lalletti.ca for kumo Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/config_entries.py", line 339, in async_setup result = await component.async_setup_entry(hass, self) File "/config/custom_components/kumo/init.py", line 97, in async_setup_entry pykumos = await hass.async_add_executor_job(account.make_pykumos, timeouts, True) File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 58, in run result = self.fn(*self.args, **self.kwargs) File "/usr/local/lib/python3.9/site-packages/pykumo/py_kumo_cloud_account.py", line 237, in make_pykumos pk.update_status() File "/usr/local/lib/python3.9/site-packages/pykumo/py_kumo.py", line 36, in update_status response = self._request(query) File "/usr/local/lib/python3.9/site-packages/pykumo/py_kumo_base.py", line 67, in _request url = "http://" + self._address + "/api" TypeError: can only concatenate str (not "NoneType") to str`

What I get from this is that we may be looking at a couple of bugs from this experience:

1. The Mitsubishi Kumo controller might need a kernel tune to reduce its TCP socket timeout wait time, to solve resource contention issues when there have been too many connections.
2. The Hass-Kumo package may be acting a little too aggressively against the controller (I have yet to measure the frequency) which was designed to only serve the random mobile calls.
3. The PyKumo package is not closing the HTTP connections in a clean fashion, causing sockets to linger on the Kumo controller for 15 minutes (assuming RFC) and causing the resource starvation issue on the controller.
4. Hass-Kumo is designed to use Cloud when its not able to communicate directly; no? I think there may be a possible regression in the logic handling for direct-versus-cloud-versus-fallback.

Beyond that, amazing work for this project! I'm going to try to reach-out to the Mitsubishi Kumo cloud product team to see what we can do about bug-1, if there's anything I can do to help on the other points, let me know.

[dlarrick]

Gonna separate out my replies into different topics.

The WiFi and TCP/IP stack on the WiFi interface definitely has some issues. For a lot of people (including myself), on occasion the units are reachable from some parts of the network (some hosts) but not others. Power cycling the unit (circuit breaker :( ) or the WiFi AP it's connected to clears it up; for me at least, so does waiting.

It is, however, pretty impressive that the whole indoor unit (including the adapter) draws only a couple of watts when idle. So we're dealing with some not-very-capable hardware and I'm glad it works as well as it does. I think it's unlikely to actually be running any recognizable OS; it's just a microcontroller with about as much capability as an Arduino.

The more common issue people see, though, is simply WiFi signal strength or interference. That's why I added the WiFi RSSI attribute. My 3 units are currently at -49, -57, and -39 dB and generally work great. I suspect the timeouts you see on a connected socket are WiFi quality related.

[dlarrick]

Re: your failure to set up after a reinstall, please see the IP Addresses section of the README. Having to enter your IP addresses is a symptom of the indoor unit not being synced to KumoCloud; we discovered this method of forcing a sync after having implemented entering IPs as a workaround.

[dlarrick]

And for your last comment: No, the pykumo library uses KumoCloud web service only to find the units and gain access (credentials). All status and control communication is local; there is no fallback to the cloud.

[dlarrick]

Closing some old tickets. This one is more of a support-type issue, not a problem with the integration itself.