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.
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.
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.
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!
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.
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...?
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.
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.
Ok, that should do it, I was able to save the driver on my hub after I updated it. I had commented out the entire section of code where the error was occurring but the "star"/"star" was closing the comment early. I just took the commented code out for now. I also updated the file to include the ".groovy" extension.
I updated the link in my earlier post, including changing the link to the raw version of the code.
I was able to run though the test, albeit without a login. Hope you have more luck this time.
I expect the Base URL is likely to be your problem. As you move around some sites (not all) they will show you the path to where you are in the address bar in your browser, which I suspect is what you are seeing with the hash and word start when you access the web site.
I'm pretty sure the URL we need to use for the API calls will still be the one I set as the default. If you could test with that and let me know the results, that would be great.
I'll try to tee up a few more commands over the weekend to try, using the output Craig provided.
@sburke781 - As I understand it (from my own experience) there are a number of landing spots based on geography for Kumo access. Trying to log into the wrong one begins a journey down a rabbit hole you don't want to experience. At first I tried the default "https://geo-c.kumocloud.com" and got this:
dev:4732021-02-12 08:54:50.201 am errorsetAuthCode: Unable to query Mitsubishi Electric MELCloud: groovy.lang.MissingPropertyException: Exception evaluating property 'login' for java.util.ArrayList, Reason: groovy.lang.MissingPropertyException: No such property: login for class: java.lang.String
In the degub logging info it does seem to be polling info (from that default site) even with the error. I can PM that log info if interested. lmk.