I’ve decided to try and go down the custom ESP route. You can read more about it in this thread: Mitsubishi AC with Wemos D1 Mini Pro - Configuration - Home Assistant Community (home-assistant.io)
I get what you’re saying about the simplicity of Nest vs Mitsubishi… but the overarching point is by going with a Nest you’re making your system less much less efficient.
Mitsubishi heat pumps can go in 1% increments as far as I remember. So with a Nest/Ecobee you’re getting either 2 or 3 stages, which means you get Off / 33% / 66% / 100%. That’s terrible.
If my info is out of date, please let me know. BUt i recently emailed Ecobee to ask them about variable heatpump support and they said:
“If you have a variable speed heatpump like Mitsubishi or Daikon, you should definitely use their thermostats”
1 Like
I wish this was more turnkey… i’d pay for a prebuilt kit in an enclosure.
Given that the official Mitsubishi interface is ~$350 each, someone making a pre-assembled kit has a lot of margin available to make it more cost effective for customers, while still leaving room for enough profit to make the commercial effort worthwhile.
1 Like
I totally understand the efficiency point. That’s why I am going to do the esp32 in the middle workaround. But I can understand if a customer keeps calling you about the Kumo system not working that they will recommend a different solution.
I wish the Nest or Ecobee guys would implement a solution using the CN105 jacks - it’s just a serial port.
You’ve got the CN105 connector on the PEAD units, see page 37 here
You should be good to go with the Wi-Fi adapters. Worth getting one and giving it a try.
The problem is I bet these void a warranty so no one will do it fully commercial. The next best thing is some tiny community effort where some technical maker would find the margin worthwhile.
Even at $100 this would be a deal compared to the oem solution
I was just wondering if anyone’s experience with Kumo using this integration has gotten much worse recently. My experience has always been poor but at least consistent / stable for the past several months or more. My Kumo goes offline and then comes back online after 1-5 mins, and once in a while I need to power cycle the adapter by unplugging it. The adapter is on a different physical network and VLAN that has no one devices but the Kumo.
However, recently my Kumo integration in Home Assistant shows “unavailable” even when the Kumo adapter is connected to my network with an active lease. And oddly, my Kumo app will work (connecting through the Kumo Cloud). If I reload the integration, nothing happens. But if I reboot Home Assistant, the Kumo integration comes back to life for a few minutes before going unavailable again.
I’m sure the root cause is Kumo… but I’m just trying to understand if there was a recent upgrade to Kumo’s back-end or the Home Assistant Core that might have affected this so I can roll back as needed to get Kumo to be more reliable.
Thanks.
This may be a bit far afield but I flashed an ESP32 chip since my KUMO WF-1 just stopped working. I can read 5V and 12V from Pins 1 & 3 as expected. But I can’t seem to get the ESP32 to communicate directly with my unit. The ESP32 server comes up but can’t connect. This is actually the same error I’m getting with a WF-1 and WF-2 when I also try to connect. Somehow the TX and RX pins aren’t working.
I’m guessing that I have bad luck and the CN105 port on my indoor control board just failed. Unfortunately, I don’t have a hard-wired 2-wire thermostat to test but the system mechanically checks out as I can run a 2-hour test run with no problem.
So was wondering if anyone on this forum happened to have a CN105 port ever fail?
And if I do have an issue with the CN105 port, is there anything I can do besides swapping out the indoor control board?
Thanks.
Can’t seem to get in past the credentials during the integrations section even though my Kumocloud username and password work on the app. Anyone have any ideas?
I have the same problem. This seems related, but no resolution yet: Invalid Credentials, Wrong user or password · Issue #109 · dlarrick/hass-kumo · GitHub
From using pykumo directly, I do see my device is not (yet?) reporting its IP address back to Kumo cloud, which could be related.
I ended up buying 3x PAC-USWHS002-WF-2 from the supply house this week and saw this HUGE label on the boxes.
This is the first time I’ve bought these (after waiting 9 months on backorder), so I don’t know if this is how it has always been labeled. Still, I can’t think of anything else I’ve ever seen that was so explicit about the specifics of the WIFI network it was connected to. It certainly is beyond the technical scope of most HVAC installers I’ve dealt with.
Kind of makes me wonder if they know they have a specific connectivity issue, but don’t want to or can’t put out a hardware revision to fix the issue. My understanding is the reason for the backorder was due to supply constraints on the wireless chip used in the module.
It’s been a while since I looked at my saved boxes, and I’d have to excavate them in the garage, but the warning sticker certainly looks familiar. I know there’s a similar (if not identical) sticker on all of my units’ boxes. It was certainly very clear to me that the WI2 was only going to work on a 2.4GHz network.
While I haven’t split my normal Wi-Fi networks into separately named networks according to the frequency, I did set my Internet-of-Things wireless network to 2.4GHz only. (There’s basically no IOT devices that I know of that can only use 5GHz networks, and the only devices that can make use of higher speeds (Chrome TV, etc.) are already on Ethernet.)
That doesn’t keep them from dropping out occasionally (see previous posts about how terrible the network stack is on these units), but they stay connected most of the time…
I have been having more problems with my install over the past several months.
I have replaced my router, had my service company replace the wireless modules, and ultimately uncovered it was that pesky 2.4 GHz BS. I created a 2.4GHz VLAN and now the connection with the units is rock solid.
I was unable to connect the devices to Home Assistant, so I removed the manual KUMO installation and installed it using HACS. That resolved my login issue and now I am able to connect KUMO to my cloud account.
The cloud account is populating the correct internal IP’s (based on the log) for my two devices. However I am not able to access the controls or sensors as they all appear “Unavailable”.
The logs have several timeout issues, so I increased the timeout to 4.8 but am still seeing warnings about timeout and HTTPConnectionPool Max retires exceeded. The integration reads failed to set up and I am lost on what to try next. Any ideas?
Is there any way to know what speed the fan is running at when Fan Mode is set to Auto?
This is happening to me, too. In my logs, there is:
Logger: homeassistant.helpers.frame
Source: helpers/frame.py:102
First occurred: November 11, 2023 at 2:42:50 PM (3 occurrences)
Last logged: 4:30:13 PM
Detected code that uses save_json from homeassistant.util.json module. This is deprecated and will stop working in Home Assistant 2022.4, it should be updated to use homeassistant.helpers.json module instead. Please report this issue.
I’d like to report this issue but don’t know how.
I have two Kumo Cloud climate sensors that are accounting for the largest number of state changes in the database.
When you look at the devices log entries there isn’t a lot going on:
However when you look at it’s state in developer tools I notice that when I hit refresh the rssi changes very frequently:
However I have the rssi entity disabled, so I’m really not clear on what is going on:
What is the right way to track down what is causing these high number of state changes?
Hi there,
Sorry for the long delay. I’ve had no extra bandwidth since we last spoke, my son is very sick. I didn’t mean to disappear on you. I really appreciate you helping me with this.
Essentially, this one mini split is located in a spot where it’s blowing right in our face when we feed our son and sit at the table, so I’m making a button press trigger a simple ‘ceiling’ fan swing setting but I can’t figure it out. I don’t want to give up.
Here’s what I began with, I don’t understand how to incorporate the swing mode, I’m sorry. I hope you can help me. Thank you so much.
alias: Set Mini-Split Fan Angle to Ceiling
description: ""
trigger:
- device_id: 1cb2e3b79adc8738dce3dfa5b5b4a4
domain: zha
platform: device
type: remote_button_long_press
subtype: remote_button_long_press
action:
- service: climate.set_fan_mode
data:
fan_mode: ceiling
target:
entity_id:
- climate.4_dining_rm
I believe you want climate.set_swing_mode not climate.set_fan_mode. See Climate - Home Assistant docs for all HA climate entities.
Thank you for the link, and suggestion. However I tried changing it to climate.set_swing_mode and sadly, no change. Nothing moved when I ran it.
Do you suspect this is not possible or is it something I’m missing?
(i.e. from the link:
data:
swing_mode: 1
I don’t understand how that setting relates to Kumo. Thank you!
My current attempt:
alias: hvac.dining_room.mini_split_ceiling_angle
description: ""
trigger:
- device_id: 1cb2e3b79ad08738dce3dfa5b5b4a4
domain: zha
platform: device
type: remote_button_long_press
subtype: remote_button_long_press
action:
- service: climate.set_swing_mode
target:
entity_id: climate.4_dining_rm
data:
swing_mode: ceiling
I try running the automation manually in HA (not using the button, to minimize variables), and it’s just not working so there is for sure an error with my code. 
I wish I knew.
Is there a master list somewhere specifically showing what swing modes are ‘called’? Do I use a number, ceiling, floor, etc? I’m confused how to specify the swing mode by name.