IP Discovery is not working on MacOs

[niemyjski]

I ran the following command (latest stable of everything)

python3 -m homekit.discover --log DEBUG
....
2019-08-18 09:48:58,415 __init__.py:0099 DEBUG candidate data {b'c#': b'1', b'ff': b'8', b'id': b'XX:XX:XX:XX:XX:XX', b'md': b'WEBOS', b'pv': b'1.1', b's#': b'1', b'sf': b'1', b'ci': b'31', b'sh': b'3mxJYw=='}

Traceback (most recent call last):
  File "/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Users/blake/Library/Python/3.7/lib/python/site-packages/homekit/discover.py", line 51, in <module>
    results = Controller.discover(args.timeout)
  File "/Users/blake/Library/Python/3.7/lib/python/site-packages/homekit/controller/controller.py", line 90, in discover
    return discover_homekit_devices(max_seconds)
  File "/Users/blake/Library/Python/3.7/lib/python/site-packages/homekit/zeroconf_impl/__init__.py", line 102, in discover_homekit_devices
    info.properties
  File "/Users/blake/Library/Python/3.7/lib/python/site-packages/homekit/zeroconf_impl/__init__.py", line 180, in parse_discovery_properties
    d['category'] = Categories[int(category)]
  File "/Users/blake/Library/Python/3.7/lib/python/site-packages/homekit/model/categories.py", line 94, in __getitem__
    raise KeyError('Item {item} not found'.format(item=item))
KeyError: 'Item 31 not found'

I'm guessing it has to do with not supporting my LG c9 tv (wonder what it will do when I get the homekit component for my shower :D). https://www.theverge.com/2019/7/24/20708380/lg-apple-airplay-2-homekit-2019-oled-microcell-uhd-tv

[jlusiardi]

looks like #131 and #136 is still open. The listing of IDs from Table 12-3 Accessory Categories are limited. There are new categories in new devices but I do not know them. Should make a generic solution and map unknown categories to "Category 31' in this case?

[jlusiardi]

@niemyjski can you try to use https://github.com/jlusiardi/homekit_python/tree/fix_158_unknown_categories in HASS.io or directly to do python3 -m homekit.discover --log DEBUG?

[niemyjski]

Yes, is there an easy way to update to this branch using pip3? Thanks -Blake Niemyjski

On Sun, Aug 18, 2019 at 4:19 PM Joachim Lusiardi notifications@github.com wrote:

@niemyjski https://github.com/niemyjski can you try to use https://github.com/jlusiardi/homekit_python/tree/fix_158_unknown_categories in HASS.io or directly to do python3 -m homekit.discover --log DEBUG?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jlusiardi/homekit_python/issues/158?email_source=notifications&email_token=AAHZFIZIU6NR6CTSATMKYNDQFG4GDA5CNFSM4IMTG4A2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4RINNA#issuecomment-522356404, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHZFI76T7W4Y727CMGUB3LQFG4GDANCNFSM4IMTG4AQ .

[jlusiardi]

Hi, should be doable with pip3 install --user -e git+https://github.com/jlusiardi/homekit_python.git@fix_158_unknown_categories#egg=homekit -Joachim

[niemyjski]

Sweet! That worked

Name: LG webOS TV D6DC._hap._tcp.local.
Url: http_impl://10.0.72.47:44456
Configuration number (c#): 1
Feature Flags (ff): No support for HAP Pairing (Flag: 8)
Device ID (id): XX:XX:XX:XX:XX:XX
Model Name (md): WEBOS
Protocol Version (pv): 1.1
State Number (s#): 1
Status Flags (sf): Accessory has not been paired with any controllers. (Flag: 1)
Category Identifier (ci): Unknown Category #31 (Id: 31)

[jlusiardi]

Hey @niemyjski , cool! Can you also pair it and use the other homekit tools? Joachim

[Jc2k]

@jlusiardi in case of delays with timezones i figured i should post the original exception from the Home Assistant side of things. When trying to verify the pairing code with the TV we are seeing:

2019-08-15 05:07:07 ERROR (MainThread) [homeassistant.components.homekit_controller.config_flow] Pairing attempt failed with an unhandled exception
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/homekit_controller/config_flow.py", line 250, in async_step_pair
    await self.hass.async_add_executor_job(self.finish_pairing, code)
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.7/site-packages/homekit/controller/controller.py", line 391, in finish_pairing
    pairing = perform_pair_setup_part2(pin, str(uuid.uuid4()), write_fun, salt, pub_key)
  File "/usr/local/lib/python3.7/site-packages/homekit/protocol/__init__.py", line 173, in perform_pair_setup_part2
    assert response_tlv[0][0] == TLV.kTLVType_State and response_tlv[0][1] == TLV.M4, \
IndexError: list index out of range

@niemyjski is running 0.97.2 here, so the homekit_python version will be 0.15.0.

[niemyjski]

I'll try pairing it today or tomorrow. I didn't know what I needed to specify for the -f flag. @Jc2k responded to that question last night. Seems like that should be optional as a file could be created with the device name in a sub directory of the install folder.

[niemyjski]

Hello,,

Sorry about the delay the past week has been crazy. Here is the pairing logs where it fails.

➜ python3 -m homekit.pair -d XX:XX:XX:XX:XX:XX -a mytv -f pairing.json --log DEBUG
2019-08-27 05:57:08,812 __init__.py:0106 DEBUG #1 ios -> accessory: send SRP start request
2019-08-27 05:57:08,813 tlv.py:0134 DEBUG sending [
  6: (1 bytes/<class 'bytearray'>) 0x01
  0: (1 bytes/<class 'bytearray'>) 0x01
]

2019-08-27 05:57:08,813 tlv.py:0117 DEBUG receiving [
  6: (1 bytes/<class 'bytearray'>) 0x01
  0: (1 bytes/<class 'bytearray'>) 0x01
]

2019-08-27 05:57:08,813 __init__.py:0060 DEBUG write message: [
  6: (1 bytes/<class 'bytearray'>) 0x01
  0: (1 bytes/<class 'bytearray'>) 0x01
]

2019-08-27 05:57:09,023 tlv.py:0117 DEBUG receiving [
  6: (1 bytes/<class 'bytearray'>) 0x02
  3: (384 bytes/<class 'bytearray'>) 0xa4716b8b96d60a92ff6c28c7d00085cd420aaccea34530f300c42f0d3776bc21ee2885e3abcaf2ef4d8466b45801080968384833463ee96ac72edcff2b3b7d506aa16d50524b203874e52f4ca4ff807d24c39c1807ad95f28c12788a930afe8f33aa19fafe42f99f481d9adae48341c75ce4d1e65b2c9f7a34a6e0bdbe0cecfcb017c373557adb7a5d8d470edea65913b877924b92721774b4e325c9c7e3bb988c8cf366308393f4b1efa70a29feff34587079bf103227e8786a9cd0a89ef871ae17ba84d03c9e88d1929ea4df010cd50bbec6a108b582d3c3123b9b81a15aee636fb7f9d1a637c775966d0331f2338eb600f1e22c0f2b46eb27eec9cc80af12d3ad28de55473283a4673ed661f929d7053318720e00ec233725f89b795a3ef393f441eddf1e6998dc31e032e16a53c8052eec5b3699feb3eb3fac89ffdc7d30bc1bd4f47d7779c0ee3736280785053b0a0e32fb272e9c4972e25d6c73349fb43c1eada186ce0c539b8648858b185880fa6195590d9519f70af5eed1832978e3
  2: (16 bytes/<class 'bytearray'>) 0x691039f6b6c8067498ff6166cc336825
]

2019-08-27 05:57:09,024 __init__.py:0067 DEBUG response: [
  6: (1 bytes/<class 'bytearray'>) 0x02
  3: (384 bytes/<class 'bytearray'>) 0xa4716b8b96d60a92ff6c28c7d00085cd420aaccea34530f300c42f0d3776bc21ee2885e3abcaf2ef4d8466b45801080968384833463ee96ac72edcff2b3b7d506aa16d50524b203874e52f4ca4ff807d24c39c1807ad95f28c12788a930afe8f33aa19fafe42f99f481d9adae48341c75ce4d1e65b2c9f7a34a6e0bdbe0cecfcb017c373557adb7a5d8d470edea65913b877924b92721774b4e325c9c7e3bb988c8cf366308393f4b1efa70a29feff34587079bf103227e8786a9cd0a89ef871ae17ba84d03c9e88d1929ea4df010cd50bbec6a108b582d3c3123b9b81a15aee636fb7f9d1a637c775966d0331f2338eb600f1e22c0f2b46eb27eec9cc80af12d3ad28de55473283a4673ed661f929d7053318720e00ec233725f89b795a3ef393f441eddf1e6998dc31e032e16a53c8052eec5b3699feb3eb3fac89ffdc7d30bc1bd4f47d7779c0ee3736280785053b0a0e32fb272e9c4972e25d6c73349fb43c1eada186ce0c539b8648858b185880fa6195590d9519f70af5eed1832978e3
  2: (16 bytes/<class 'bytearray'>) 0x691039f6b6c8067498ff6166cc336825
]

2019-08-27 05:57:09,024 __init__.py:0118 DEBUG #3 ios -> accessory: send SRP verify request
Enter device pin (XXX-YY-ZZZ): 739-34-736
2019-08-27 05:57:33,755 tlv.py:0134 DEBUG sending [
  6: (1 bytes/<class 'bytearray'>) 0x03
  3: (384 bytes/<class 'bytearray'>) 0x73520bb9c3cd416bdf68955569dd1fb506dd851b8ce3ae34a4dfcc2f48edf953bfceccb9ea02fcf10cab8d24cc94b50835b23672debf0a4bf2b35dc030627c8e7060cd1414af3d89e0fc060aa432924a3c18fbf4b77bb703937fb3b55c7c50469b641ee21c532620a20ed7b5ee1f714fe24a33c988ea63f33e3749f0fe23335fe919ba9bec6c2ffbd911f4ee9d970e2ca1225a69350b403168eae727b71af6ad573b9a7f145a441c6da73b1d29c934598d46debd44d6696eb935d98ee0f0db298f051a487ee37334a77538e5668718a9aeb8121603f9dedbddbfa129a7f153fdb4f97602504eb5dee5094b8dc5123bb6354c319f6e1d2bf7429ca95359177dec0b5afbd11155bd07d66678e59f636355a56111c08e306e082bcf0855aeb51cb965d7de65f3618249a3674780c1d690169e71a7e4d627a11ad1a110514fa7368e0289bd8f0fdee7abec1420b15bcf9e46f0a41a547d9873dc3a42accb0cbb613b5ac33fa0e938ca65c42dd18c71e27735a3f2cef1e9d6b085d9eeca84ec790e8d
  4: (64 bytes/<class 'bytearray'>) 0xba082ff088e539e3176a90ce49eb042f5ec1af70796dd72d9f39fe679b84f99848e3f423bdcadf9d7d28d07d509588c791e4f93f55b0cbea0b4957eec741b628
]

2019-08-27 05:57:33,755 tlv.py:0117 DEBUG receiving [
  6: (1 bytes/<class 'bytearray'>) 0x03
  3: (384 bytes/<class 'bytearray'>) 0x73520bb9c3cd416bdf68955569dd1fb506dd851b8ce3ae34a4dfcc2f48edf953bfceccb9ea02fcf10cab8d24cc94b50835b23672debf0a4bf2b35dc030627c8e7060cd1414af3d89e0fc060aa432924a3c18fbf4b77bb703937fb3b55c7c50469b641ee21c532620a20ed7b5ee1f714fe24a33c988ea63f33e3749f0fe23335fe919ba9bec6c2ffbd911f4ee9d970e2ca1225a69350b403168eae727b71af6ad573b9a7f145a441c6da73b1d29c934598d46debd44d6696eb935d98ee0f0db298f051a487ee37334a77538e5668718a9aeb8121603f9dedbddbfa129a7f153fdb4f97602504eb5dee5094b8dc5123bb6354c319f6e1d2bf7429ca95359177dec0b5afbd11155bd07d66678e59f636355a56111c08e306e082bcf0855aeb51cb965d7de65f3618249a3674780c1d690169e71a7e4d627a11ad1a110514fa7368e0289bd8f0fdee7abec1420b15bcf9e46f0a41a547d9873dc3a42accb0cbb613b5ac33fa0e938ca65c42dd18c71e27735a3f2cef1e9d6b085d9eeca84ec790e8d
  4: (64 bytes/<class 'bytearray'>) 0xba082ff088e539e3176a90ce49eb042f5ec1af70796dd72d9f39fe679b84f99848e3f423bdcadf9d7d28d07d509588c791e4f93f55b0cbea0b4957eec741b628
]

2019-08-27 05:57:33,755 __init__.py:0060 DEBUG write message: [
  6: (1 bytes/<class 'bytearray'>) 0x03
  3: (384 bytes/<class 'bytearray'>) 0x73520bb9c3cd416bdf68955569dd1fb506dd851b8ce3ae34a4dfcc2f48edf953bfceccb9ea02fcf10cab8d24cc94b50835b23672debf0a4bf2b35dc030627c8e7060cd1414af3d89e0fc060aa432924a3c18fbf4b77bb703937fb3b55c7c50469b641ee21c532620a20ed7b5ee1f714fe24a33c988ea63f33e3749f0fe23335fe919ba9bec6c2ffbd911f4ee9d970e2ca1225a69350b403168eae727b71af6ad573b9a7f145a441c6da73b1d29c934598d46debd44d6696eb935d98ee0f0db298f051a487ee37334a77538e5668718a9aeb8121603f9dedbddbfa129a7f153fdb4f97602504eb5dee5094b8dc5123bb6354c319f6e1d2bf7429ca95359177dec0b5afbd11155bd07d66678e59f636355a56111c08e306e082bcf0855aeb51cb965d7de65f3618249a3674780c1d690169e71a7e4d627a11ad1a110514fa7368e0289bd8f0fdee7abec1420b15bcf9e46f0a41a547d9873dc3a42accb0cbb613b5ac33fa0e938ca65c42dd18c71e27735a3f2cef1e9d6b085d9eeca84ec790e8d
  4: (64 bytes/<class 'bytearray'>) 0xba082ff088e539e3176a90ce49eb042f5ec1af70796dd72d9f39fe679b84f99848e3f423bdcadf9d7d28d07d509588c791e4f93f55b0cbea0b4957eec741b628
]

2019-08-27 05:57:33,848 tlv.py:0117 DEBUG receiving [
]

2019-08-27 05:57:33,849 __init__.py:0067 DEBUG response: [
]

2019-08-27 05:57:33,849 __init__.py:0169 DEBUG #5 ios -> accessory: send SRP exchange request
list index out of range
2019-08-27 05:57:33,849 pair.py:0085 DEBUG list index out of range
Traceback (most recent call last):
  File "/Users/blake/src/homekit/homekit/pair.py", line 78, in <module>
    finish_pairing(pin_function())
  File "/Users/blake/src/homekit/homekit/controller/controller.py", line 391, in finish_pairing
    pairing = perform_pair_setup_part2(pin, str(uuid.uuid4()), write_fun, salt, pub_key)
  File "/Users/blake/src/homekit/homekit/protocol/__init__.py", line 173, in perform_pair_setup_part2
    assert response_tlv[0][0] == TLV.kTLVType_State and response_tlv[0][1] == TLV.M4, \
IndexError: list index out of range

[Jc2k]

To me, this looks like a completely normal M1/M2/M3 exchange, then the TV abruptly returns nothing / closes the connection instead of sending us an M4. There are no extra fields or new reserved flags suddenly being used in the M2 to indicate we should behave differently. I wondered if they rolled out a new pairing scheme (different salt? pub key?) There is no new spec, though. That likely means it failed the SRP proof? But that kind of error should (according to the spec) yield an M4 response with a kTLVType_Error.

[jlusiardi]

@niemyjski and @jc2k: i would like to close this and move the issue to #170, since this is not discovery related anymore and we seem to have the same issue with at least the Eve Energy 1EC0 plug as well.

[Jc2k]

Fine by me!

[jlusiardi]

Continued in #170!