Mitsubishi Kumo Cloud Integration

Feature Requests
428

The Kumo adapters have some serious weak sauce WiFi code in them. They can be reliable however. They really don’t like to see a lot of network traffic, and that causes them to drop off the network, usually coming back shortly after.

What I did to fix this was to put them on their own vlan, with SSDP and other multicast filtering on. This means they don’t see the usual chatter on the home LAN. I have a separate IOT SSID and vlan, but that wasn’t good enough, I had to put them on their own subnet with multicast off and seperated from all my other IOT devices that needed muticast. They don’t need to be on their own SSID, but if you put them and a separate SSID and still hook them to your main subnet, that won’t fix the problem.

Eventually I want to replace them with ESP32’s running GitHub - akamali/mhk1_mqtt: Control Mitsubishi heat pump over the CN105 port using MHK1 and MQTT which is a fork of the normal SwiCago code that enables it to sit in the middle between an MHK1 and the heat pump (just like the Kumo), and allow the MHK1 to override the program running, which has a lot higher WAF than just removing the MHK1 and depending on HA commands.

3 Likes
429

Thanks for the detailed instructions. I’ll try to give this a shot and hopefully it will help. I like the Kumo Adapter so will try to make it work.

430

One quick question since I’m definitely not a networking person…. Right now, I’m just using a dedicated 2.4 GHz Wi-Fi router for the Kumo and it’s working better. But if I create a separate VLAN just for the Kumo so that the Kumo’s traffic will not interact with any of my other IOT devices, can Home Assistant (which is on my main network) communicate fine with the Kumo on the new VLAN? I’m using an Orbi Pro as my main router so I assume I configure it from there so that I can communicate across the 2 VLANs? Thanks

431

My Kumo is working much better now that I’ve isolated it from other devices on my LAN with its own fixed IP. However, I have one (slightly different problem). Once in a while, the Kumo integration shows my Mitsubishi as “UNAVAILABLE” (same as before when it was actually disconnected) but it’s actually connected and the Kumo Cloud app works ok. I’ve tried reloading the integration but that doesn’t seem to help. But if I restart Home Assistant, the integration seems to reconnect. Anything I can do on my side to address this? Thanks.

432

Yes, the orbi would need to act as a router in this case between the two subnets. The kumo integration requires manual input of the Kumo’s IP address, so you don’t need SSDP or multicast to work across subnets for setup. It’s best actually to prevent multicast forwarding between subnets as it keeps the network quiet for the Kumo Wifi adapter.

Good luck!

433

I see that very rarely. I assume the Kumo is busy, maybe talking to the cloud controller and can’t do two things at once, but that’s speculation on my part.

You selected prefer_cache right? Perhaps increase the response and connect timeout parameters?

434

Yes, I set to prefer_cache. Do I increase the response time parameters in the json file or the config yaml?

The odd thing is that I would have thought reloading the Kumo integration would fix things but only a HA restart seems to work.

Thanks.

435

Thanks! At this point, it’s definitely my problem :grinning_face_with_smiling_eyes:

I’ll try to figure this out from here. Thanks again.

436

Hi! One last question (hopefully)…

I set up a separate VLAN and turned on IGMP Proxying, which seems to be the only setting my Netgear Orbi Pro has to minimize traffic from Multicasting. Not sure if it helps but the dropouts seems to be fewer (though still around 1 per hour for less than 20-30 seconds).

If I want to increase the response and timeout parameters, any recommendation on how much to increase to start? The current setting (default) is 1.2 for Connection Timeout and 8 for Response Timeout.

Thanks!

437

I would turn off IGMP proxying - that bridges multicast traffic, you don’t want that. Instead put in an ACL that drops everything on that VLAN for 224.0.0.0/4. That will kill all multicast. Once you do that hopefully it will be thoroughly reliable.

Good luck!

438

Thanks very much or the guidance. Unfortunately, it looks like my Orbi Pro 6 doesn’t have the option to create an ACL for a specific VLAN. As a result, I’ll need to find another way to block multicast traffic for the VLAN that my Kumo Adapter is on.

Thanks again.

439

Ah yes, I forgot consumer routers don’t have a lot of firewall controls. I use PFsense which is an open source firewall.

Try turning off IGMP proxying on that VLAN and see if that makes it reliable. It may not be doing multicast forwarding at all in the normal case (that is what I would expect). The ACL would make sure that so such traffic hit the WLAN, but normally it should not need that.

Also, if you want to check what’s going connect, connect a laptop to the same WLAN that the Kumos are on, and run wireshark on that interface, and you should be able to see all the traffic and see if there is multicast or broadcast traffic that is putting too much load on it.

Also, how good is the WiFi connection to the Kumo? And does the data rate it’s connected at change often? If it does change, you may have interference from other WiFi AP’s on the same channel, neighbors, etc…, that could be adding instability to the Kumo connection, and as you have learned, it’s a pretty fragile implementation.

440

Thanks again for your response. I really appreciate all your efforts…

Sadly, my Orbi Pro is technically “Pro” but clearly this is a marketing term. However, it does have some VLAN functionality.

I turned off IGMP Proxying (for entire network since I can do it by VLAN). I also configured a port on my router to “access mode” so traffic is only for the Kumo VLAN. Then I connected a new TP-Link router that the Kumo adapter exclusively connects to. The wireless signal is extremely strong (~ -11 to -15 consistently) since it’s only about 1 foot from the Kumo. I’ve also tried different channels.

There’s only one wireless client connected (the Kumo) and I see only minimal traffic on the network. However, I still get dropouts.

My last option is to use OpenWRT. The new TP-Link wi-fi router that I installed as an access point just for the Kumo can be flashed with OpenWRT so I will try to do that as that does have more filtering capabilities than the stock TP-Link firmware.

Hopefully, OpenWRT can help with the Kumo wireless connectivity.

Thanks.

441

Just a quick update… I think I isolated the Kumo device as much as I can…

I set up a new Archer A7 router running the latest OpenWrt firmware and with a firewall to filter out all multicast messages, and the Kumo wireless adapter is the sole device attached to it. In addition, the A7 is connected to a port on my main router so it’s on its own dedicated VLAN / subnet (port is configured as access). I also set up a static route so my HA server (on my main network) can access the Kumo adapter.

However, I still get dropouts. At this point, I think this is about as good as I can get it so I’m thinking it may just be the adapter. It comes back online very quickly (usually less than 30 seconds) so I can live with it. I only notice since I have an automation that sends me a notification when the adapter is not available.

Please let me know if there are additional traffic rules I should set up in my firewall besides blocking Multicast.

Otherwise, I can live with it as it is.

Thanks again for all your help!

442

I’m in hell right now. I’ve go the older PAC-USWHS002-WF-1 adapter and had kumo cloud working the last few years. I’ve struggled with timeouts and disconnects but learned to live with it as I wasn’t sure what was going on.

When it was originally installed I felt liken a Guinea pig way back in 2018 (?) since they told me to get cloud control I needed to give up MHK1. Oh well, home automation won over WAF and while automation has been nice it’s been super annoying to be the only person who can adjust the temp.

Anyways, fast forward to today. HA is telling me it can’t communicate and no temp is showing in my cards. I go into kumo cloud app and it’s reporting the zone is offline.

I try to reconnect Wi-Fi in the kumo cloud app in system settings and no luck. I tried factoring resetting the adapter and no luck.

Still can’t get the Wi-Fi to connect again. I remember struggling with this years ago but can’t remember how I managed to resolve it or if it was just luck and me trying over and over.

It seems like these adapters are a POS based on my read of the last few pages. I want to try to fix this ultimately with different hardware based on earlier posts but for now I need to get this connected as I can’t control our HVAC at all now for our main zone.

Help?

443

Hi,

I’ve had similar issues and they seem to be getting worse. Even if I do nothing, the WF-1 still seems to drop off. The only way that I’ve been able to reliably get the WF-1 back online is to power cycle the adapter. In my case, I can’t reset the circuit breaker for my unit so I have to unplug the WF-1 and then plug it back it. It’s definitely super annoying…

I’ve found that I can ping the WF-1 so it’s connected to my network but neither the Kumo App nor HA can connect to it so I get the “unavailable” error in both. This can only be fixed by power cycling the adapter.

Good luck…

444

Thanks for the tip. I’ll try that.

I noticed that the WF-2 adapter is supposed to work in conjunction with an MHK1. Is it any more reliable than the WF1?

Update: just power cycled the WF-1 adapter by unplugging it and then back in. Still no luck reconnecting it. Ugh

445

Hi,

I actually haven’t been able to find the WF-2 at anything resembling a reasonable price so just stuck with the WF-1. As a result, I can’t speak to the reliability of the WF-2. I had wanted to get the WF-2 for its extra port so I can use the MHK-1 similar to your configuration.

However, I do know that my WF-1 has been getting worse over the past year. Of course, that may be due to software as much as hardware since there’s nothing mechanical and it’s a pretty simple device.

If power cycling the WF-1 doesn’t work for you, what worked for me was to factory reset the WF-1, delete the zone from my Kumo App and then start over. You do that by holding down one of the 2 buttons on the front of the device… don’t remember exactly but it’s in the data sheet.

In my case, all the automations and cards were preserved in HA since the entity name was the same. The only thing I lost was the programming schedule for my zone that was in Kumo. Just make sure you name the zone in Kumo the same as it was originally.

And separately, I use a static IP with the “prefer local cache” option.

I definitely want to bail on the WF-1 so once I can find a WF-2, I’ll buy one and see if it helps.

446

One additional comment, in case it helps… I’m not sure if the root cause of my problems is the same as yours. However, several times HA has shown my Kumo as “unavailable” and the Kumo Cloud app also shows my unit as “offline” However, I can tell from my router that the WF-1 is still connected.

What’s worked sometimes in this case is to restart HA. I’ve tried re-loading the integration but that doesn’t seem to work. But with local cache set and a static IP, HA can sometimes access my Kumo again without me having to power cycle the WF-1. I don’t know if there’s something else I can do in between restarting HA and reloading the Kumo integration but restarting HA isn’t a big deal for me so I can live with this process for now. So even though the Kumo app can’t find my unit, at least HA can access it.

Good luck!

447

I don’t have a WF-1 to compare to, but the more extreme problems folks have described in this discussion do not sound like things that I’ve had issues with myself.

I have a total of six WF-2s, purchased in two batches (a single unit, and then five more). I would not call them “robust” or “bulletproof”, but they are reasonably reliable on a long-term basis.

What exactly does that mean?

Are they online and responsive 100% of the time? No. I have occasions where Kumo Cloud can’t see them, or can’t contact them, or hasn’t heard from them for a while. Sometimes it’s just one or two units, more often it’s all of them. The Kumo app is mostly useless anyway, once they’re online, so I never really use it.

It’s also possible my VLAN or firewall or DNS configuration causes issues, though you’d think that would be constant, instead of intermittent. Maybe they spaz out when they try to do something naughty, and my Pi-hole DNS causes that to fail? It would take traffic sniffing, and expertise I don’t have, to figure it out.

There are also times when Home Assistant seems to lose connection with individual units, though that’s usually very short term. I don’t bother doing anything to try to “fix” the issue, I just use the standard Mitsubishi remote to control the unit manually. The problem eventually goes away. HA never seems to lose access to all of them at a go, and I can still see them on my network, so it’s probably just individual interfaces being overwhelmed by “noise” on the IOT VLAN. On the occasions when I’ve looked into the logs, it seems like HA is reaching out, but nothing is answering. (Sorry, been too long for me to dig up specifics.)

The explanation provided (here? a different thread?) about how the IP stack running on the WF-2 hardware is poor quality matches the behavior I think I’ve experienced. It’s pretty clear that $15 in ESP32 hardware, and any of the options for running software on it would be a better solution. If my equipment was not less than a year old, I’d certainly look at the DIY approach. But I’m not voiding my warranty for that; the WF-2 interfaces, while wildly overpriced, work well enough for me to keep me on that “kinda happy path”.