Mitsubishi Electric Kumo Cloud Binding (MHK2)

I’m sure this is probably all expected behavior, but in case it helps in thinking about a workaround: The below pattern of entries shows up in my openhab.log before every communication failure, and then repeats every 3 seconds for three times, then a ~30 second pause, then another 3x, then 30 second pause, and so on until the connection comes back online.

2024-05-28 19:10:21.361	
	at org.openhab.binding.mitsubishikumocloud.internal.MitsubishiKumoCloudBaseHandler.sendRequest(MitsubishiKumoCloudBaseHandler.java:93) ~[?:?]



2024-05-28 19:10:21.361	
	at org.openhab.binding.mitsubishikumocloud.internal.MitsubishiKumoCloudDeviceHandler.updateData(MitsubishiKumoCloudDeviceHandler.java:204) ~[?:?]
2024-05-28 19:10:21.361	
	at org.openhab.binding.mitsubishikumocloud.internal.MitsubishiKumoCloudBaseHandler.retrieve_attributes(MitsubishiKumoCloudBaseHandler.java:216) ~[?:?]
2024-05-28 19:10:21.361	
	at org.openhab.binding.mitsubishikumocloud.internal.MitsubishiKumoCloudBaseHandler.make_request(MitsubishiKumoCloudBaseHandler.java:142) ~[?:?]
2024-05-28 19:10:21.361	
	at org.openhab.binding.mitsubishikumocloud.internal.MitsubishiKumoCloudBaseHandler.sendRequest(MitsubishiKumoCloudBaseHandler.java:107) ~[?:?]
2024-05-28 19:10:21.361	
org.openhab.binding.mitsubishikumocloud.internal.KumoCloudCommunicationException: java.util.concurrent.ExecutionException: java.net.NoRouteToHostException: No route to host
2024-05-28 19:10:21.361	
2024-05-28 19:10:21.128 [WARN ] [nal.MitsubishiKumoCloudDeviceHandler] - Communication Failure: java.util.concurrent.ExecutionException: java.net.NoRouteToHostException: No route to host

Hi-

Yes, those are “normal”: If a request fails, it’s retried 2 times in case a temporary glitch causes the problem. The errors you’re seeing are happening because the device has actually dropped off the network, most likely because it’s rebooting.

The fix is easy. Turn off logging for the binding. I’ve been using for a while, and before that the homeassistant equivalent, and despite a noisy log, all has been stable.

@kjknauss It seems like that would just stop me from seeing the when the device goes offline and then online again. Unfortunately, that’s not the problem. I don’t care if it’s just something I see in the logs.

In this case, every time the device loses and regains connection, it turns on the heat pump. This afternoon it was happening repeatedly: the heat pump comes on–even though the current temperture is above the setpoint–it runs for about 5 to 10 minutes, then shuts off until the next offline/online cycle. When things are bad, that’s often 5 minutes later. With the ultimate effect that the heat pump and the blower fan are running far more than they have to, and the house stays a few degrees above the setpoint.

My main concerns are wear and tear on the system, and overall energy usage. So now I’m considering creating a workaround where, if the house temp is more than a degree higher than the heat setpoint, I turn the system mode to off. (When it’s set to off it doesn’t run a cycle every time the device loses connection). And then I’ll just turn it on again when the temp gets back down to the setpoint, or maybe a degree under the setpoint.

It’s either that or stop using the binding and/or kumocloud. When I deactivate the binding, the system still does the seemingly pointless cycles now and then, but it’s more like once an hour or two instead of 4 or 5 times an hour. So now I’m looking into the “Mitsubishi2MQTT” interfaces that some folks have put together, and meanwhile keeping an eye out for Mitsubishi’s replacement to kumocloud.

@hww3 Thanks again for your help with this. I’ve managed to keep the kumocloud device crashes down to reasonably minimal by setting the refresh to 600 seconds, and turning off the system when it’s reasonable to do so.

Now I’m working on an automation that involves setting the mode to “fan”. The trouble is that every time I try to set the system mode to “fan”, the fan doesn’t come on, and the system mode changes back to whatever it was before, after about a second or two.

I’ve noticed that when set the mode to fan manually (either via the thermostat or via the kumocloud app), the system mode in openHAB says “vent”. So I tried setting the system mode to “vent” in openHAB, but with the same result: It changes back after a moment, and the system doesn’t go into fan/vent mode.

I’m wondering if this is something that you’ve run across before? Is it another kumocloud bug/limitation? Or could there be something in the binding that is causing this to fail?