expose outdoor unit speed and/or heating stage

[brianr2600]

This information is available over cn104, but I don't know if kumo exposes it.

[dlarrick]

I would absolutely love to export this information, along with the indoor unit's actual fan speed when in auto. But I have not found it in the (undocumented) command/response schema used by the indoor units.

My snooping on comms between the KumoCloud app and my units turned up the following commands to be sent to the unit ("c" being, presumably, "command"):

1. {"c":{"indoorUnit":{"status":{}}}} we knew about
2. {"c":{"sensors":{}}} gives info on the connected sensor(s) if any. I definitely wanted this one -- the temperature was already promoted, but the humidity and sensor battery % are interesting.
3. {"c":{"systemChangeover":{}}} probably has to do with multiple units switching operating mode in tandem.
4. {"c":{"eqc":{"channels":{"4":{}}}}} seems to have to do with “Kumo Station” which allows Kumo to control other HVAC equipment (“EQuipment Controller”)
5. {"c":{"indoorUnit":{"profile":{}}}} gives the device capabilities
6. {"c":{"indoorUnit":{"schedule"} with various subcommands allows access (and presumably modification) of the builtin schedules
7. {"c":{"adapter":{"info":{},"status":{}}}} gives info on the network adapter
8. {"c":{"adapter":{}}} gives even more sub-dicts -- info, status,
9. {"c":{"indoorUnit":{"settings":{}}}} returns “rawITPFrame” which is devoid of info
10. {"c":{"indoorUnit":{"info":{}}}} is accepted and returns an empty dict
11. {"c":{"test":{}}} is accepted and does not return anything useful

kumojs (from which this project pulled its starting point) dealt with item 1 only. I pull some additional info from item 2, because one of my units has a remote sensor. This is how we get humidity and the sensor's battery. I also pull some info from items 5 and 8 to auto-configure the capabilities of different unit types and installations (modes other than cool, number of fan speeds, etc.) When we get responses

But additional snooping, and trying some likely command verbs I could think of in the spirit of the existing api, has not turned up what you're asking for, nor even just if the unit is currently heating/cooling.

If anyone else wants to take a shot at it, it's easy enough with basic Python skills to make a PyKumo object and try to send arbitrary commands to the indoor unit, using the existing calls to self._request as a guide.

A couple other avenues that might be worthwhile: the WiFi interfaces can evidently receive updates over the air. If someone could find one and unpack it, it might be possible to uncover the complete schema. Alternatively, a similar technique might be useable with the Android or iOS apps.

[ash211]

I'd be interested in getting outdoor unit speed+stage also.

I took a crack at learning more by decompiling the Kumo Cloud Android app and seeing what I could find.

• Download it from https://apkcombo.com/apk-downloader#package=com.mehvac.kumocloud
• Unzip
• The app is using Apache Cordova so most of the logic is not in Java/Dex -- it's in the assets/www/js/app.js file
• that file looks packed/obfuscated/bundled up, so largely unreadable.
• looking for the command pattern {'c':{ gives some commands:

pi@raspberrypi:~/Downloads/kumocloud_2.14.8/assets/www $ grep -o "{'c':{.........................................................................." -R js/app.js
{'c':{'adapter':{'status':{'runState':_0x1e72f0(0x14a7,-0xf8,-0x10a4,-0xe8e)}}}}
{'c':{'indoorUnit':{'status':{}}}},_0x1449ee,_0x47a0e7);},_0x34da80[_0x562d29(0x
{'c':{'indoorUnit':{'errorHistory':{'errors':{0x1:{}}}}}},_0x39c872,_0x596ab1);}
{'c':{'indoorUnit':{'profile':{}}}},_0x4d90b3,_0x411521);},_0x34da80[_0x1247dc(0
{'c':{'adapter':{'info':{},'status':{}}}},_0x54314f,_0x9d071);},_0x34da80[_0x124
{'c':{'indoorUnit':{'schedule':{'events':_0x4e4faf[_0x2d696c]}}}},_0x3093e8,_0x2
{'c':{'eqc':{'reporting':{},'connected':{},'oat':{}}}},{'c':{'eqc':{'channels':{
{'c':{'eqc':{'channels':{0x2:{}}}}},{'c':{'eqc':{'channels':{0x3:{}}}}},{'c':{'e
{'c':{'sensors':{}}},_0x499427,_0x41aaf5);},_0x34da80[_0x1247dc(0x30b0,-0x152,0x
{'c':{'mhk2':{}}},_0x578b24,_0x2a51d3);},_0x34da80[_0x562d29(0x42,0x2ac7,0x539a,
{'c':{'indoorUnit':{'initialSettings':{}}}},_0x5432d8,_0x45c7ab);},_0x34da80[_0x
{'c':{'systemChangeover':{}}},_0x26a3b4,_0x8607cf);},_0x34da80[_0x562d29(0x179b,
{'c':{'indoorUnit':{'prohibits':{}}}},_0x313008,_0xef5c04);},_0x34da80[_0x1247dc
{'c':{'indoorUnit':{'acoil':{}}}},_0x47ea84,_0xa3d582);},_0x34da80[_0x562d29(0x3
pi@raspberrypi:~/Downloads/kumocloud_2.14.8/assets/www $ 

Some commands that aren't listed above:

• {'c':{'indoorUnit':{'errorHistory'
• {'c':{'eqc':{'reporting':{},'connected':{},'oat':{}}}}
• {'c':{'eqc':{'channels'
• {'c':{'mhk2':{}}}
• {'c':{'indoorUnit':{'initialSettings':{}
• {'c':{'indoorUnit':{'prohibits':{}}}}
• {'c':{'indoorUnit':{'acoil':{}}

Maybe the mhk2 or indoorUnit.acoil commands have something?

[ash211]

Also, what do you think of this object in the kumo_cache.json?

                "reportedCondition": {
                    "more": {},
                    "_created": 1644527236696,
                    "power": 0,
                    "operation_mode": 1,
                    "sp_heat": 21
                },   

power and operation_mode look promising.

[dlarrick]

In the past, people have looked at the web app but I'm not sure anyone has decompiled the Android app before, so thanks for that. In the webapp there seemed to be a bit less obfuscation in some of the surrounding code that shed light on what the commands do. See also my first comment in this thread.

I too would dearly love to get ahold of indoor & outdoor unit current operation (calling, fan speed, etc.) but have hooked up a power monitor to the outdoor unit's circuit, which does give me some insight into how much it runs.

mhk2 is a remote indoor thermostat that support for was contributed recently so we're now at least pulling humidity from it; see #20 . This should work in current hass-kumo if you install the new 0.2.1 version of pykumo.

eqc seems to do with "EQupment Controller" seems to be a different name for Kumo Station. Again, support for this was contributed but I haven't gotten a chance to fully review the (very large) corresponding hass-kumo PR.

acoil is new by me and may be worth digging in to. My units, though, give'__invalid_api_request' when presented with that command.

initialSettings is, I think, related to the numeric options in the installer portion of the app. For me it returns a dict with keys of the numbers from 0 to 31.

[cjkrolak]

Also, what do you think of this object in the kumo_cache.json?

                "reportedCondition": {
                    "more": {},
                    "_created": 1644527236696,
                    "power": 0,
                    "operation_mode": 1,
                    "sp_heat": 21
                },   

power and operation_mode look promising.

operation_mode: 1=heat, 2=dry, 3=cool, 7=fan, 16=off, 33=auto
power toggles between 0 and 1, if operation_mode is 16 then power is 0, else it is 1

[dlarrick]

Philosophically I'm unwilling to rely on the cloud for any more than setup. The KumoCloud service has proved anything but reliable, and is much much slower than local control.

However, anything in the kumo_cache that's specific to the device has to have come from the indoor unit, and should be fetchable by API. I suspect what you're seeing is just the "mode" -- in other words, it's the setting, not what the unit is actually doing.

[cjkrolak]

I suspect what you're seeing is just the "mode" -- in other words, it's the setting, not what the unit is actually doing.

You may be correct, from what I've observed, changes made through the mobile app are ~immediately updated in the kumo_cache, changes made with a remote control are not available in the kumo_cache until you do something on the mobile app that triggers and interrogation of the head unit, like opening a zone detail page.

[ash211]

Philosophically I'm unwilling to rely on the cloud for any more than setup. The KumoCloud service has proved anything but reliable, and is much much slower than local control.

Agree with this -- local control is far superior and certainly preferred.

but have hooked up a power monitor to the outdoor unit's circuit, which does give me some insight into how much it runs.

Are you referring to something like https://blog.sense.com/sense-gets-flexible-with-flex-add-on-sensors/ ? I'm using Sense Flex for a similar purpose, but it's hard to tell how much watt consumption correlates with the setting.

From the above discussion the past couple days, I think this outdoor unit speed/stage is unavailable. Maybe a future update to the Kumo Cloud firmware and app will expose this data in a way we can get to it with this integration.

In the meantime, @brianr2600 mentioned the data is available over cn104. Can you tell us more about that?

[jojoelfe]

Not sure if this helps, but I just got a new ducted S-series heatpump installed and my WIFI adapter seems to respond to:

query = '{"c":{}}'.encode('utf-8')

I've uploaded the responses while idle, cooling with auto fan, and cooling with max fan.

Unfortunately, diffs between them are super boring, suggesting that info about compressor and fan states is not in the local json.

diff output_idle.txt output_cooling_fan_auto.txt 
3c3
<     'spCool': 24.5,
---
>     'spCool': 24,
334c334
<   'adapter': {'status': {'localNetwork': {'stationMode': {'RSSI': -55,
---
>   'adapter': {'status': {'localNetwork': {'stationMode': {'RSSI': -52,
341c341
<     'uptime': 24799,
---
>     'uptime': 25196,
370c370
<   'wallClock': {'posix': 1722191420,
---
>   'wallClock': {'posix': 1722191816,
374c374
<    'local': 'Sun Jul 28 14:30:20 2024'},
---
>    'local': 'Sun Jul 28 14:36:56 2024'},
552c552
<    'scansCompleted': 2435,
---
>    'scansCompleted': 2474,

diff output_idle.txt output_cooling_fan_max.txt 
3c3
<     'spCool': 24.5,
---
>     'spCool': 24,
6c6
<     'fanSpeed': 'auto',
---
>     'fanSpeed': 'powerful',
334c334
<   'adapter': {'status': {'localNetwork': {'stationMode': {'RSSI': -55,
---
>   'adapter': {'status': {'localNetwork': {'stationMode': {'RSSI': -48,
341c341
<     'uptime': 24799,
---
>     'uptime': 25722,
370c370
<   'wallClock': {'posix': 1722191420,
---
>   'wallClock': {'posix': 1722192352,
374c374
<    'local': 'Sun Jul 28 14:30:20 2024'},
---
>    'local': 'Sun Jul 28 14:45:52 2024'},
552c552
<    'scansCompleted': 2435,
---
>    'scansCompleted': 2526,
597c597
<     'indoorHumid': 70},
---
>     'indoorHumid': 68},

[dlarrick]

Thanks for this! It's both good & bad news.

Good news: we've managed to find most of the interesting stuff already
Bad news: it sure would be nice to get access to more, especially any info at all about the outdoor unit.

I'll take a look over your raw responses. I'm booked this weekend but maybe next week.

Edit: another interesting diff would be between normal operation, and when there's a significant difference between the current temperature and the setpoint.

[ekiczek]

6. {"c":{"indoorUnit":{"schedule"}

I'd like to thank you for discovering this command, as I've just used it to create a script to set schedules in lieu of the horrible Kumo Cloud "service". I've had so many problems with Kumo Cloud, and that inspired me to check out pykumo. At first I wrote a CLI cron script to set temps on my thermostats. After discovering the schedule information, I was able to decipher how scheduling works and write another script to just set the schedule.

My system -- I can't speak for all Mitsubishi systems, but this seems to work for me -- seems to have 28 schedule "slots" when you query '{"c":{"indoorUnit":{"schedule":{}}}}'. For example, here's my sample output from that query:

{"r": {"indoorUnit": {"schedule": {"events": {
        "1": {"active": true, "inUse": true, "day": "We", "time": "0800", "settings": {"mode": "heat", "spCool": null, "spHeat": 21.5, "vaneDir": "auto", "fanSpeed": "auto"}},
        "2": {...},
        ...
        "28": {...}
    }
}}}}

I discovered that you can directly overwrite one of the 28 slots with a query like:

            base_query  = '{"c": {"indoorUnit": {"schedule": {"events": {' + \
              '"1": {"active": true, "inUse": true, "day": "SuMoTuWeThFrSa", "time": "0800", "settings": {"mode": "heat", "spHeat": 20, "vaneDir": "auto", "fanSpeed": "auto"}}' + \
              '}}}}}'

I hope this works for others and that others find this information useful.