Mitsubishi Kumo Cloud Integration

I think you have a bad (or unreadable? permissions?) copy of your kumo_cache.json which it can’t get data from, so then it tries to read from the server but doesn’t have a URL in that codepath. That’s clearly a bug, but the more relevant question is why can’t it read from the cache?

What’s more, I think it’s having trouble contacting the KumoCloud servers. Either they’re down (all too common unfortunately, and the reason for the kumo_cache.json), or your username/password is not right, or there’s some other reason for it.

Next time I’m making changes I’ll try to make these error paths more resilient, but (assuming my remote clairvoyant debugging skills are correct) even if my code were perfect here all it could do is not hang but not create climate units either.

I have tried uninstalling and re-installing a couple of times, with or without the kumo_cache.json file present same result every time.

I think (armchair quaterback) there should be a check for the kumo_cache.json and if its not there re create it.

For now Ill be messing around with some chmod etc.

Eejit that I am I changed 2 things, so cant pin it down to a single one.

I changed prefer cache to “true” and did a brute force chmod 777 on kumo_cache.json

That brought it back.

After changing prefer_cache to false again it overwrote the kumo_cache.json and its still working.

So my assumption is that the script kumo uses didnt have access to the json, which is weird but I aint a unix guy…

EDIT - Further testing revealed that simply switching prefer_cache back and forth does the trick as well.

Prefer_cache will insulate you against KumoCloud outages on HA restarts, but requires that your network won’t reassign indoor unit IP addresses. It’s also a different codepath, of course.

I suspect the real problem was ownership/permissions of the cache file and I can certainly beef up error reporting in that area. I’ve made an Issue on GitHub to remind me.

@KaiserKai I’ve pushed an update which should have better error handling and logging around loading the server config (from server or from cache).
@omriasta this version also adds a pretty quick timeout when talking to the indoor units, so an offline or unreachable unit should not cause HomeAssistant hangs. If people are seeing timeouts in normal operation I’ll have to make it configurable.

I also added a battery_level attribute to the climate component, if an indoor unit has a remote sensor. You can turn this into an actual battery level sensor with a template sensor like

sensor:
  - platform: template
      loft_kumo_battery:
        value_template: '{{ states.climate.loft.attributes["battery_level"] | float }}'
        unit_of_measurement: '%'
        device_class: battery

Hey all,

Kumo has been merged into the default store list in the HACS store. See https://github.com/hacs/integration for how to set up HACS in your Home Assistant, then search for “Kumo” in integrations.

For support / debugging, please continue to post in this thread. If you find a legitimate bug, feel free to create an issue on GitHub.

It’s been an interesting project for the last 9 months or so, and I’m glad others are finding it useful. I don’t have any immediate plans for improvements, though I’m sure some ideas will come up.

1 Like

Awesome, there was no action necessary, HACS automatically recognized and cleared my prior custom repository.

1 Like

The issue with empty setpoints being displayed has been fixed by HomeAssistant as of 0.106. No other updates from me; everything seems to be working fine. Carry on.

Something blew up for me - Not working for a few days now. Have tried all kinds of config changes.

It tells me “Connection Refused” - Across all my Units. Sample below.
Nothing has changed in my config, password etc all the same.

2020-03-08 21:18:08 WARNING (MainThread) [pykumo.pykumo] Error issuing request http://192.168.1.10/api: HTTPConnectionPool(host=‘192.168.1.10’, port=80): Max retries exceeded with url: /api?m=8cf708e5e3d1ce3aa40722f4b294a822c7acc772f32986b99bb44bff0b45f083 (Caused by NewConnectionError(’<urllib3.connection.HTTPConnection object at 0x7f7be0aed0>: Failed to establish a new connection: [Errno 111] Connection refused’))

Most likely, your units have either lost WiFi connection to your router, or have been assigned new DHCP leases.

I’d say either move the kumo_cache.json out of the way or temporarily turn off prefer_cache, and restart.

Got it working again.

It was the counterintuitive option of deleting kumo_cache.json and having prefer cache = true

I had this happen before, next time I’ll know :slight_smile:

Thanks Again

Hey all,

Novice here… please excuse my ignorance. I’ve installed kumo using HACS and added the following to my configuration.yaml. When I restart, I get the error further below:

kumo:
  username: !secret kumo_username
  password: !secret kumo_password
  prefer_cache: false

Invalid config

The following integrations and platforms could not be set up:

  • kumo

Please check your config.

I’ve checked my username/password and my HACS and kumo install went through without a hitch… until, of course, the restart. Your help is greatly appreciated!

I think I fixed the issue…

There was a “]” in my original password. I changed my password to remove the “]” and it seems to have done the trick.

Thanks for the hard work.

I was trying to assign the different thermostats to their appropriate areas. Apparently, only devices can be assigned to an area. All of the Kumo stuff shows up in entities only. Would it be possible to update this so that we Kumo can be recognized as a device?

From what I can tell, you only get a Device if your Entity supports Config Flow, i.e. configuration via UI. While I’d like to do this I don’t have the time currently. There’s a partial PR on GitHub that does some of the work but it’s incomplete.

Understood. Is this something you’d want to track in Github?

Thanks again for all the work you’ve put it on this thing.

You’re welcome to create an issue if it will help you track it. Not necessary from my end.

I have had issues a lot when restarting my ROuter and thus potentially new IP adresses being assigned.

I always tinkered and tried within the settings of the component, but it turned out I simply needed to use the Kumo Cloud app once, assume it refreshes the IP addresses internally which can then be drawn upon by the component.
Drove me crazy but this seemingly works every time now.

Maybe useful information for others here.

Thanks for this tip. Opening Kumo Cloud app does seem to help bring a hard-to-reach indoor unit back online. I wonder what it’s doing?

I would highly recommend using a static (persistent) DHCP lease for your indoor units. Many routers offer this option buried somewhere in their settings.

Hey, I installed from HACS and it went well. I’m stuck though on the initialization. In the custom component folder, I found the kumo_cloud_setup.py file and I ran that manually to see what it would produce and it looks like the JSON that I get back from the Kumo Cloud server does not contain an address for a unit that is in a zone (I’ve started testing with just 1 unit named Master bed). Output below:

climate:

  • platform: kumo
    name: “Master bed”
    Traceback (most recent call last):
    File “kumo_cloud_setup.py”, line 38, in
    main()
    File “kumo_cloud_setup.py”, line 33, in main
    print(’ address: “%s”’ % zone[‘address’])
    KeyError: ‘address’

Where have I gone wrong here?