If I were you I’d look at what they’re called in the “Swing” menu on the HA climate card for this indoor unit, and try those (capitalization maybe important, exact spelling definitely important). Or try small numbers if that doesn’t work.
1 Like
Oh I hadn’t thought of that. I will try now. I checked the climate widget and sure enough it has terms like Horizontal, etc. for swing mode - I will try and report back!
Indeed, the ‘ceiling’ vent setting in the Kumo app itself corresponds to the HA Kumo setting swing mode = “Horizontal” which I found, curious. 
But let’s see if the automation works now, I’ll report back!
Thank you!!
Sadly, I feel defeated. I saw the list of options for swing mode in climate like you suggested. I tried them. None of them correspond to moving the vent angle simply up or down. I don’t know what to do. 
Stupid question: can you get the vanes pointed how you want by choosing different swing options from the climate card? Under the hood, the card is calling the same climate.set_swing_mode service call that your automation should be doing.
Hello all - just confirming. Does my HA have to be on the same network as my mini-splits? I would like to remotely monitor them with my HA like I do with the app. I’ve downloaded and tried to configure the integration but I get an “unknown” error during the initialization which never completes.
I plan on putting in a 2nd HA at this remote location eventually but would love to monitor these units now.
Thanks for your input.
Hello all,
I have two Mitsubishi MSZ-FS indoor units and I am looking at getting Kumo Cloud adapters from Mitsu and using the Kumo Cloud Integration for HA.
The critical question for me is - can you put the unit into “Smart Set” mode? Smart Set allows the minimum temp to be 50 degrees F. That is critical for me as I use the units to heat my shop and I only need to keep it at 50. Or can you just set the min temp to be 50?
I’d appreciate any insights!
I see a few mentions of creating a separate VLAN. Anyone happen to be using unifi here and be able to give some basic instructions on how to set this up?
In the app itself you can set the max heat to 50 if that helps.
I decided to try an old Logitech Harmony I had sitting around. This worked perfectly. I had to teach the Harmony the IR commands for the Mitsubishi, but that was simple as I only need to turn “Smart Set” on and off.
Unexpectedly the Mitsubishi Remote has a single button for “Smart Set” but it actually sends a discrete on and off command. This makes the on and off from the Harmony determinant.
It works perfectly for me.
You can buy a Harmony Hub very cheaply. In currently see them on eBay for $29.
Hi all,
I work at Enode, a Norwegian start-up building digital infrastructure for connecting and optimizing control of energy devices. We currently have integrations with EVs, EV chargers, HVACs, inverters, and home batteries, and are looking to expand our list of supported HVAC brands. We are therefore looking for owners of a Kumo Cloud account that are willing to participate in our testing program for compensation. See more details here.
Some help if you please as I can’t get my Mitsubishi heat pump to show up.
-Statically assigned IP, can see & control it in the Kumo Cloud app, even Alexa’s plugin works, so we know the adapter is up on and accessible. Installed from HACS, but here is where I get stuck and never see the device or entity:
- When prompted, enter your KumoCloud username (email address) and password. <<Entered
- You can also enable the
prefer_cachesetting in this dialog. See details below. <<did this, but notice it never sets the “address”: “192.168.0.127”, in the kumo_cache.json, but even when I do I still don’t get my device to show up. - Click Submit to enable the integration and begin device discovery. << I submit, it says success, I click finish, but now begin discovery? What discovery?
- Once discovery is complete: <<What discovery? I’ve waited, rebooted, reinstalled, and don’t see a device, entity, or climate entry at all. I don’t get any of these prompts the instructions say I will.
- You’ll be prompted to assign a room (Area in Home Assistant terminology) for all discovered devices. << Nope, wasn’t prompted.
- You might be prompted to assign IP addresses for devices where Kumo didn’t receive an IP address from the KumoCloud service. See details below. <<Nope, wasn’t prompted, but as mentioned in #2 I did add this and no difference.
In notifications I did get an Invalid Config for kumo.climate and kumo.sensor. Log shows this:
Logger: homeassistant.setup
Source: setup.py:291
First occurred: 10:57:38 PM (2 occurrences)
Last logged: 10:57:38 PM
Unable to prepare setup for platform kumo.climate: Platform not found (cannot import name ‘HVACAction’ from ‘homeassistant.components.climate.const’ (/usr/src/homeassistant/homeassistant/components/climate/const.py)).
Unable to prepare setup for platform kumo.sensor: Platform not found (cannot import name ‘UnitOfTemperature’ from ‘homeassistant.const’ (/usr/src/homeassistant/homeassistant/const.py)).
Any help would be greatly appreciated. Thanks.
Update: Posted on the GitHub as an issue and problem was recent versions incompatible with my older version of Home Assistant (I do have valid reasons). Manually installed version 2.8 as that was released around the time of the Home Assistant version I have and it works.
Observations from the Mitsubishi Kumo Cloud service event on Friday April 12th around 5:45 pm EDT
Sometime after 5:45pm EDT I started to notice that my Kumo devices in HA started to oscillated between Unknown and Unavailable. While not uncommon given the general WiFi flakieness of the devices, the simultaneous occurrence of it was odd, and it didn’t seem to be recovering on its own. I went through a full HVAC system power cycle, and that having not fixed the problem, I also rebooted all of my access points, even though I wasn’t seeing any other Wifi issues.
The devices were not staying on the network. They were not responding to pings for the most part, seeming to come up for 20-30 seconds every few minutes but for the most part were offline. At this point, I checked Downdetector and saw the problem reports for Kumo Cloud. Also checked with a couple of people I know who have it who also confirmed their systems were offline in the app (unfortunately don’t know anyone else doing local access via HA or Homebridge).
Now, fearing the worst, did Mitsubishi just pushed out a software update that bricked all the devices? I started looking at active flows from the devices to hosts on the internet from my firewall. It looked like they were resolving the hostname geo-rev2-b.kumocloud.com. On a lark, I put in a firewall rule blocking all outbound connectivity from the Kumo devices to TCP/80 and 443. Within five minutes, all of the devices were back online, pingable, and communicating with Home Assistant reliably.
My suspicion is that whatever event was happening at Mitsu was causing the devices to get caught in an infinite reboot loop. Blocking them from communicating with Mitsu’s cloud service seems to avoid whatever the trigger was.
Some other observations from my investigation:
-
The Kumo Cloud devices appear to make DNS queries to hard coded Google DNS (8.8.8.8) bypassing local DNS configuration. Using DNSBL lists will then not be an effective technique for blocking their outbound communication. You’ll need to block it on the firewall.
-
The endpoint that the device is trying to communicate with geo-rev2-b.kumocloud.com resolves to AWS EC2 IP addresses in us-west-2. The DNS responses wee rotating through multiple sets of 4 IPs, so I suspect hat this might be a CLB/ALB where the IPs will be dynamic and change as the ELB scales in and out or replaces nodes. Therefore, Firewall rules can’t block on IP address. For this event, I just blocked all outbound TCP 80/443 traffic from the Kumos.
-
The endpoint is serving up a self-signed certificate (not uncommon for IoT applications), but with an expiration date of May 7, 2045. Assuming Mitsubishi has no mechanism to update the trust stores on these devices, we now know that built-in drop-dead date for them. I’m not too worried about my HVAC system, let alone the controllers, lasting that long…
-
During the event, the units that were on appeared to be cycling every couple of minutes. Two of the units were heating the room when the MHK2 thermostat was several degrees above the setpoint. I’ve seen this behavior before where connectivity is temporarily lost with the MHK2 and the unit switches to the internal temperature sensor. Given that the MHK2 receiver is connected via the Wifi module, I think this supports the theory that the device was caught in a reboot loop during the event.
I’m strongly considering leaving this firewall rule in place and see if it improves my overall system reliability. I have no need for Kumo app based control. My only concern is allowing the units to continue to sync their clocks (not needed for schedules as that is all done through HA, but to keep the clock on the MHK2 updated). Hopefully, that uses standard NTP as I’m only blocking HTTP/HTTPS traffic currently.
Hopefully this is helpful to anyone else who observed the outage as well.
I am curious to here from folks that are preventing their Kumo devices from reaching the internet, how is that working out for you? What specifically are you blocking?
1 Like
Is there an easy way to find the IP of my kumo cloud devices?
Check with your router, there’s almost always an interface for displaying the DHCP clients and their IP address assignments.
If you can’t get it from your router, you’re probably looking at something like Fing or another network scanning app.
In my situation, the issue was the 2.4 GHz network was not passing data over to my standard IOT network. I set up firewall rules to pass traffic, restarted the router and poof, here I am nearly another year later and finally have everything working as expected. I understand that KUMO uses the 2.4 GHz network because it has a better range, but they should put in decent enough technology to auto-negotiate the correct band when both are being broadcasted OR just use the other bands available when the range is not an issue.
I just got minisplits installed last week and have been trying to connect them to a 2.4 only network on my unifi dm se. I keep getting a “server-error” when clicking to connect and I’m trying to diagnose if it’s on my end or Kumo Clouds. I know there was an outage last weekend because I saw it on Reddit. Anybody know if Kumo Clouds servers are back up? Whether you’re able to connect through the app?
Have been using the integration for years. However, I upgraded HA from 2024.6 to 2024.7, and the Kumo integration from 0.3.10 to 0.3.13, and am now getting timeouts and my devices are showing unavailable.
3 Kumo devices. Static IP. I can ping the devices successfully. I use ‘prefer cache’ and have extended timeouts.
I removed and reinstalled the repository. I removed and reinstalled HACS.
Not sure where to look next.
Logger: homeassistant.components.climate
Source: helpers/entity_platform.py:1031
integration: Climate (documentation, issues)
First occurred: 9:03:27 AM (9 occurrences)
Last logged: 9:59:27 AM
Updating kumo climate took longer than the scheduled update interval 0:01:00
Logger: urllib3.connectionpool
Source: /usr/local/lib/python3.12/site-packages/urllib3/connectionpool.py:826
First occurred: 8:54:52 AM (5310 occurrences)
Last logged: 10:04:59 AM
Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7fb73bd05280>, 'Connection to 10.0.2.201 timed out. (connect timeout=1.2)')': /api?m=a7ece08dcd39ee79d5aefa385edf5b53cbd74bcbb5bc56bd87a5dd9a9efc0fdb
Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7fb73be27aa0>, 'Connection to 10.0.2.202 timed out. (connect timeout=1.2)')': /api?m=25283ba1180d1347e895e2e62afc66821674cedeed992c60eb13cbcbbdaf1344
Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7fb73bce4980>, 'Connection to 10.0.2.201 timed out. (connect timeout=1.2)')': /api?m=a7ece08dcd39ee79d5aefa385edf5b53cbd74bcbb5bc56bd87a5dd9a9efc0fdb
Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7fb73bce4e60>, 'Connection to 10.0.2.202 timed out. (connect timeout=1.2)')': /api?m=25283ba1180d1347e895e2e62afc66821674cedeed992c60eb13cbcbbdaf1344
Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7fb73bce5af0>, 'Connection to 10.0.2.201 timed out. (connect timeout=1.2)')': /api?m=a7ece08dcd39ee79d5aefa385edf5b53cbd74bcbb5bc56bd87a5dd9a9efc0fdb
What logs should I attach?
Solved. Used VirtualEnv to test the APIs. Did a reboot of one of the WiFi modules. Alll 3 modules started responding and the integration started working.
I have been using HA and the Kumo Cloud Integration for several years with pretty good results – like others, I experience occasional WiFi problems. I have had four mini-split heat pumps.
This week we installed two new Mitsubishi mini-split heat pumps (bringing the total to 6) and new Kumo Cloud WiFi boards.
We could not set up the WiFi boards with my older iphone-8 but we were able to set them up on Kumo Cloud with my wife’s iphone-13. With my router I assigned fixed ip addresses to the new heat pumps as I have with the other four.
Yesterday I attempted to add these two new Kumo Cloud devices to my HA integration. I ended up deleting the Kumo integration and adding it from scratch. I did not need to provide the ip addresses for the four older heat pumps but did have to supply them for the new ones, bed1 and bed2.
I now have six devices in my Kumo integration, but none of the entities are available for the two new heat pumps.
I have tried re-loading HA and re-booting HA with no change.
This is the log entry.
This error originated from a custom integration.
Logger: custom_components.kumo.coordinator
Source: helpers/update_coordinator.py:386
integration: Kumo (documentation, issues)
First occurred: 6:54:35 AM (2 occurrences)
Last logged: 6:54:37 AM
Error fetching kumo_3934P008D100124F data: Failed to update Kumo device: Bed1
Error fetching kumo_3734P008K100441F data: Failed to update Kumo device: Bed2
Running kumo cloud on my old iphone I don’t even see the two new heat pumps, but they do show up and are controllable in the Kumo Cloud app on my wife’s iphone-13 and on my newer ipad.
I am wondering if changes to Kumo Cloud protocols are at work here that are not supported by older code?
I have no idea what to do.
Hi,
Not sure if this info helps at all… but thought I would post in case by some wild chance this helps someone.
I’ve had middling success with the WF-1 and WF-2 adapters for years. I’ve tried everything from static IPs, different subnets, different networks, isolated HA instance and even a dedicated network with its own WAN connection. Regardless of what I do, my Kumo Cloud integration with HA seemed to work randomly. Sometimes it would go for weeks and sometimes hours - sometimes requiring a power cycle to fix and sometimes fixing itself.
But the last thing that seems to have worked is to not expose any entity beyond what the integration exposes by default. Previously, I exposed the wireless strength and some other hidden attributes to see if there was a drop in signal strength when I lost my Kumo Cloud connection (there wasn’t). In fact, I could even successfully ping the adapter even though the integration was “Unavailable”
However, now with just the default settings (and not doing anything else), my Kumo Cloud has been as reliable as it’s ever been. In fact, I’m running it on my normal LAN mixing with my usual home traffic and it’s still working well.
So not sure if it was just in my case, but zero customization on the climate entity has (at least for me) seemed to solve my problem.