LOCAL_DATA structure is different

[Alfiegerner]

Hi Z,

Thanks very much for this.

I had to change my LOCAL_DATA string to as follows:

LOCAL_DATA = """<?xml version="1.0" encoding="UTF-8"?>
<ESV>{}</ESV>
"""

Discovered by running web traffic through a proxy after seeing the local commands failed.

Using newish wall mounted units MSZ-AP25VGKD and MSZ-AP35VGKD and an older floor mounted model MFZ-KJ25VE. Also a new account with Melview, started in July / August 2019,

No idea what's changed / why my content tags are different, but thought I should post in case it helps anyone.

Cheers,

Alex

[zacharyrs]

Hi Alex,

Thanks for making me aware of the difference!

The LOCAL_DATA string only plays a role when you include the local flag, as per:

climate:
  - platform: melview
    email: MY_EMAIL@gmail.com
    password: MY_PASSWORD
    local: yes // This line

The control should work independently of this flag; it's just a tad faster. Essentially I forward the local command over the local network, directly to the unit. This command is as provided by MelView, and the web app manually makes the request. I imagine there's a structure to the string that would even offer completely offline control...

I did notice your floor unit has WiFi control built-in, as opposed to mine where I use a dongle. Can you give me the output of the request to https://api.melview.net/api/unitcapabilities.aspx, in particular, the adaptor type?

Cheers,
Zach

[Alfiegerner]

Hi Zach,

All of my units have a MAC-568IF-E dongle attached.

For local control you might like to look at the echonet implementation available here: https://github.com/scottyphillips/mitsubishi_echonet

But for some reason since overhauling my network that's become unreliable for me - still working out the issues.

My experience with the LOCAL_CONTROL not working was that there was a 30 second or so delay, which is not the end of the world but confusing for wife and children - with it working it with <ESV> tags it works as well as as the mobile app.

[zacharyrs]

So I've just taken a quick look into that. You have the MAC568, whereas I have the MAC559. Seems the MAC558/559 use the older (and included) LOCAL_DATA format, whilst the MAC568 supports the ECHONET standard.

I suspect the adaptor type for you would be mac568, as returned by https://api.melview.net/api/unitcapabilities.aspx. Could you check this for me, and then I'll include it in the script.

The ECHONET implementation linked seems to be using a multicast address, whereas I directly talk to the unit. This may be the root of your issue with it following the network changes?

[scottyphillips]

I reckon the API is sending back a PKI encrypted command string. The private key is likely stored on the Wi-FI adaptors. If we could bust open the wi-fi adaptors and get access to the private key we could potentially work out what the commands actually are that are being sent to the adaptors... if every adaptor has the same private key depending on model then 1. Stupid on Mitsubishi's part, and 2. possible to build a 100% local implementation for potentially ALL Mitsubishi adaptors... Time to download Kali I think... :-)