Mitsubishi Wifi Module WF-RAC (Smart M-Air)

Okay, cool, i can’t wait! :grinning:

Great job! And congratulations @jeatheak !

As I’m not using HA, I’m just running the code locally in python. With the code below I’m able to read the values of the device. However, setting values is not possible. The returned temperature is still the same after sending the command.

Could you help me how to change values?

from wfrac.repository import Repository
from wfrac.rac_parser import RacParser
from wfrac.models.aircon import AirconStat


if __name__ == "__main__":
    r = Repository(hostname="192.168.1.9", port=51443)
    details = r.get_details()
    stats = r.get_aircon_stats(operator_id="123")
    par = RacParser()
    aircon = par.translate_bytes(input_string=stats)
    print(aircon.PresetTemp)

    aircon.PresetTemp = 25.0
    airconstat = AirconStat(aircon=aircon)
    command = par.to_base64(aircon_stat=airconstat)
    response = r.send_airco_command(operator_id="123", airco_id=details.airco_id, command=command)
    aircon_changed = par.translate_bytes(input_string=response)
    print(aircon_changed.PresetTemp)



Thank you @peeeter

I think the trick to get it working is to send the correct Operator ID with the request.
You can get the operator id from the remoteList in the response from get_aircon_stats (its in the base object content).

see https://github.com/jeatheak/Mitsubishi-WF-RAC-Integration/blob/8bf56cced4eef7dca9797586fbafd49034264342/mitsubishi-wf-rac/wfrac/repository.py#L40

I hope it helps. If not let me now.

Thanks for helping @jeatheak . I was already thinking about the meaning of the Operator ID. For my understanding, is this a hardware ID of the internal Unit, or is this an ID of the device that is sending the request to WF-RAC?

I looked at the remoteList item of both, get_aircon_stat and get_details. Unfortunately both just contain a list with three empty strings (['', '', '', ''])

get_aircon_stat reports that my firmVer of wireless is 010 and 115 for mcu. Just in case this is of any importance.

Do you have any other idea how to get the Operator ID?

I found out why remoteList was empty in my case.
When initially setting up wifi for WF_RAC I chose the “local” mode in the smart phone app (Smart M-Air). After I enabled internet access, I can see the operatorID in remoteList. With this ID the device accepts the commands that I’m sending :slight_smile:

I installed the integration and noticed that the Indoor temp is equal to the value displayed on the Smart M-Air app, while the Outdoor temp is not. Just some tenths of degree, but it is not the same.
Is it the same for you?

EDIT: Actually I tried again, and sometimes also Indoor temp doesn’t report the same temperature of the app.

Ok nice. I think it is the app/device ID that is connected with the airco.
The local access is something I should look into in the future.

Edit: @peeeter i did a quick check with mitmproxy and can see that it is a ID that is generated by the app (i think uuid) and when you register the airco in the app it will send uptadeAccount api request with te ID. I think it will then accept the ID in the command. I will put it on the todo list to add this functionality to the integration

Ow ok I did not notice that but after checking it myself it does indeed have different values.
But the difference is that it looks like the values in Homeassistant are changing more often therefore it looks like the update interval of the app is slower than the homeassistant integration (30 seconds).

I will check look into it when I have time.

2 Likes

I installed your integration

I feel stupid. Do you mind telling me how you did that?

When I try to add the repo to the official add-ons, I get "https://github.com/jeatheak/Mitsubishi-WF-RAC-Integration is not a valid add-on repository".

When I try to add the repo to HACS, I get "<Integration jeatheak/Mitsubishi-WF-RAC-Integration> Repository structure for main is not compliant".

Download the Release from GitHub as a ZIP (link), then expand the mitsubishi-wf-rac folder so it goes inside the custom_components subfolder of your Home Assistant installation.
If you’ve done correctly, you should have the files like so:

Home-Assistant\custom_components\mitsubishi-wf-rac\manifest.json

Then restart Home Assistant and after startup you should see the new Mitsubishi integration in the Configuration > Integrations menu. There you can assign a name, insert the IP Address of your AC unit and it will create 2 sensors for the indoor and outdoor temperatures.

3 Likes

after startup you should see the new Mitsubishi integration in the Configuration > Integrations menu

Like a charm! Thank you!

Works here great for three airco’s also!

i have four, its work. waiting for more options <3

Hey Guys,

At the moment I’m busy implementing the climate control feature but I’m not sure wat to do with the account update at the moment. Mayby you have some suggestions?

The problem:
To send commands to the Airco you need to have a accountID (operatorId) registered at the airco. This can be done trought the updateAccountInfo api request. But there is a option to add it to the remote list or not. The remote list is meant for the remote connection trough their app/website. If the accountId is not added to the remote list is works also but we never now which operatorId we have set.
The airco can have max 4 “phones” connected.

Possible solutions:

  1. don’t add it to remote list and use a fixed operator id like hassio-operator-id-1 then the integration will try to add it and if it is already present. But it is difficult to determine when to delete. Especially when there are more homeassistant instanced
  2. add a random generated uuid as operator id to the account list. But there is a possiblilty that the delete will go wrong. If the maximum of 4 phone are reached a manual factory reset of the module is needed
  3. add a random uuid also to the remote list therefore we always know which operator id has been registered. But we don’t know which extra features it will activate in the module. (like sending data to their cloud servers)

I hope it is a little bit understandable what I did write.

For me personaly I think solution 2 is the best option because it is meant to be used like that.
But there is a small chance (happend to me, because of development issues) that the phone count will be reached. Than the user needs to reset the module to factory default. Ofcourse it can be checken when adding the airco and display a error with instructions.

1 Like

What is the process for doing this? If it’s simple, I think that would be acceptable.

I have not tried it yet but in the Manuals it says you need to press the reset button more than 3 seconds.

Ah, so it might be a bit of a pain as you’d have to set the wifi up again?

probably :frowning:

Yes that’s true but it will mayby never happen beacause I did implement the delete feature. So in my case it only happend because I was developing (adding/removing the integration) without the delete method.

But there is a small change it will happen. And that the user needs to manual setup de wifi module again.

Edit: you can see the connected accounts in the app: in Airco->options->bottom page (number)

I think you’re right, the probability is low and even then the impact is also low. I would agree that #2 seems the best approach.

1 Like