@Leiesoldat sf=0 means that the accessory is paired to something. You need to either delete it from whatever “Home” it is paired to or factory reset it. Both should work.
@lambdafunction sf was indeed 0 in my bulbs. So I did a factory reset and did not add them to the Nanoleaf app anymore. HA was then able to find the bulb and I am now able to control it from there.
Some early feedback on the integration:
- There’s a bit of a delay (1-2 seconds) the first time you control the bulb (either turn it on or off). Subsequent commands after that gets instant response. Then it’ll be slow again after several minutes of not issuing commands.
- If I turn off the physical switch connected to the bulb, HA does not recognize that as an unreachable device.
At this point, I’m just glad that we now have the ability to control the bulbs in HA. The native Nanoleaf app is just too finicky to be considered useful 
Hats off to everyone who contributed to this @Jc2k @lambdafunction @TheTofu
@spanky13 glad to hear you got it working! It sounds like you may be connected over BLE? You can check from the HA console:
jq '.data.entries[] | select(.domain == "homekit_controller") | select(.data.Connection == "BLE")' /mnt/data/supervisor/homeassistant/.storage/core.config_entries
Since you’ve got Android, you should be able to add the bulbs to the app again to get them on Thread. Or wait for the HA service, but that will be 2022.9 at the earliest.
Hmm, having various issues since I upgraded to HA 2022.8.3, some of which are homekit related.
Seems like occasionally the bulbs will lose connection and I’m not sure why, I may also just have some kind of network DNS issue, not sure if that would cause what I’m seeing:
Logger: homeassistant
Source: components/homekit_controller/config_flow.py:288
First occurred: 7:01:53 AM (148 occurrences)
Last logged: 10:55:12 PM
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/discovery_flow.py", line 74, in _async_process_pending_flows
await gather_with_concurrency(
File "/usr/src/homeassistant/homeassistant/util/async_.py", line 199, in gather_with_concurrency
return await gather(
File "/usr/src/homeassistant/homeassistant/util/async_.py", line 197, in sem_task
return await task
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 222, in async_init
flow, result = await task
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 249, in _async_init
result = await self._async_handle_step(flow, flow.init_step, data, init_done)
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 359, in _async_handle_step
result: FlowResult = await getattr(flow, method)(user_input)
File "/usr/src/homeassistant/homeassistant/components/homekit_controller/config_flow.py", line 288, in async_step_zeroconf
await conn.pairing.reconnect_soon()
File "/usr/local/lib/python3.10/site-packages/aiohomekit/controller/coap/pairing.py", line 228, in reconnect_soon
address = self.pairing_data["AccessoryAddress"]
KeyError: 'AccessoryAddress'
Logger: aiohomekit.controller.coap.pdu
Source: components/homekit_controller/connection.py:629
First occurred: 9:43:42 AM (19 occurrences)
Last logged: 10:48:44 PM
Transaction 0 failed with error 6 (Invalid request)
Logger: aiohomekit.controller.coap.connection
Source: components/homekit_controller/connection.py:629
First occurred: 7:47:41 AM (91 occurrences)
Last logged: 10:55:42 PM
CoAP POST returned unexpected code <aiocoap.Message at 0x7fdf6f1ea350: Type.ACK 4.04 Not Found (MID 39198, token a8d5) remote <UDP6EndpointAddress [fdee:b12:3711:0:a015:26c6:b359:f13c] (locally 2603:8000:f101:2930:2459:9c09:ceb8:59cb%ens18)>>
CoAP POST returned unexpected code <aiocoap.Message at 0x7fdf6e732c50: Type.ACK 4.04 Not Found (MID 25189, token 4fda) remote <UDP6EndpointAddress [fdee:b12:3711:0:c65b:4519:b08e:d483] (locally 2603:8000:f101:2930:2459:9c09:ceb8:59cb%ens18)>>
Decryption failed, desynchronized? Counter=11/14
Decryption failed, desynchronized? Counter=12/14
Decryption failed, desynchronized? Counter=14/16
Slightly off-topic, but if you do have Nanoleaf gear connected via HomeKit BLE, there is a bunch of work in flight that will make things much faster over the coming months.
- Looks like HA OS 9 will switch dbus implementations to https://github.com/bus1/dbus-broker. Early testing shows this is twice as fast at reading. https://github.com/home-assistant/operating-system/pull/2053
- There are more changes here: https://github.com/altdesktop/python-dbus-next/pull/126.
- And here: https://github.com/hbldh/bleak/pull/923.
All of these changes together have a huge impact on HomeKit BLE performance.
1 Like
@TheTofu - at least the first one looks like my bad and probably caused by: https://github.com/Jc2k/aiohomekit/pull/133. Probably stick on .2 for now if you can.
I’m having trouble pairing the Essential bulb.
The environment:
- RPI 4 running on DietPi
- HA container: v2022.8.3
- both code hacks in the python scripts are done
- Essential bulb is paired to the BR (NL Shapes), working in NL android app, and available over Thread
- Essential bulb can be seen in Service Browser (android app)
- Essential bulb is auto-discovered (after turning it off and on after 5-10 secs) by HA which ask to integrate it through Homekit Controller
When trying to integrate it, I have some Timeout error every time (tried many times, turning off/on the bulb, reset etc).
Error log:
2022-08-11 09:34:02.634 WARNING (MainThread) [aiohomekit.controller.coap.connection] Pair setup 1/2 failed!
2022-08-11 09:34:02.642 ERROR (MainThread) [homeassistant.components.homekit_controller.config_flow] Pairing attempt failed with an unhandled exception
Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/tasks.py", line 456, in wait_for
return fut.result()
asyncio.exceptions.CancelledError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/homekit_controller/config_flow.py", line 502, in async_step_pair
self.finish_pairing = await discovery.async_start_pairing(self.hkid)
File "/usr/local/lib/python3.10/site-packages/aiohomekit/controller/coap/discovery.py", line 57, in async_start_pairing
salt, srpB = await self.connection.do_pair_setup(
File "/usr/local/lib/python3.10/site-packages/aiohomekit/controller/coap/connection.py", line 291, in do_pair_setup
response = await asyncio.wait_for(
File "/usr/local/lib/python3.10/asyncio/tasks.py", line 458, in wait_for
raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
Any idea on this ?
I could try to make it work over BLE only to test, but I dont know how to force this, as it’s over CoAP right now.
@TheTofu the last one is the “normal” series of errors when comms get messed up. Either the bulb loses our session or some traffic is dropped/repeated causing the encryption context to get out of sync. I try to recover in the code but in general I’ve found that if you see the first error (CoAP POST returned … 4.04) that the bulb has lost the session. In the future I hope to make this more seamless to the frontend but for now the bulb toggles to “unavailable” for a minute.
@damru hmm can you please try to ping6 / ping -6 the bulb from the HA console? You can use the hostname format Nanoleaf-A19-XXXX.local where XXXX represents your bulb’s 4 character ID. If that doesn’t work, check if HA has an IPv6 address with ip -6 a. Finally, please restart HA and then don’t restart the BR (which causes it to advertise bulbs on a new IPv6 prefix).
If none of those work, please turn on the 3 debug logs per post 160 and DM them to me.
@lambdafunction I’m playing with your “hacktastic” code and was trying to see if I can get an Eve device to join the Nanoleaf router. I added it to a HomePod border router so that I could get the HK ID, unpaired it and reset it, and then tried to have it join the Nanoleaf border router using the service you created. I keep getting an Unknown HKID error when I try it though. Any ideas? Or am I missing a step
And thanks!
@psumatt the HomeKit ID changes with each pairing. If you are connected to the device over BLE, download the device diagnostics from HA & the HK ID will be in there.
@lambdafunction ahh genius, thank you. I’m no longer getting that error, although it doesn’t seem to be adding it to the thread network either.
Any tips on what I should be looking for in the logs? I’ve also tried it with an OpenThread router I have setup but still not seeing it join the network. Have tried the Android flag as well as the iOS flag.
I was pleasantly surprised when I found HASS discover one of my Nanoleaf Essential bulbs today. It was an unpaired bulb in a lamp I hadn’t used in a while. Once I turned the lamp on it was discovered by homekit controller, paired as expected, and works like a charm 
. Seems like the new bluetooth and bits for homekit in 2022.8 are working! Going to try and unpair existing bulbs to see if I can replicate it.
@psumatt hmm I’m looking around in tech news & although I see Nanoleaf saying they were going to launch support for all HomeKit devices pairing to their BR, I don’t see news of the actual launch or any reference to that in release notes. There is a chance that non-NL devices are blocked but I don’t have any to test with ATM.
EDIT: although I don’t know why the OpenThread BR wouldn’t work. I haven’t tested with that at all yet. I’ll try to get to that soon.
2nd EDIT: the only indication of success I got was the BLE connection being forcibly closed and the BLE/HAP code being suddenly unable to connect to the device while it tried to auth to the Thread network. If if fails, it shows up over BLE again after a bit. That’s all I’ve got to work with currently. I’m not sure how to query the device for errors.
My NUC with built-in bluetooth with HAOS sitting like two meters away from Nanoleaf essential LED strip and it doesn’t see it. What did you do to make it work? What is your setup?
Edit: reset of lightstrip fixed it.
Thanks for pointing this IPv6 thing out.
I was running an AdGuard Home on my network (as an ad blocker + DNS resolver), for the sake of testing everything, I removed it.
Now I’m facing some funny issue where I can run ping6 Nanoleaf-A19-1J8Y.local from my laptop and get a correct response. But when I’m running this command from any other device (the RPI running HA, the HA container directly, another RPI or even a NAS) I cant get any response.
I either get ping6: bad address 'Nanoleaf-A19-1J8Y.local' or a simple timeout when running with the IPv6 address directly.
I tried installing avahi-daemon (through dietpi-software) to get the Bonjour service, but it didnt change a thing.
So basically it seems that it’s a networking issue, and I have no clue how to fix this mess 
@lambdafunction - thanks - maybe best for me to start seeing if I can get Nanoleaf to join the OpenThread network (additionally the Nanoleaf border router) and make sure I can at least replicate what you’ve done first. I’ll report back after I try it.
I think I fixed some of the issues I was having, I had set a nextdns resolver in my dhcp server, but quickly realized I want my router to do resolve dns, not computers directly, but I forgot to remove the IPv6 address for nextdns. I realized this as I was having issues with other devices on the network as well somehow, so maybe it was wrecking something internally.
To keep unrelated network stuff out of this thread, you can DM me and I’ll help you work through it, I’ve had my fair share of networking issues.
Or if it’s fine to post things to the thread, what router are you using? Are you able to ping6 google from the other machines?
A little update.
Basically, running with DietPi instead of RPiOS comes with some drawbacks. One is that there’s no mDNS available by default. For future reference, if anyone wants to make it work, there’s 2 packages to install:
- avahi-daemon
- available through
dietpi-software - this will make
*.localnetwork hosts available
- available through
- libnss-mdns
- manual install
sudo apt-get install libnss-mdns - this will allow using
*.localfor ping, ssh etc.
- manual install
So now I have all *.local hosts available from my RPi, but not from HA container. Still, the bulb is discovered anyway:
2022-08-16 14:05:00.749 DEBUG (MainThread) [homeassistant.components.zeroconf] Discovered new device Nanoleaf A19 1J8Y._hap._udp.local. ZeroconfServiceInfo(host=‘fdc9:8597:8c49:0:c338:d73e:974d:850’, addresses=[‘fdc9:8597:8c49:0:c338:d73e:974d:850’], port=5683, hostname=‘Nanoleaf-A19-1J8Y.local.’, type=‘_hap._udp.local.’, name=‘Nanoleaf A19 1J8Y._hap._udp.local.’, properties={‘_raw’: {‘c#’: b’2’, ‘ff’: b’2’, ‘id’: b’6E:66:A5:3C:04:B4’, ‘md’: b’NL45’, ‘pv’: b’1.2’, ‘s#’: b’13’, ‘sf’: b’1’, ‘ci’: b’5’, ‘sh’: b’prexiQ=='}, ‘c#’: ‘2’, ‘ff’: ‘2’, ‘id’: ‘6E:66:A5:3C:04:B4’, ‘md’: ‘NL45’, ‘pv’: ‘1.2’, ‘s#’: ‘13’, ‘sf’: ‘1’, ‘ci’: ‘5’, ‘sh’: ‘prexiQ==’})
But i’m still getting the Timeout issue
Small update:
-
aiocoapPR was merged! This fixes >1 NL HAP/Thread device causing an exception. - There’s been a regression tracking bulb IP changes that we’re working on fixing in conjunction with some other related enhancements (e.g., following bulbs from BLE to CoAP after Thread provisioning)
- I’m trying to make Thread provisioning more reliable as the bulbs ignore the command 99% of the time & I’m not sure why yet.