Hey guys,
Relative newcomer to HA and got a few Nanoleaf A19 bulbs to dip my toe in the Thread waters.
I’ve had a good read of this thread but have so far been unable to bring the bulbs into HA.
I have a single AppleTV4k, and am running HA 2023.2.1 core on a Mac M1. As far as I can tell IP6 seems to be fine – I can ping6 the bulbs and see their mDNS info.
All bulbs paired to HomeKit and confirmed as thread routers through the Eve app.
When I remove one from HK, HA immediately shows it available but when I enter the 8 digit code, it says it’s already paired and the HomeKit integration disappears. Tried power cycling bulb and AppleTV but the mDNS entry still shows sf=0 which I understand means the bulb is still reporting that it is paired.
Factory reset takes me back to square one.
Is there any other approach I can try to unpair the bulb from HK and achieve sf=1?
Realise HA thread provisioning is on the way but it looks like a number of others here have these working now?
Hmm, I would have expected a reboot of the bulb and/or BR to broadcast fresh data. What app are you using to unpair the bulb? If you happen to be using the Eve app, can you give the Home app a try? It shouldn’t matter, but you never know. Also, what version of everything are you on: iOS, ATV4k, NL bulb firmware? I don’t have a 4k but I do have a HomePod mini I can test with.
I used the Home app to unpair (tried iOS and mac).
iOS 16.2, Monterey. Latest bulb firmware. But my AppleTV4k is the 2021 2nd generation which clearly has thread, though perhaps not as functional as the 3rd gen – after posting I found a page that mentioned:
Apple TV 4K (2021) is “not compatible with non-HomeKit Thread devices” while Apple TV 4K (2022) has a dedicated Thread radio that should also work with non-HomeKit Thread devices.
So that could be my problem right there. Looks like I need to update my Apple TV or add a HomePod mini to the mix and report back!
Technically A19 is a HomeKit Thread device, since you are removing it from the Home app, so that shouldn’t necessarily cause the issue.
I have both an Apple TV 2021 4K and HomePod minis.
What worked for me was: add the lights to the Home app, wait until they joined Thread network (checked the status using Nanoleaf app), removed them from Home app (which will remove them from Nanoleaf app as well), waited for a few minutes (even if they show up immediately in HA), added them to HA via HomeKit Controller, and exposed them back to the Home app via HA HomeKit.
Had them paired since Sep 2022 (Bulbs firmware: 1.6.35; HomePod OS: 16 beta (at the time); iOS 16 beta (at the time) )
My guess is it takes a while for the bulbs to “realize” they’re not paired anymore.
As a note, this was before upgrading to the new HomeKit architecture, not sure if that affects in any way, or if you applied that upgrade.
Hope it’s helps.
In the March release we will be landing the work @lambdafunction did figuring out how to provision a BLE HomeKit device on to Thread.
This work is able to to migrate a HomeKit device that is paired to Home Assistant by bluetooth onto a thread network. You do not need iOS or Android in this process, just working Bluetooth on your HA instance.
This has evolved a fair bit since the prototype back in August.
We’ve now fixed the BLE backend, so the manual hacks in core.config_entries described earlier in the thread are no more.
It will be integrated with the new Thread integration in HA (Thread - Home Assistant). Not only will this integration automatically know about any OTBR running on HAOS (i.e. SkyConnect and HA Yellow users), but the companion apps should also eventually be able to sync credentials for other thread meshes running in your home. No faffing about trying to extract the key for your network.
And the service call is gone. If you used the prototype and remember all the different fields you needed to fill in, you’ll know how excited I am about this. Right now, a compatible device will get a button on its device page that will migrate it onto your preferred thread network. Thats it. You pair your device with HA over bluetooth and then press a button and a minute later its available via thread.
If everything goes well, instead of a button on the device page we’ll be going further and exposing this feature in the thread control panel (Matter & Thread: where we’re at - Home Assistant). You’ll be able to see a list of available devices and migrate them.
If the thread integration doesn’t work for you yet or it isn’t able to get the credentials for your border routers the existing methods will still work. All my production devices are connected via HomePod’s using the Pair with iOS / Unpair / Pair with HA method in the homekit_controller docs.
I also wanted to post a quick update on stability.
I’ve been handling a large volume of support requests via discord and some patterns are starting to emerge.
We are seeing cases where when a border router changes its ipv6 address HAOS might not remove the old route. This should always happen within 30 minutes, but it doesn’t seem to. This can mean your HA container is trying to reach your thread mesh by a router that doesn’t exist. I’m still collecting evidence on this one to try and narrow down what is responsible and how we can prevent it, but when it happens your thread devices will be offline until you restart your HAOS device or VM (or you SSH in and manually fix the route table).
We are also seeing cases where some border routers have lousy connections to the mesh. The commercial BR’s don’t really have much easily accessible logs for users to get. ATV seems to be the worst offender, though this could be because they tend to be hidden away in cupboards with lots of HDMI cables and other AV gear. In a multi-BR setup we have seen users with 6 BR’s, and if we manually remove their ATV from the list of routes their setup becomes more stable (briefly - theres no easy way to stop the ATV from coming back right now). Like, we leave ping6 running and when we remove the ATV from the route table all their devices suddenly become pingable again.
We’ve also seem routes flapping. They just vanish from Linux’s route table with no obvious cause and then eventually come back. The weird thing for this case is Mac’s don’t lose the routes. So it’s not that the mesh is inaccessible, just Linux loses sight of it.
Unfortunately none of these issues are fixable by changing homekit_controller or aiohomekit. The best we can hope for at that level is to be more tolerant of them ad to recover with more grace. But we are doing pretty well there in the cases that i’ve looked at in depth.
I am doing what I can to identify any changes at lower levels that might help, and to build diagnostic tools to see if i can spot these cases automatically at least (at its a lot of work to prove them by hand remotely).
One question I have is whether you think all or most of the connection/routing issues that you described will go away in 2023.3 if we were to just use SkyConnect as an OTBR and re-pair all of our HomeKit Thread devices to use that as the sole BR.
It sounds like you said the option to move devices between thread networks is coming at some point, but I assume that at least initially, we would have to manually re-pair them.
Looking forward to it!! Thanks for all the work! I have so many HK/Thread devices on my network now doing all sorts of automation and it has been so much fun playing around with all this stuff!
From your HK devices POV it’s gonna have some thread credentials still, it’s gonna join thst network and then announce itself via zeroconf.
From homekit_controllers POV, it’s going to look at zeroconf and then connect to an ipv6 address. It really doesn’t care about thread any more, it’s just flinging udp around a network.
So in theory as long as upgrading doesn’t reset your OTBR everything will carry on working. If it doesn’t, then it’s probably an OTBR problem not homekit or the devices.
I don’t have an answer for you there. I have been running HomePod as my BR since august and I haven’t had a lot of the problems I’ve seen and investigated with other users. And I’ve only been using my HA Yellow with OTBR as a dev env for a couple of weeks. I turn it off even. I just don’t have enough data to make predictions.
I suspect OTBR running on HAOS won’t have the stale routes problems. There might be other problems, but I don’t think it’ll have that one.
I think HAOS and OTBR on different VMs might still have the stale routes problem, but not enough data.
So you’ve been using OTBR and it’s being stable for you? I mostly only get to talk to people with broken envs, so I’d love to know more about your setup.
I will say that after reading your comment about ATV being problematic, I decided to try changing the “Connected” device to be one of my HomePods instead of the ATV and since then, I would say things have been working far better. And by that I mean that my Nanoleaf A19 bulbs are not randomly becoming unavailable and failing to reconnect until I reboot the sever and also it appears that the lights are more responsive to changes most of the time. It’s only been a couple of days since the change but so far so good. In case it’s useful info, my ATV is a 4K 2nd gen.
It used to be that the ATV would eventually take over as the “Connected” device but lately it seems to stick now until that device is rebooted.
Cheers. I’m not really familiar with the UI for setting the “Connected” device. Would be very interested if you could tell me more about it, and send me the service browser (Discovery - DNS-SD Browser on the App Store output for your devices in _meshcop._udp and the output of ip -6 route from inside your HA container. (Need Debugging the Home Assistant Operating System | Home Assistant Developer Docs to be able to do that) - and you’ll probably need to do ask --no-cache add iproute2 as the default ip command in Alpine Linux is a bit crappy for Thread stuff.
With the Apple meshes I have investigated remotely what seems to happen is all devices publish a route to the mesh. So from Linux’s point of view, one device being the “connected” device shouldn’t matter, as from what I’ve being able to see all the routes are identical. So I’m wondering if setting the Connected device manually has forced the mesh to only have one primary border router or whether it has increased the priorities of one of the routes. If thats the case, that could be a really helpful trick for Apple users.
I have painstakingly read through 375 posts here, and unfortunately haven’t been able to solve my problem with any of the methods discussed.
I have a single (for now) Nanoleaf A19 bulb that I’m trying to pair via an Apple TV. It shows up in HA, but I am unable to complete the pairing process.
I believe the problem is related to my HA host (and the HA container itself as a result) not being able to ping the Thread network. I found the A19’s IP address with the Discovery IOS app, and I can ping it from my MacBook. A route appears to be created (not sure how, specifically). However, attempting to ping it from my NAS (Debian), which hosts my HA instance in docker, fails. Additionally, I tested trying to ping the A19 from another laptop I have, running Arch (btw).
I’m happy to share any other information as needed, and I apologize that this isn’t explicitly about the HomeKit controller, as opposed to more general questions about ipv6/thread (and possibly linux in general, since it “magically” works on MacOS). I’ve been searching various terms for days trying to find SOMETHING to go on.
Few quick facts:
I have public ipv6 addressing working (2600:4040:etc/64).
I have linklocal addresses being distributed as well (fe80::/64).
The Thread network is a different network (fdc5:d1dd:4268::/64)
I can see all of those IPs on the Apple TV via Discovery app.
The two linux machines that can’t ping the Thread network, can ping other local addresses, as well as out to the internet at large.
Can anybody try to point me in the right direction?
Did you join it to Home app first (like a regular HomeKit device)? You have to do that, then “remove” from the Home app, but DO NOT reset the bulb. You should see it pop up in HA then and then you can pair. You have to do the normal HK pairing first so that the device gets the network credentials.
Supposedly in the next release of HA, you won’t have to do this step.
I’m using a nRF52840 as a co-processor with firmware from here on a raspberry pi 4 (4gb) running homeassistant os 2023.2.5. I had to put the dongle on a USB extender to get it to work, otherwise it had too much interference from the USB SSD I’m using as the boot drive for the pi using this encluser. I’m using my modified version of Homekit Controler which I hardcoded the OTBR creds into a custom button that tells thread enabled HK devices to join the thread network and has a custom setup for the airversa. I’m running 8 nanoleaf A19’s, an Airversa air purifier, 3 wemo plugs, and an eccobe thermostat. I have a HASS Bridge setup to pass everything to Homekit on my phone, as well as a connection to google for google home integration. I have automation for my withings bed sensor to change the thermostat when I go to bed, a airthings puls that turns on the HVAC fan when CO2 levels get too high, and turn on the airversera to a high fan speed when VOCs are high. Let me know if you want any other info! Note* I still get some errors in the logs for HK devices, but they are rare and don’t seem to cause any functional issues.
@ha_steve: Yes. I have paired via HomeKit, and then removed it.
@lambdafunction: The route thing makes sense. I do see this route on my Mac, where I am able to ping. On both linux machines, this route doesn’t exist. So, what I’m wondering is which OS is “doing it right” here? I understood the typical intent is that RA does the lifting in this scenario, such that manual routes wouldn’t be required. Perhaps I’m not understanding this correctly, or perhaps the OS defaults aren’t configured this way out of the box. I’m not opposed to adding routes manually, but I don’t understand this well enough to know if those routes could change (ie: if the border router just decides it’s using a different network one morning).
So, I wonder then, is there a setting both of my linux machines need to get to allow this type of RA to work (assuming that’s the underlying disconnect)?
And as a footnote, I think the dedication some folks in this thread have to helping is a lot more impressive than me reading a bunch of posts, haha.
Edit: Sorry, I forgot to include the most important parts, haha. I just manually added the route to my docker container running HA and I can ping, and pair, the bulb. So the route is absolutely the issue at hand, I’m just not sure if adding it manually is the best/correct solution.