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?