Async API

[robarnold]

I'm seeing some timeouts trying to talk to my kumo devices via HomeAssistant and I realized from the logs that the full set of retries is taking over 10 seconds on one of the sync worker threads. I'm not sure how much this affects other threads due to the GIL but I'm wondering if it's worth providing an async API and using that in the HA integration. Is this something you're open to building or taking PRs for?

[dlarrick]

At this point I'm not sure it's worth the effort, honestly.

The ongoing issues with the stability of the indoor units' local API is not a good sign. Mitsubishi doesn't seem to care that its adapters randomly stop responding and require a power cycle.

Trying to adapt to this situation -- by making more, smaller requests -- seems to have helped somewhat. But it's also the cause of the slowness you're seeing, especially if the indoor unit has less than excellent WiFi signal.

If it gets much worse, I (and others, I'm sure) am much more likely to switch to a homebrewed ESP32 based solution than to expend heroic effort on continued workarounds.

[cjkrolak]

@robarnold can you elaborate with a traceback and test sequence that triggers your error? I'm not sure I've seen this error case yet (knock on wood), I'm not an HA user.

[robarnold]

@cjkrolak I don't have a more precise sequence as I think this is just HA doing its normal periodic polling, but here is a recent sample. It's a mixture of timeouts and refused connections for a unit that is particularly far (maybe 25ft) from an access point but I've seen it for a few other units. I have 6 units in this network, so this issue can compound if they all get cranky around the same time.

@dlarrick, I haven't had to power cycle anything yet aside from some initial setup woes but that wouldn't surprise me if it comes to it. I'm hoping the move to async would be easier on developers and users than a move to ESP32, but I've never done a conversion before.