Mitsubishi Kumo Cloud Integration

Yes, I think I’ve got the same issue with zones as the original KumoJS. My setup is not zoned. Someone made a PR against my repo, but it hits Python exceptions for my non-zoned setup and I requested some other changes as well; that user has not replied to my comments (presumably it’s working for them).

If you can get me an example JSON that gets retrieved from the KumoJS servers for your case (sanitized of usernames/passwords, of course) I’m sure I can adjust the parsing code. Or if you’d like to make a PR that actually works I can take a look.

The other thing you might be hitting is that the KumoCloud servers may have been down. I did my normal upgrade to the latest HA on Saturday morning and Kumo did not come back up. I thought there might be some incompatibility, but no, it’s just that the servers were not working. Long-term it would be nice to add some caching to the Kumo HA component for use in these situations, and possibly also periodic re-polling for folks whose setups change (indoor units getting new DHCP lease, for example).

I’ll add my sanitized non-zoned server config json to the repo for testing purposes. Ideally we’d have unit tests making sure the various variants can be parsed properly.

I’ll get one up as soon as I can. Is the Kumo login service still down for you or is it back?

It’s back. It was only down for about an hour I think. A quick way to check is that the KumoCloud app works on your phone.

Ok, the traceback I posted above was due to me using the wrong password to login (embarrassing). I suppose that is a good test case to capture though.

Once I used the correct password, your component pulled in my top-level non-zoned unit, but did not see the other units in the zone as I suspected.

I have submitted a PR to pykumo with a sanitized version of my config with the zone setup.

Hi Greg,

I’ve pushed code which should support units in zones. I took the opportunity to make some other changes, so you’ll need to pull from the ‘zones’ branch on both repos.

I haven’t made any changes to cache the config for the case where the service is offline. That will require a bit more work.

Please let me know how it goes. If it looks good, I’ll merge these changes back to the mainline.

Hi Doug, I just got around to testing the zones branches out. It picked up all five of my unites, including the 4 in a zone, but the naming of the units seems to be the serial number rather than the “label” element from the configuration file. Here’s what I’m seeing:

My apologies, I didn’t push all the required changes to the https://github.com/dlarrick/hass-kumo/tree/zones repo. Please pull that one again.

1 Like

That looks better!

Thanks, I merged those changes in their respective repos. I also merged the ‘native’ branch of https://github.com/dlarrick/hass-kumo to master since it’s been working well for me for a while now.

That’s great, what do you see as the steps to get this as an official component of HASS?

First step is to submit pykumo to PyPI and adapt hass-kumo to depend on it. Someone who’s dealt with PyPI before could probably do that in about 2 seconds but for me it’s a learning curve. I also want to be reasonably sure pykumo supports any small features I might want to add in, say, the next 6 months. One big one is the capability to cache the KumoCloud server JSON in case of an outage (or if someone wants HA to not talk to that server at all beyond initial setup), and the pieces are in place for that in pykumo.

Second step might be to get hass-kumo set up for something like HACS, though I’ve never used it and haven’t investigated what’s required. I think it’s a lower bar than full-fledged integration, but would allow people to install, test, and give feedback more easily.

Final step is to get all the ducks in a row to create a PR to the HomeAssistant Github. Again, someone who’s done this before would be a big help. One area where an interested but motivated non-programmer could help is documentation in the style and quality of the existing official HA docs; this is definitely a requirement to get a PR accepted. But this component is simple enough – and perhaps as importantly, is a non-cloud integration, philosophically aligned with HomeAssistant’s principles – that I think in principle it should be accepted.

Hey @parkercat !
This worked great! Let me know how I can help get it into HA/submitted to PyPi.

Hey all, I’ve pushed a new version of pykumo and the hass component to their respective repos. The change here is that it caches the config JSON retrieved from the KumoCloud servers locally, in case the service is down (as happened to me a couple times recently).

There’s also an option to always prefer the locally-cached file (if present), which will speed up startup a bit, and avoid HomeAssistant talking to KumoCloud at all after the initial setup. This comes at the cost of not picking up configuration changes to your account. Note that this config information includes the indoor units’ names and IP addresses, so if you use this option and those change (even including the indoor units getting a different DHCP lease), you’ll want to delete the cached file. If this sounds good to you, add:

prefer_cache: True

to your configuration.yaml alongside your kumo username and password.

I am in the process of going through the steps on PyPI and I will update here.

In the meantime, one piece I know we’ll need is some documentation. If someone’s interested in taking that on, I’ve made a Issue on GitHub and discussion & coordination should occur there: Need documentation for Home Assistant · Issue #5 · dlarrick/hass-kumo · GitHub

-Doug

1 Like

All right! The PyPI piece was relatively straightforward. I have pushed a new version that uses the published pykumo to the hass-kumo Git repo. To migrate over:
1.Remove any vestiges of pykumo from your site-packages directory. Note: you should only need to do this if you’ve been following along since the beginning.
2. Remove the custom_components/kumo/ directory including its subdirectories
3. Fetch a new hass-kumo from https://github.com/dlarrick/hass-kumo and put the ‘kumo’ directory from there in place of the old one in your custom_components directory.
4. Restart Home Assistant as usual. It will go out and fetch the appropriate pykumo from PyPI and you should be on your way.

Please report any issues here.

I followed steps 2, 3, and 4 and things appear to generally be working as it relates to using the PyPi code.

I am having a minor issue with the fan mode - my mini splits seem to turn on and then close the vanes without blowing any air. Any thoughts on what the issue might be?

When you say “fan mode” – you mean you choose “Operation Mode” selector to be “Fan Only”, but the indoor unit briefly does something then turns off? There’s code that’s supposed to prevent you from selecting modes your unit doesn’t support – can the KumoCloud app successfully put it into Fan Only? Or am I not understanding correctly?

In the ‘kumo_cache.json’ file that’s in your .homeassistant directory, look for the “reportedProfile” section for one of your units. What does it say for “has_ventiliation_function”? One of mine looks like this:

                       "reportedProfile": {
                            "fan_speed_stages": 5,
                            "has_air_direction": true,
                            "has_auto_fan_speed": true,
                            "has_dry_function": true,
                            "has_extended_temp_range": true,
                            "has_heat_function": true,
                            "has_swing_direction": true,
                            "has_test_run": false,
                            "has_unit_function_setting": false,
                            "has_ventilation_function": true,
                            "maximum_auto_temp": 31,
                            "maximum_cool_or_dry_temp": 31,
                            "maximum_heat_temp": 31,
                            "minimum_auto_temp": 16,
                            "minimum_cool_or_dry_temp": 16,
                            "minimum_heat_temp": 10
                        },

If your has_ventilation_function is true my next suggestion would be to capture the conversation between HA and your unit that causes it to shut down, and compare it to the one from KumoCloud app that works. Easiest is if you can follow the packet capture instructions up-thread.

It might be a little bit before I get to the packet capture part…

Here’s my profile:

                    "reportedProfile": {
                        "fan_speed_stages": 5,
                        "has_air_direction": true,
                        "has_auto_fan_speed": true,
                        "has_dry_function": true,
                        "has_extended_temp_range": true,
                        "has_heat_function": true,
                        "has_swing_direction": true,
                        "has_test_run": false,
                        "has_unit_function_setting": false,
                        "has_ventilation_function": true,
                        "maximum_auto_temp": 31,
                        "maximum_cool_or_dry_temp": 31,
                        "maximum_heat_temp": 31,
                        "minimum_auto_temp": 16,
                        "minimum_cool_or_dry_temp": 16,
                        "minimum_heat_temp": 10
                    }

It looks like it’s there. When I look at the status in my HA website, it states: “Idle (Fan Only)”. I don’t seem to be able to take it out of Idle…

If you put the unit into fan-only mode with the KumoCloud app, does it behave differently? Does HA show anything different once you’ve done that? (give it a minute or two to poll for status)

You know what - the issue is on my side. There’s some interesting behavior (going into idle) between using the heater and then switching to fan mode that is apparently part of the way the machine is designed (it goes into that idle mode in both the Kumo app and HA plugin).

Thanks for the support - your plugin works really well! Hopefully this gets picked up as a native integration at some point.