Based on the connector the wifi adapter uses, and the similar Mitsubishi PAC-US444CN-1 thermostat interface, I wonder if these mini-splits really just talk serial to whatever controller box gets hooked to them. Could be a more reliable, and less expensive, way to control them compared to the wifi box.
Maybe less expensive, but at $150 ea, I'm happy to have the redundancy. HE, in my home with 2 units, has proven not reliable. For me, HVAC should really be reachable, period. So a thermostat, and kumo supported by Mitz, for remote control and HE as a convenience for home automation links is a great mix... for me.
That said, I see why a wired serial link would be a smoother way to fiddle its knobs😉
I'm not sure whether the US adaptors offer this, but the Aus/NZ API documentation talks about being able to control them completely within the local LAN. From memory it talked about issuing a command and getting back the xml as a response that can be used in future requests for the same command.
I haven't looked at it closely for the Aus/NZ (MelView) or Eurpoean (MelCloud) drivers I am writing, but am keen to include it. I'll take a look at the US documentation when I get around to writing the code, hopefully they offer the same feature.
I've got one installed, and another 2 to do. I can confirm the docs say it'll work locally if iNet is down... but the caveat is only for ad-hoc changes, i.e. schedules created in kumo cloud obviously won't be heard if the internet is down. And the kumo cloud schedule is wholly separate from a local thermostat schedule. It operates on a transactional basis, so whichever timer goes off overwrites the last command regardless of which schedule set it. I have the US PDFs of the 2.9 technical and owners manuals and the kumo cloud wifi adapter manual, if that's helpful, lmk. But in all honesty I find they have a lot of pictures, and very little information.
Not sure if any of the info here is helpful... Not really Kumo, but...
https://nicegear.nz/blog/hacking-a-mitsubishi-heat-pump-air-conditioner/
I could just strangle my Kumo(s)... and I just got em! What the ____ is wrong with offering an ethernet connection anyway?
FYI, I might have something working in hubitat in the next few weeks using local IP communication with the KumoCloud 2nd gen wifi adapter directly.
Right now I just got my basic status API request working, and now working on the refresh routine to properly map the status into hubitat.
Im using the API work that came from here
Stay tuned
Great work, would love to see this developed. Happy for you to look at my code for the MelCloud (European) version or I can give you a hand. The link to my code is on the MelCloud thread I setup:
I mention at the end of the MelCloud post about how as I have been writing this MelCloud integration and having previously worked on my own for the Australia / NZ MelView service, I would expect a lot of the logic and the settings should be essentially the same for all three platforms, it should just be API calls that would be different. If you get time and are interested, you may be able to see where I am heading with this in the MelView code, separating the API calls and the logic into their own methods. This should hopefully lead to a more seamless bringing together of my own Aus/NZ code and potentially yours. There was also some nuance to refreshing the status of the unit vs applying changes to the status that need to instigate an API call. Maybe it was just my brain that struggled with this....
Good luck and feel free to get in touch if you need a hand.
Simon
Thanks! I did glance through your code but could barely recognize the API I’m using in your work; seems like KumoCloud is a completely different implementation.
Right now I got most of my Hubitat interactions working with static keys last-night, now the next step is to rewrite sushilks’s cryptokeyFromAddress() function from TypeScript to Groovy that signs the http request contents, and slowly bring everything back to the KumoCloud userid/password credential.
Getting there!
I guess what I meant is that conceptually the logic and information are likely to be very similar, having a set temperature, current room temperature, heating and cooling set points and logic around maintaining those, that should be pretty much the same, even across different thermostat's outside of Mitsubishi I would imagine. The process of interacting with Kumo vs the MelCloud platforms is, unfortunately, very different, but ideally that part should be the only difference.
Anyway, great work getting it going, I look forward to taking a look.
Simon
I'm looking forward to your work on this, thank you again for taking this task on! I've been trying (and failing) to add Kumo to my Homebridge pi using this homebridge-kumo - npm . If you need any beta testers for your work, please let us all know!
@sburke781 and @craigspree I just happened across this page:
It appears that if you install the wifi adapter 2, it exposes a local wifi http interface that can be used to control the unit without going to the cloud. If I understand the post correctly though, you have to have it in Kumo Cloud first to pull down the authentication key for your device, otherwise you'd need to have a sniffer running on the network with the a/c and your mobile device to capture sniff the key from the network traffic.
In any case, I installed the wifi2 the other day. It can sometimes take a minute for the cloud to pick the device up as connected, even when my firewall shows an open session. It took a bit of extra work to set up because it only talks 2.4ghz and my phone is on a vlan/ssid that is only 5ghz, while they have to be together for the app to complete setup even though it's initially talking bluetooth. If you don't connect right away following boot, it may not connect, or may take a very long time. So I had to move my phone to my untrusted devices 2.4ghz network, then factory reset/power cycle the adapter because it had half completed the prior attempt and got in a weird state. It does appear Kumo Cloud is required for scheduling. What I don't know is what happens if the cloud is disconnected at the time a turn off is supposed to occur; does it check status and execute on reconnect?
The IFTTT integration is pretty disappointing. It basically just works so a few things like smart outlets and lights can turn on/off with the a/c.
I might play around with MQTT to the wifi adapter's API. Would love to have an all-local option, and worst case a cron job shuts the a/c off at night if something inadvertently turned it on and left it on.
Just a friendly check to see if you’ve been able to make any more progress
Given this post from @bravenel today, it looks like IFTTT support from Hubitat is going away at some point in the future (< 1 year). At that point my Kumo integration through IFTTT goes away.
I’m willing to donate a bit to the effort if needed. Just let us know. Thank you!
Sorry it's been so long since I posted here, I know I'd been promising to look at this for quite some time.... Been distracting myself with all manner of new toys, including a new C-7 hub. I'd like to make some kind of start on this, unless @kris2k2 has made any more progress... Happy to share some code or work together if you are close to having something finished? Also happy to have a play with the API myself, the only issue for me is I don't have a unit to test with, so a little hamstrung there. I may need someone to set me up with an account on their system, but can understand if people would prefer not to. I can also write some of the code and pass it over for others to testing, that is fine as well. If anyone is interested please let me know. I can amuse myself for a while yet getting familiar with the API.....
I do plan to try and incorporate this into the existing code I have built for the Eurpoean version, so hopefully that may speed up some of the development, but it is always hard to predict.
Regards,
Simon
The article you refer to @BGP does sound similar to what I have read for the MelView platform in Aus/NZ, I think ours provide an XML response for future use in a completely local solution. I looked at it briefly when I started to program my own driver and I can see what it is meant to do but have been focused on getting it to work first, but will definitely be looking at this at some point.
In terms of scheduling I can only imagine that would not be an issue if you start managing the scheduling yourself through HE...?
Hi! I’d be happy to test any code you want and report back with detailed results. Ready when you are!
Thank you!!!
Hello, I would be happy to test it too. I have 2 condensers and 10 heads under Kumo. thanks!
I've got a few US version Kumo-cloud units ready and willing for testing with a C-7. Let me know what I can do to help with any testing. Really motivated to get away from the 'cloud' mitz can't seem to keep up and available.
I've made a very small start on the Kumo driver. It's not a driver by an means at this point, just the authentication call, so that I can make sure that first step will work based on my translation of a python script I found. It does not include any controls for the air conditioner at this point, i.e. no temperature or mode controls, etc.
I'll write some more notes shortly.. (EDIT - That is a little hampered by my Internet being out for my Hub, happy to help anyone if you need a hand setting up this test....)
First you need to install the driver code (manually, it's not in package manager yet), create a new Virtual Device referencing the driver, enter your username and password, click Save Preferences and then run the Refresh command for the device. Ideally you should see an AuthCode state variable appear on the device page, but also review the logs to see what comes up. I don't have a Kumo account, so can't test this myself... Would love to hear any outcomes of testing.
I plan to do a few of these tests to make sure my integration with the Kumo Cloud works the way it needs to before doing a more fully fledged driver allowing for control and status updates.
Simon
Excellent! I've been looking forward to starting to test this, even if just an auth POC. Thank you!
I'm getting an error at this step. I've got plenty of other custom drivers installed, and I made sure I'm in the 'driver' section of my admin interface.
Here's the section around line 69 if it helps:
How I installed:
MyHub > Drivers Code > New Driver > Import Driver > Paste this URL: https://raw.githubusercontent.com/sburke781/hubitat/KumoCloud_AuthPOC/KumoCloud_ParentDriverPOC > Click Import > Click Save > Get error.
Thanks for testing, I really should have found that one myself. Hokd on I'll take a quick look.