Kumo Station & MHK2 support

[dlarrick]

@brgaulin @dmcc please test this version and report back. If it looks good I'll commit and make a new pykumo release.

[dmcc]

Sorry for the delay -- ran a quick test this morning. Haven't been able to dig in yet, but something is up with account creation:

import pykumo
account = pykumo.KumoCloudAccount.Factory('<username>', '<password>')
kumos = account.make_pykumos()
print('kumos', kumos)
unit = kumos['Upstairs']

In the main branch, this succeeds. In kumo-station, I get:

kumos {}
Traceback (most recent call last):
  File "/path/to/test_kumo.py", line 6, in <module>
    unit = kumos['Upstairs']
KeyError: 'Upstairs'

Hope this helps and can look further at this later today.

[brgaulin]

Ah. That might get interesting. I think in my branch I had made a change to use the serial number as the key in the dict. As that shouldn’t ever change, but the units can be renamed.

I can work on a PR to back out that breaking change if we want. Or maybe we could expose an alternate method for the indexed by serial number and restore the old one.

[dmcc]

Gotcha. It seemed like I wasn't seeing anything in the dict from make_pykumos, so could it be a different issue?

(also, paranoid question: would this potentially change the name/IDs in Home Assistant integration in https://github.com/dlarrick/hass-kumo ?)

[brgaulin]

We should test the upgrade. There is a PR against hass-kumo as well that pairs with this, but I don't think the names would change

[brgaulin]

On my end, I took ./server_parser.py and uncommented the test section, and I do see data flowing (omitted passwords, and replaced serials with some 9999s at the end)

python3 ./server_parser.py ./examples/local.json
Units: dict_keys(['1434P008T1009999', '1734P008T1809999', '1434P008T1009999', '1434P008T1009999', '1434P008T1009999', '1434P008T1009999'])
Unit 3rd Floor: address: 192.168.3.185 credentials: {'password': 'OMIT', 'crypto_serial': 'OMIT'}
Unit Living Room: address: 192.168.3.181 credentials: {'password': 'OMIT', 'crypto_serial': 'OMIT'}
Unit Kumo: address: 192.168.3.180 credentials: {'password': 'OMIT', 'crypto_serial': 'OMIT'}
Unit Front Bedroom: address: 192.168.3.184 credentials: {'password': 'OMIT', 'crypto_serial': 'OMIT'}
Unit Back Bedroom: address: 192.168.3.183 credentials: {'password': 'OMIT/L', 'crypto_serial': 'OMIT'}
Unit Master Bedroom: address: 192.168.3.182 credentials: {'password': 'OMIT', 'crypto_serial': 'OMIT'}
Indoor Unit 3rd Floor Current Temp: 6.5
Indoor Unit Living Room Current Temp: 18
Kumo Station Outdoor Temp: -11.4
Indoor Unit Front Bedroom Current Temp: 17
Indoor Unit Back Bedroom Current Temp: 19
Indoor Unit Master Bedroom Current Temp: 19

I also attempted your test code @dmcc and it seemed to work ok. I noticed in your output the kumos {} which is an empty dict. Something might of gone wrong with auth? And I was mistaken, the objects were still available on their names, ex.

import pykumo
account = pykumo.KumoCloudAccount.Factory('USER', 'PASS')
kumos = account.make_pykumos()
print('kumos', kumos)
print(kumos['Living Room'])

=>

kumos {'Kumo': <pykumo.py_kumo_station.PyKumoStation object at 0x7f9f4e24c610>, 'Living Room': <pykumo.py_kumo.PyKumo object at 0x7f9f4e21f5b0>, '3rd Floor': <pykumo.py_kumo.PyKumo object at 0x7f9f4e316b20>, 'Front Bedroom': <pykumo.py_kumo.PyKumo object at 0x7f9f4e316880>, 'Master Bedroom': <pykumo.py_kumo.PyKumo object at 0x7f9f4e244ac0>, 'Back Bedroom': <pykumo.py_kumo.PyKumo object at 0x7f9f4e244520>}
<pykumo.py_kumo.PyKumo object at 0x7f9f4e21f5b0>

[dlarrick]

Hi guys, thanks for testing. I gave this a try myself and I agree, seems to be working, result still indexed by name. I suspect KumoCloud was having one of its numerous outages.

I'm also interested in whether this new version is picking up the Kumo Station and humidity from MHK2.

[brgaulin]

Kumo Station looks good, I see it in my output above and it shows the outdoor temp ok

[dmcc]

Ah, weird, maybe there was an auth problem? Just ran it again this morning and now I see a different issue:

kumo-station branch% python test_kumo.py
Unable to determine unit type None
Unable to determine unit type sez
kumos {}
Traceback (most recent call last):
  File "/home/dmcc/prj/test_kumo.py", line 7, in <module>
    unit = kumos['Upstairs']
KeyError: 'Upstairs'

When I run it from my branch, I get the expected output (kumos has two objects in it). Let me know if there are specific debugging statements that would help here.

[dmcc]

Out of paranoia, I ran this again in a fresh checkout with these shell commands:

gh repo clone dlarrick/pykumo
cd pykumo
gh pr checkout 25
python -mvenv v
cd v
source ./bin/activate
pip install .
pip install requests
python /path/toj/test_kumo.py

I get the same output I was seeing in https://github.com/dlarrick/pykumo/pull/25#issuecomment-1011167836

If this works for @dlarrick and @brgaulin then I'll work on tracking it down.

[dmcc]

Alright, I think I've found the issue. The Unable to determine unit type None warning was significant: For whatever reason, my units report two new unitTypes:

self._units[unit] => {'address': '<redacted>',
                    'cryptoSerial': '<redacted>',
                    'label': 'Upstairs',
                    'mac': '<redacted>',
                    'password': '<redacted>',
                    'serial': '<redacted>',
                    'unitType': None}

self._units[unit] => {'address': '<redacted>',
                    'cryptoSerial': '<redacted>',
                    'label': 'Downstairs',
                    'mac': '<redacted>',
                    'password': '<redacted>',
                    'serial': '<redacted>',
                    'unitType': 'sez'}

So, as a hacky fix, I can set:

KUMO_UNIT_TYPE_TO_CLASS = {
    "ductless": PyKumo,
    "headless": PyKumoStation,
    None: PyKumo,
    "sez": PyKumo
}

at the top of py_kumo_cloud_account.py but I worry about what other assumptions we're making. Would it make sense for PyKumo to be the default except for unitType=headless?

[brgaulin]

I think setting pykumo to be the fallback is a good idea, and we can set more specific ones as needed

[dlarrick]

I merged the fallback. Let me know how things look; if we're good I'll merge this to master and make a new release.

[dmcc]

Thanks @dlarrick! I've tested the latest version and it looks good.

[dmcc]

@dlarrick and @brgaulin Does it work for you too?

[dlarrick]

Sorry, my day job has been stupid busy. I hope to get a release out this weekend.

[dmcc]

No worries, I've been there 😃