Anyone Using Mitsubishi WiFi Controllers / Apps (MELCloud) in Europe

Swedish

1 Like

Hi @jasper, I don't believe anyone on this forum has setup anything outside a Hubitat hub to test their code, so I would expect that if you get anything working in that space it would be useful for more than just me. For my own development I have just worked on my own "production" hub. Some get a second hub just for development and testing, both of their own code and/or other Community apps / drivers they want to introduce. I guess the thing you may struggle to replicate outside of a hub is the interaction between devices, not necessarily in this case, but certainly in other drivers or apps.

If you are seeing errors with the code you are more than welcome to post them here and I can take a look, but you are equally welcome to work through it yourself and am happy to help you with doing that wherever I can

Also, thanks for the Country listing above.

Simon

1 Like

I almost forgot, presets have been requested before and I intend to get to them eventually, but you are welcome to fast track that yourself :slightly_smiling_face:.

1 Like

Hi @sburke781!

I don't know what has happend but the icon-thing has fixed itself.
I haven't change the mode in weeks and I noticed it now.

I installed your newest version and I'll report if I find something.

1 Like

For anyone interested, I have setup a test version of the Parent Driver that includes a Language selector in the preferences of the parent device (see link to the code below), but PLEASE KEEP READING before using this code.

The background to this is that I used someone else's code to get me started and that included passing a language code of 13 when performing the authentication step. @mikkomattip has reported issues with the language changing to Swedish in the MELCloud mobile app following the setup of the HE drivers. @jasper also reported that if the language setting was taken out of the authentication step the language was changed to English. Hence the decision to include the setting.

The reason for "shouting" earlier to read on is only that from the list of languages Jasper kindly provided, Swedish (which I believe is Svenska), has a code of 18, and the language code 13 that has been used in my code to date, is actually listed as Norsk. So I guess I would just warn people that this may not produce the expected outcome and may need some adjusting after some testing.

Simon

1 Like

Hi, this is truly awesome if you get this work!

I installed the new driver. I changed a language to Finnish (number 17) and saved the settings but at the moment I don't see any changes. Everything is still in english on my dashboard.

Edit:

Now when I press refresh on a device menu, my MelCloud app stays in Finnish.

1 Like

You read my mind.... :slightly_smiling_face:

Any chance you could test the Swedish option to make sure it is in fact Swedish?

Only had a bit of time this week, but I am struggling a bit to get the driver to work. My devices are in a different house layout, 2 floors, one floor divided into 2 areas.
This seems to work for me (not tested much yet):

Next problem is an authentication error upon child device creation (in the child device itself). Still working on that. parent.getAuthCode returns null right after creation. It does return the authcode upon an explicit refresh (after the children have been created).
Subsequently, I get another exception thrown. still gotta look into that one.

1 Like

Thanks for the feedback @jasper, and your efforts in testing, happy to help out where I can.

As much as I thought I had catered for multiple devices, this is probably a setup I and other users haven't had to deal with or test in reality. I am looking at something similar in working on an integration for the users in the US with the Kumo cloud, so I may learn something with my efforts there that could translate to the code for the MELCloud devices.

All that said, does sound like you are getting some very specific issues with the child devices which I wouldn't have expected. I'll try to look at these over the next week or two, but would be interested in any further feedback on you own testing.

Thanks,
Simon

Just to keep you posted a bit, the traverse_buiduing works correctly (for me) (adding all devices somewhere within a single building (e.g. floors, areas, etc), BUT I have some new code which also iterates over the buildings within a single account. to be continued.

It seems like the "parent.getAuthCode returns null right after creation" problem is known, as the instructions in the readme cope with this ("press refresh after..."). (basically the state of the parent only gets persisted after execution, while the child devices already request it when being created). Solution still to implement is to either pass the authcode along upon child creation, or re-request it.)

That said, I have setup a code base in which I can more easily debug and test the device implementation, and at the same time cleaning up the code a bit. (easier to tackle the exception I am getting). Will make that available soonish.

After that, I will be focusing on presets. Still thinking of the best way to arrange this. So far my line of thinking is to implement the "thermostatMode" capability, and allow the user to map the modes ( "heat", "cool", "emergency heat", ) onto user presets (I can configure 3 presets per unit). The two remaining modes ("auto", "off" ) will map directly on auto with a temperature setting, and off. Any ideas/brainstorming is welcome ofc :wink: The other approach would be to do this "custom" and not implement an existing capability.

2 Likes

Just an FYI that I have merged the language selector into the main branch on my GitHub repository.

1 Like

That all sounds very promising @jasper.

I will look into the auth code issue and have created an issue in GitHub. Thanks for picking up on it.

Not sure if this will change anything for you, but I do have plans to merge together drivers for MELCloud in Europe, the work I am doing on Kumo Cloud in the US and a driver I wrote some time ago for MELView here is Aus / NZ. You may notice a most of the "logic" is split out from the API calls in different methods. I intend to leverage the same logic around checking temperatures are in the right range, updates to set points, etc, but then call different code for the different API's when I get around to merging them.

In terms of presets, I'm certainly open to ideas. Without having looked at it closely myself, I was thinking of just setting up some virtual switches as child devices and was hoping you could call the API and pass in the preset you wanted to activate, essentially leaving the config and processing of the presets within the MELCloud platform. Having a similar concept built within the drivers could be of some benefit, but if it can work within the existing preset setup in MelCloud, I'm reluctant to build something that simply replicates it without any additional benefit.

Interested to hear the you next update....

Simon

About the presets all I need is heating in winter and cooling in summer with specified temperatures. My AC is just running 24/7 and basically I don't change any settings during the seasons.

Of course all that is done by changing the mode from the dashboard, but would be a nice addition to just have two buttons "winter" and "summer".

2 Likes

Yeah, it makes sense to add some buttons as child devices next to the airco's. sounds good :slight_smile:

At the moment I have some draft code ready that can read and apply the presets (note that it is only applying the presets, an airco device is unaware of the presets). Next steps is to create the buttons. Then migrate the code to a hub (as I emulated a hub to speed up coding).

3 Likes

Sounds great, look forward to it. Thanks for your work on this, I have peaks and troughs in my work on different projects, good to have this one ticking along with your efforts.

My next focus is getting these drivers into package manager.

Got some code in a different project that
(1) extracts devices from more places (supporting devices assigned to buildings, floors, areas etc. ).
(2) extracts and applies presets.

Still needs a bit of cleanup, refactoring and functionality extension. But in case you're already interested I can point you to it. (otherwise just wait for the cleanup, refactoring and functionality extension :wink: ).
(Later, code can be moved into your driver. For now, I am using this repo to learn a bit abt hubitat dev.)

1 Like

Great to hear this driver has sparked an interest and in learning more about driver development, I know I've learnt a lot myself.

I am also refactoring the code (slowly) to accommodate the combining of the Aus/NZ (MelView), Eurpoean (MelCloud) and US (Kumo) based systems. I don't expect this will cause any issues with merging your code, nor would I want to dampen your enthusiasm, I am more than happy to have others contribute, just wanted to make you aware. Happy to talk you through my plans if you want. Would also be happy to look through what you have done so far, even in a partially completed state.

Thanks again,
Simon

Yeah, so far I just started a fresh repo, with some code inspired by your driver.
Added an emulated hub and driver so I can do integration tests (method get_authDriver) (and debug) on my melcloud account from an IDE).
Here is the code that traverse through all buildings to find device ( method updateChildDevices)
And finally the presets. Presets are actually part of the ListDevices call, so I kept that in the parent driver (method getPresets), and have the child device request it (method setPreset).

For now, I just create a separate button for each preset as child device but that might change.

(Once I got things ironed out a bit I can see to map it to your driver.)

2 Likes

Great job, I'll try and take a look at the code some time soon.... Love the idea of being able to work outside of a hub, would be interested in how you have set it up and how you have found that experience, as I am sure others on the Community would also be interested....