Does anyone in Europe use the WiFi controller and associated phone app for a Mitsubishi air conditioner?
I previously developed a driver for mine here in Australia and was asked to get it up and running for a user in Sweden, but turns out they are two different web services / API's, i.e. mine is on a system called MelView for Australia and New Zealand, whereas Sweden (Europe) are on MelCloud.
I'm planning to expand the code to include MelCloud and eventually release it. Just thought I'd check if there were any other users who may want to test the driver.
It's been a while and I've finally got back to looking at this code. Just thought I'd add another post here to see if anyone else has had any experience with the MELCloud API?
I'm looking at controlling the air conditioner using the SetATA call. Seems like you may need to provide a large number of settings in one call, at least I think that's what is happening, i.e. settemp, power (on/off), etc, in the one call, I don't think I can provide just a setTemp.
EDIT - 26-Nov - I have merged the last 4-5 months worth of changes back into the master branch, so have adjusted the links to the code, as they pointed to a "temporary" branch in Git.
I still have plenty to do, but wanted to make this early version available for anyone interested in testing. If anyone apart from @MatsF is interested, let me know and I'll post some instructions, but for anyone that is familiar with what feels like the "old way of doing things", i.e. pre package manager, it is just two device drivers to install (see links below), the creation of a device using the parent driver, putting in some credentials in the parent device, pressing refresh and the child device (the actual A/C) will be created automatically.
Like I said, this is nowhere near finished, but hoping some users can get something working and provide feedback. It is heavily hard coded to a set list of operating modes, etc. I plan to do so much more with it, but just need the time... Hoping I can eventually construct it in such a way that I can have the same high level logic from many of the existing methods, then specific code for the API calls to MelCloud (Europe), MelView (Aus/NZ) and the Kumo Cloud (US) sitting underneath, perhaps as separate drivers, not sure.
Great to hear @mario.fuchs, happy for you to download the code and see if it works for you.
I have made some more changes today and uploaded them to the branch in Github linked above. Happy for you and @MatsF to check them out. I think I have most of the basics covered, including changes in thermostat mode, fan mode, temperature, etc. I have just included some code to read in the supported modes from MelCloud and adjust where the authorisation code is stored in the parent device.
I'm happy for anyone to install and test the code, but before I post a beta page on the community I just want to look at a couple of things, including:
scheduling refreshes of the units inside the driver code to get the latest status information such as set temperature, room temperature, mode, etc, including an option for the user to set the polling period
managing / coordinating the scheduling of these refreshes with running commands to change temperature, etc, so that they don't clash
encrypting the authorisation code
Make available in Package Manager
There's certainly more that I want to do, but I think once I implement these and resolve any issues that come out of initial testing, I'd be happy to make it more widely available.
Feel free to get in touch with any questions or requests.
Great work, I'm also using melCloud and have made a simpe drivers for setting preset modes and on/off and using it today. I have downloaded yours and got it installed, the first thing I saw is that you are using a totatlly diffrent URI.
I'm using as base URI https://app.melcloud.com is this the URI you are using in Australia for melView/melCloud ?
Thinking about it some more, your scenario of preset settings does sound like a useful option to include down the track, not so much for me, but still something worthy of including once I get the basics working how I want.
I was thinking of storing different presets so that you could configure and call them from within HE. Not sure how, may need some sort of map or array to store the settings I expect.
2: created a virtual device for the parent and entered my login credentials
Looks like I got a State Variables authCode and the Split AC unit was picked up
Excellent, thanks so much for the details on your testing. Looks like I may need to look at the fan modes. Has that gone from being unknown to a more appropriate value? I did tweak the code for that list of supported modes just before my earlier posts, so there may have been an issue there.
Now that I have gotten the hang of basic functionality, I would like to tie this in with home/night/away modes in Hubitat. From what device can I pick up either presets or defining settings to be used for different scenarios?
Even better: does the parent pick up the 3 configurable presets from the MEL app?
If so, I'll go ahead and define Home/Night/Away there.
If it is showing the 5 fan modes from your screenshot I would expect it has detected you have 5 acailable, is this not the case for your unit? What fan modes do you see on you Mitsubishi app on your phone / tablet?
Are you talking about using something like mode manager? Either way, I would expect you would choose the child device representing the air conditioner unit.
Not quite sure what you are referring to here, you may need to explain a little more...
Sure! on my iPhone, in the MEL Cloud app, when having clicked in to my unit from the home screen, on top of the page are 3 user configurable presets. These are what I'm referring to:
Ah, that makes more sense now. I haven't looked at these yet, I have been focused on the basic functionality for now. I can add them to the list for future work.
When push on the temperature set's 10 and all auto.
it also sets the temperature to 10 when hitting off.
Doing this from postman or my simple driver starts the unit with the same settings as was before shutdown.
Weird, I have tried to compare the body/headers from Chrome, Postman, your driver and my simple driver.
Body from your driver
{
"Power": "true",
"EffectiveFlags": "1",
"DeviceID": "XXXXX",
"HasPendingCommand": "true"
}
Body from postman
{
"Power": true,
"DeviceID": XXXXX,
"EffectiveFlags": 1
}
I have tried to remove "" from the body in your driver but same results, also tried to change httpPost to httpPostJson. I'm not a developer though. can it be something with the headers ?