Unable to pair HomeKit device: Koogeek LS1

Quentame commented 5 years ago

Home Assistant release with the issue: 0.91.4

Last working Home Assistant release (if known): N/A

Operating environment (Hass.io/Docker/Windows/etc.):

System param	value
arch	x86_64
dev	false
docker	true
hassio	false
os_name	Linux
python_version	3.7.3
timezone	Europe/Paris
version	0.91.4
virtualenv	false

Component/platform:

https://www.home-assistant.io/components/homekit_controller/

Description of problem:

Hello,

I am trying to pair my Koogeek LS1 (my first HomeKit HA pairing) for an automation, but I am facing some problems :

HA recognize the device hours after I powered it
I have two Koogeek LS1 actually and when HA recognize them, all friendly names are "LS1", so ... how should I know which one is it ? (Display "Koogeek LS1" may be better, and when this name isn't unique it may be nice to append the MAC address in parentheses :wink:)
After clicking on the configuration button, it is asking me for the HomeKit code, nice ! But could you add the pattern (if there is) ? Because I don't know if I should enter XXX-XX-XXX (which is my pattern) or XXXXXXXX.
No success or fail feedback are comming to the configure popup (that also explain my disappointment of the point 2 and 3)
No log are printed !

I did : I solved the problem of the 2 LS1 by unplugged one (old fashon way :smile:). I reset the LS1, which was previously paired with my iPhone. I tryed all pattern of the HomeKit code (XXX-XX-XXX and XXXXXXXX) I tryed to just give the Wi-Fi to the LS1 but to pairing with my iPhone. Of course, restart HA and LS1. I looked at issues in GitHub, but no log to find any good match.

Nothing works.

I have the /config/.homekit folder created and empty.

configuration.yaml

discovery:
  enable:
    - homekit

Traceback (if applicable):

No log at all :cry:

Additional information:

Maybe linked with #23189, #18949, #23172 and #15692

Jc2k commented 5 years ago

Hi just wanted to ack your ticket and say I will try to help when I am at my desk. I have the same device here so pretty confident we can get it work. I am actually working on revamping the pairing experience but it won’t land until 0.94.

pmatias commented 5 years ago

@Jc2k Thanks for the hard work, I appreciate the effort.

Koogeek appliances are just crap, I'm just too late to return them. So I'm looking forward to this :)

Jc2k commented 5 years ago

Have actually managed to fix point (2) in my local dev environment, but it's going to be in 0.94 (lots of large pending changes first).

The best workaround for (1) atm is to restart HA after your device is in pairing mode. HA will do a scan at boot and after about 30s your device should show up. I'm not sure how frequent scans are after that. I think the core team might be making improvements around discovery but I can't help with this bit atm.

For (3), it is definitely always XXX-XX-XXX for all HomeKit devices, regardless of what the label says. It's part of the crypto implementation so if a manufacturer deviates from this it wont work with an iPhone. Validation has been added for this and its trickling its way down from unmerged Github branches. But we need to update the input text to be clearer too.

There should normally be a popup! So this must be an 'unusual' error.

On this version of HA i'd expect LS1 to work so can you confirm it's version for me.

Then one LS1 at a time:

if you have /config/configuration.yaml, make sure /config/.homekit exists (you said that it did, but i wanted to make sure it was relative to your configuration.yaml in particular. I often say /config/.homekit when its just a path i made up).
reset your LS1 (press and hold button till it glows red)
pair it with your iPhone
unpair it (by tapping on its detail panel and choosing remove accessory)
restart HA (this will remove any pairings in memory and force discovery to run)
try to pair

I followed this procedure with my LS1 and it works.

Quentame commented 5 years ago

Hi @Jc2k !

My versions are HA 0.91.4 and Koogeek LS1 2.3.6 (all latest updates).

I do have the config/configuration.yaml file in the same directory as the .homekit directory.

I followed your steps but after 15 mins HA restared, no configurator.ls1 appears from the notification panel. Perhaps the nmap_tracker is finding the light strip on the network ! Is there a way to manually trigger the discovery ? Like in services ? (looked, but can't find)

0.94.0 looks promising, already waiting for it !

Thanks for the quick answer and for your contributions and implication about this component, thumbs up ! 👍

pmatias commented 5 years ago

I come to the point where I see HA showing me the configurator option but it won't accept the HomeKit code (I use the format XXX-XX-XXX but I did try XXXXXXXX just in case).

I can wait until 0.94, there's so much else I want to learn about HA while I wait :D

jcalderon71 commented 5 years ago

@Jc2k Hi, I have 3 wifi switches (Insignia) which have an independent control app, but are also HomeKit compliant and have Homekit PIN for setup, I am running ubuntu on a docker with hassio 0.91.4
I reset the switches and delete it from the native app "insignia connect"
I am adding 1 by 1 in the app because all 3 has the same entity_id name, when the setup its done in the app for the 1st switch, I restarted hassio, in the front UI configurator link I entered the PIN code, the 1st time nothing happened jus the cursor spin for 1 minute, I closed the popup message and opened again, re-enter the code and this time I got this message:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/homeassistant/components/websocket_api/commands.py", line 122, in handle_call_service
    connection.context(msg))
  File "/usr/local/lib/python3.7/site-packages/homeassistant/core.py", line 1138, in async_call
    self._execute_service(handler, service_call))
  File "/usr/local/lib/python3.7/site-packages/homeassistant/core.py", line 1160, in _execute_service
    await handler.func(service_call)
  File "/usr/local/lib/python3.7/site-packages/homeassistant/components/configurator/__init__.py", line 221, in async_handle_service_call
    call.data.get(ATTR_FIELDS, {}))
  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/homeassistant/components/homekit_controller/connection.py", line 127, in device_config_callback
    self.controller.perform_pairing(self.hkid, self.hkid, code)
  File "/usr/local/lib/python3.7/site-packages/homekit/controller/controller.py", line 329, in perform_pairing
    raise AlreadyPairedError('Alias "{a}" is already paired.'.format(a=alias))
homekit.exceptions.AlreadyPairedError: Alias "5A:81:84:CA:1A:13" is already paired.

I restarted hassio one more time assuming that the switch was already pair with my HA and nothing, in the HA UI the configurator window still there, if I re-enter the PIN code again I got the message:

"This accessory is already paired to another device. Please reset the accessory and try again"

but not error message on the logger. I do have the config/configuration.yaml file but NOT the .homekit directory

thanks for your help

PS: In one of my tries after estart HA got this eror in the logger:

Error doing job: Fatal error on transport TCPTransport (error status in uv_stream_t.shutdown callback) OSError: [Errno 107] Socket not connected

I dont know if is related or not

Jc2k commented 5 years ago

@jcalderon71 Thanks for the detailed report.

The problem is the .homekit directory not existing. Pairing works but it fails to save the pairing. The second time the pairing already exists in memory so you get an AlreadyPairedError. Then when you restart it clears out the pairing from memory, but the device still thinks its paired. So you need to reset the device to try again.

The .homekit directory is supposed to be created automatically but on 0.91 it isn't. In 0.94 the directory is going away entirely as homekit_controller embraces all the modern and up to date API's for integration building. But for long and boring reasons some of that code got merged too soon. It's fixed in 0.92 but in the meantime you need to make the .homekit directory and try again. You need to follow the same procedure I posted already:

Make sure the .homekit directory exists
Reset your device so that it shows as pairable again
If the switches have now fallen off your wifi, pair with your iPhone then unpair (by tapping on its detail panel and choosing remove accessory)
Restart HA (this will remove any pairings in memory and force discovery to run)
Try to pair

It will take a while to pair. The process isn't as optimised as it could be and there is a cryptographic exchange that is quite slow on some devices. But it should go through and you should find you have a pairing.json file in your .homekit directory. If that file exists pairing has worked.

The 2nd error (The OSError) is unrelated and is probably nothing to worry about.

Jc2k commented 5 years ago

@Quentame am baffled by your discovery issue so i'm going to start from the basics. Can you post the changes you made to your configuration.yaml to try and enable the homekit controller?

jcalderon71 commented 5 years ago

@Jc2k Thanks for the advice, I created the .homekit directory and so far the 1st switch is working

Quentame commented 5 years ago

@Jc2k

Here is part of my configuration.yml :

# Discover some devices automatically
discovery:
  enable:
    - homekit

# Tracking
device_tracker:
    # iCloud
  - platform: icloud
    username: !secret icloud_mail
    password: !secret icloud_password
    gps_accuracy_threshold: 150

    # Network scan
  - platform: nmap_tracker
    hosts: 192.168.0.1/24
    home_interval: 10
    exclude:
      - 192.168.0.10 # NAS
      - 192.168.0.13 # TV
      - 192.168.0.21 # Hue Bridge

I'm gonna update to 0.92.0 tonight to see if there is some changes ...

python3 -m homekit.discover --log DEBUGas found in #23259 (which the description of the problem is the same), returns :

Jc2k commented 5 years ago

And can you see that the Koogeek is on your network? (It looks like 2 different discovery mechanisms don’t think it is)

Quentame commented 5 years ago

Yes I can

It is « LED Cuisine », the « LED Canapé » is disconnected due to the names in the configurator which are both « LS1 ». So no more red light « climbing to the wall » coming from the sofa, until I can pair the kitchen light strip :D

Absent => Away

Maison => Home

Just in case ;)

Jc2k commented 5 years ago

I feel like i'm missing something obvious with your case @Quentame!

Discovery for homekit is turned on correctly
The light strip indicators in the UI - are they from the nmap_tracker? So if i understand correctly - they show Cuisine is inded on the network, even though configurator currently can't see them?
The devices are currently unpaired (no pairing attempts with HA since a reset, not currently paired with an iPhone, etc)
Discovery outside of home-assistant can't see the devices at all, only the Hue.
Discover inside HA can see them sometimes because you said you can see the configurator has 2 LS1's.
But sometimes it doesn't show up in HA even after hours?

It just doesn't make sense with anything i've seen with the LS1! The python3 -m homekit.discover command should always see the LS1, even if its paired. So i would normally assume there was something weird going on with bonjour on your network - but the Phillips Hue is visible which proves it works.

When you can see that Cuisine is on the network AND you can't see a configurator, can your iphone see that the LS1 is available to pair? Is the discover command still not returning anything at that time?

Quentame commented 5 years ago

Hi @Jc2k !

To be clearer, I made a video :sweat_smile:

https://photos.app.goo.gl/mLxcWUKrMJfdur21A

https://photos.app.goo.gl/dpXczpzhxWnkfnDz5

HA restarted around 8:05PM, at 10:53PM I got the configurator (forgot to look more often)

Hope it helped.

PS: sorry for my English it’s been a long time.

Jc2k commented 5 years ago

Thank you for all the effort you put into this, and your english is pretty amazing actually. I wish my French was half as good (it's not even close :cry:).

Unfortunately i'm still baffled by whats going on 😭

I'm at a complete loss as to why discovery sometimes works but can take hours to do so. I would like to leave it and concentrate on pairing but i think its actually part of the problem. There is a mismatch between the homekit_python API and the HA API which means that homekit_python does its own discovery as well when you try to pair. This is not normally a problem, but in your case homekit_python's discovery never seems to work (e.g. python3 -m homekit.discover). So I think we have to get to the bottom of that...

Are you able to easily run docker containers outside of your NAS or get an interactive terminal on a docker container on your NAS? I want to try and right some discovery diagnostic scripts and match them to how you can easily run them.

Quentame commented 5 years ago

I can run HA in Docker on my Mac or maybe the interactive mode is working on the NAS throw SSH (not available on the NAS Docker Web App).

Jc2k commented 5 years ago

OK - docker on mac should be doable. Do you use brew at all? I do most of my dev with the python3 package from brew so if you already use that this will be super easy.

Quentame commented 5 years ago

I do :beer: my Mac yep

Jc2k commented 5 years ago

Hi @Quentame - sorry for not getting back sooner.

0.14.0 of homekit_python has just released - have submitted a PR to update to it (#23562). I don' /think/ that will help with your situation but if you want to try it then its worth a shot.

The other thing i want to rule out is if a longer discovery interval will help. You can actually specify how long the discover command should wait for with the -t option. Can you try:

python3 -m homekit.discover -t 60

I'm wondering if the default (30s) is too short for your device. That would be weird given its not for my LS1, but it seems to match with what was happening in the video. So I want to see if there is a value that consistently is long enough. Try 60, 180, 300, etc. Is there a value that is always long enough? Whats the lowest value that works 5 times in a row? If you power cycle the LS1 does it still work 5 times in a row?

HA discovery is different to homekit.discover. If i understand it correctly it runs for 30s every X minutes, so it could be that we could discover the device much quicker if there was a longer discovery window.

ghost commented 5 years ago

Hey there @Jc2k, mind taking a look at this issue as its been labeled with a integration (homekit_controller) you are listed as a codeowner for? Thanks!

This is a automatic comment generated by codeowners-mention to help ensure issues and pull requests are seen by the right people.

Jc2k commented 5 years ago

@Quentame any luck with the command above?

Quentame commented 5 years ago

Hi @Jc2k !

Sorry for not answering, I had kinda busy weeks. Already 21 days ago :scream: !!

So, with : python3 -m homekit.discover -t 120 running inside the Docker container, I could see my light strip almost every time but HA not.

Then, I kept triggering the command to maintain a certain connection and HA discovered the strip, it tooks around 20 min.

But since I reboot HA, the strips became unavailable : Capture du 2019-05-21 13-49-23

Maybe I have network or device issues, I don't know.

Thanks again.

Jc2k commented 5 years ago

Right now on a restart the entities are only loaded after discovery happens again. So even though it worked enough to pair and it records the IP address in the pairing it wont load the entity again until the next discovery finds the Bonjour mdns record. For whatever reason HA's zeroconfig implementation isn't managing to do this repeatedly.

It's weird that the command i gave you seems to be reliable because it uses the same underlying zeroconfig library.

There are a couple of things that will help your specific case:

0.94 will migrate to HA Config Entries. This will enable the lighstrips to be loaded on HA startup without relying on discovery to work
There is a PR to move the discovery mechanism to use aiozeroconf. It is always monitoring mdns records so should work better in this case (the current one scans for 30s, sleeps for X minutes, then repeats).

But doesn't fix the underlying issue, which feels networky but im out of ideas.

Quentame commented 5 years ago

I can automate the homekit.discovery command at HA boot and see what happens, also check my router settings.

I upgrade HA uselly the day after the release, I'll let you know about the famous 0.94 benefits.

Jc2k commented 5 years ago

Both of the things i mentioned above are in 0.94. So if you manage to pair them now they should stay working after HA restarts.

Quentame commented 5 years ago

Okey, will test.

Actually, I made automations like I said, and it was working nice (usually < 5 min to be recognize by HA). I will past my code when I can reach it.

I said "will test" because my NAS, which was hosting HA, just failed to death two days ago ... :disappointed: No data should be lost but since I didn't really complete my HA config, I haven't configure backups for it (genius). Kinda end of next week should be fine.

Jc2k commented 5 years ago

Hope you got everything running again. Were you able to test yet?

Quentame commented 5 years ago

Hey !

It was longer because I returned it, the shop don’t have replacement pieces. I get it back 4 days ago, but I also change my IPS during this time to go fiber, and router change place ... so I should move the UPS, Hue bridge and Z-wave ... long story 😅

Working with it the week end !

Quentame commented 5 years ago

Hi again !

So, I've boot HA (0.93.4 I suppose) on the new NAS and of course the LS1s were still unavailable. I've updated HA to 0.95.4, still the same. So as my LS1s were paired with the old NAS I decided to deleted the entities from HA (an alert told me to disabled homekit_controller to "take the effect" properly or something) I reseted, linked to my iPhone, updated LS1s, and removed them from the Home app. I've disabled HomeKit in the discovery component (as it's enabled by default now), restart HA. Enabled again and restart (about the alert I received when I deleted the entities). Since all of that HA didn't recognized my LS1s, no notifications.

Did I made something wrong ? How can I "reset" the homekit_controller to install the LS1 properly on the new NAS ?

My homekit.discovery automation (which was working before changing the NAS, paired with the old I guess) :

configuration.yaml

shell_command:
  search_homekit: python3 -m homekit.discover -t 120

automation/homekit.yaml

- alias: homekit_find_devices
  trigger:
    - platform: homeassistant
      event: start
    - platform: time_pattern
      minutes: 5
  condition: 
    condition: template
    value_template: >
      {{ states('light.koogeek_ls1_205cad') == 'unknown' or states('light.koogeek_ls1_2043cf') == 'unknown' }}
  action:
    service: shell_command.search_homekit

Thanks.

Jc2k commented 5 years ago

Is the HA container deployed with host mode networking?

Jc2k commented 5 years ago

And is the zeroconf component turned on?

Quentame commented 5 years ago

Host mode : ON Zeroconf component: NO (docs)

I thought the Zeroconf was part of the core, but obviously not, just found out. I apparently didn't read the release notes entirely, shame on me.

Will update my conf.

Quentame commented 5 years ago

OK, so zeroconf is awesome, it's working perfectly now !!!

I plugged only one LS1, add the zeroconf component and restart HA, the LS1 was recognized directly after HA started.

And then I plugged the other one, and it took 10s to discover it.

I'm closing the issue.

home-assistant / core

Unable to pair HomeKit device: Koogeek LS1 #23238