@victor-perez I am working on adding Thread provisioning to HA but there are no specifications to work from so it is tricky. It would add the feature you seek, telling a HAP BLE device to start talking HAP Thread.
2 Likes
@victor-perez what blind do you have out of interest? So far i’m only really aware of Eve and Nanoleaf having HAP-over-Thread products. And I think there is an air purifier too. So very interested in case its something i can get for testing.
You can already using this with Nanoleaf border routers, but I haven’t tested that method to write documentation for. So you can use it without an Apple product already.
Also, a lot of work is happening to make BLE faster. The bluetooth library will be significantly faster in 2022.10. When HomeKit over ESPhome works, that might actually be even faster still (its not ready yet though).
My blinds are use a Eve MotionBlinds Motors (https://www.smartblinds.com). I also see that they are planning to add Matter support before the end of this year.
Just an fyi - for anybody curious or anybody wondering what happens if you’ve got it working and are afraid to upgrade.
I just upgraded to 2022.10.03 (and OS 9.2) and the NL55 still works (99.99% of the time) like a champ.
Observations:
- The changes to /etc/sysctl.conf in my instructions (step A.5) are wiped out by the upgrade, but the existing NL55 still seems to work.
– I don’t know if this would prevent finding new devices - The changes to const.py in my instructions (step A.6-8) are removed completely
– There is no “AIOHOMEKIT_TRANSPORT_COAP” to remove, and there is no “if True”
Note that above I noted it works 99.99% of the time - that 0.01% is only because sometime in the middle of the night (this was before I did the upgrade) the NL55 became “unavailable” - and it took a reboot of HA to get it to stay available again. Since I was running in a non-official way, I didn’t bother with capturing any logs or anything - but this is now running official and proper, so I’ll monitor it and will file a bug report if it happens again.
1 Like
You only need the sysctl change if you find your HA container isn’t getting any ipv6 routes to the mesh network. For some people this isn’t neccessary, but I don’t know what the key factor is.
@putch any chance you could tell me the output of ip -6 route and ip -6 a s.
My ISP doesn’t support IPv6, so my vlans each have a link-local fe80 netowrk. The HomePod then advertises routes to its mesh local network, and its isolated to that one vlan. So i get something like this:
fd59:86c6:e5a5::/64 via fe80::95:1af6:9f0a:7a3 dev vlan101 proto ra metric 1024 expires 1701sec pref medium
And the vlan interface looks like this:
3994: vlan101@bond1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 02:65:0a:c0:ae:03 brd ff:ff:ff:ff:ff:ff
inet6 fe80::65:aff:fec0:ae03/64 scope link
valid_lft forever preferred_lft forever
I am not sure what happens if your network has ULA’s or GLA’s set up, and whether that negate the need for the the sysctl changes.
I am working with another user who actually reconfigured their UniFi router to accept router advertisements from their apple tv. So then they had cross VLAN access to their mesh network ipv6 addresses. The sysctl change is not needed in that case because the HA container is on a different vlan - its their router that needs to know the routes. This was hard - they actually compiled a custom kernel to make it work.
Would just like to report that after I joined my openthread border router to the nanoleaf network, I disabled thread routing on my shapes controller and everything is still working properly in HA, so it seems like as long as there’s a border router of some kind it all just works, which also annoys me because that means there’s zero reason there can’t just be an option to specify a custom thread network to join in the app.
I had an issue where my lights kept getting disconnected from HA when I had both the shapes and HA working as border routers, but when it’s just one or the other that issue goes away.
Haha I agree! One of my few complaints with the Apple ecosystem.
I don’t have a lot of experience with ipv6, so looking for a bit of help, as that’s where I think I’m running into trouble with pairing Thread devices to HA. HA does detect the accessory, but then errors out when trying to pair (logs say it’s a timeout).
I think it’s due to ipv6 issues; my laptop can ping the accessory just fine (with mdns or the ipv6 address), but my Unraid server (on which I’m running HA in Docker) is unable to ping at all.
Any suggestions on what I can look at on the ipv6 front to debug?
Sorry for the delayed response - was absent for a bit.
My ISP does not support IPv6 either. Here is the output you requested.
bash-5.1# ip -6 route
::1 dev lo metric 256
fd7a:5117:99f3:469c::/64 dev enp0s18 metric 100
fdfa:dc8e:f458::/64 via fe80::4ce:dcff:2f8e:1617 dev enp0s18 metric 100
bash-5.1# ip -6 a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fd7a:5117:99f3:469c:3120:d3a2:c6b8:9db8/64 scope global dynamic noprefixroute
valid_lft 1672sec preferred_lft 1672sec
inet6 fe80::8b79:4856:f6be:e52a/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: hassio: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::42:a7ff:febe:57e3/64 scope link
valid_lft forever preferred_lft forever
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::42:e2ff:fe30:3436/64 scope link
valid_lft forever preferred_lft forever
6: veth6fccb54@if5: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::94a4:fff:fe88:2cce/64 scope link
valid_lft forever preferred_lft forever
8: veth584e638@if7: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::98aa:b0ff:fecc:e81/64 scope link
valid_lft forever preferred_lft forever
10: vethc299607@if9: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::9c95:83ff:feee:7ba8/64 scope link
valid_lft forever preferred_lft forever
12: veth5ed0633@if11: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::c01b:88ff:fec5:3518/64 scope link
valid_lft forever preferred_lft forever
14: vethfeacb13@if13: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::2c1a:4cff:fed3:fc12/64 scope link
valid_lft forever preferred_lft forever
16: veth1cddd22@if15: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::347a:43ff:fef3:8c1f/64 scope link
valid_lft forever preferred_lft forever
18: veth419c2b3@if17: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::868:eaff:fe60:738b/64 scope link
valid_lft forever preferred_lft forever
bash-5.1#
Cheers! That looks much like mine. Maybe i needed it because my iot vlan interface is a macvlan. Or maybe its a kernel version thing. What kerenl do you have?
Hi @rahil, sorry i didn’t see this, it’s a bit random as to when i get forum notifications.
So your feeling about ipv6 is right I think.
My first instinct is to ask whether you have any VLANs. If mDNS works but IPv6 isn’t you might have VLANS and an mDNS reflector. So you could see the correct IP address, but because you are on a different vlan you wont have an ipv6 route to it (by default your router will probably ignore thread routes).
If you are on a flat network (no vlans) my next question is whether you have any wifi network extenders in play. There are some that just can’t forward ipv6 traffic at all. And others that break mDNS (but thats probably not the problem here).
Finally, on your unraid box can you run the commands that I asked putch to run. We both posted examples of what it looks like for us. Can you also post an example ip address for one of your discovered thread devices? It might be that your unraid box is not seeing the ipv6 routes the border router is advertising.
Thanks for the help.
No VLANs on my network. My network set up is using TP-Link Omada equipment: 4 APs hooked up to a switch and a router (which handles DHCP) on the same switch, so no extenders or the like.
Here’s the output of those commands on my laptop (Mac):
bash-3.2$ nslookup Eve-MotionBlinds-1CBF.local
Server: 2001:558:feed::1
Address: 2001:558:feed::1#53
** server can't find Eve-MotionBlinds-1CBF.local: NXDOMAIN
bash-3.2$ ping6 -c4 Eve-MotionBlinds-1CBF.local
PING6(56=40+8+8 bytes) 2601:647:cc00:f4:bd52:7bf4:c9c7:7f13 --> fd5e:3f71:7692:0:cfae:5287:a33b:6ce0
16 bytes from fd5e:3f71:7692:0:cfae:5287:a33b:6ce0, icmp_seq=0 hlim=63 time=1975.065 ms
16 bytes from fd5e:3f71:7692:0:cfae:5287:a33b:6ce0, icmp_seq=1 hlim=63 time=979.031 ms
16 bytes from fd5e:3f71:7692:0:cfae:5287:a33b:6ce0, icmp_seq=2 hlim=63 time=1979.392 ms
16 bytes from fd5e:3f71:7692:0:cfae:5287:a33b:6ce0, icmp_seq=3 hlim=63 time=986.307 ms
Here’s the output of those commands on my Unraid box:
root@server:~# nslookup Eve-MotionBlinds-1CBF.local
Server: 192.168.0.1
Address: 192.168.0.1#53
** server can't find Eve-MotionBlinds-1CBF.local: NXDOMAIN
root@server:~# ip -6 route get fd5e:3f71:7692:0:cfae:5287:a33b:6ce0
fd5e:3f71:7692:0:cfae:5287:a33b:6ce0 via fe80::929a:4aff:fe31:cfa3 dev br0 proto ra src 2601:647:cc00:f4:e63d:1aff:fe3d:e6f0 metric 213 pref medium
root@server:~# ping6 -c4 Eve-MotionBlinds-1CBF.local
^C (had to cancel out, did nothing and wasn't timing out)
root@server:~# ping6 -c4 fd5e:3f71:7692:0:cfae:5287:a33b:6ce0
PING fd5e:3f71:7692:0:cfae:5287:a33b:6ce0(fd5e:3f71:7692:0:cfae:5287:a33b:6ce0) 56 data bytes
^C
--- fd5e:3f71:7692:0:cfae:5287:a33b:6ce0 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3077ms
Can you post ip -6 a for your unraid box?
Can your unraid box ping your mac over ipv6 and vice versa?
I’m pretty sure I needed it sysctl change to get it working initially - and I’m flat, no vlans.
Kernel …
bash-5.1# uname -a
Linux homeassistant 5.15.72 #1 SMP Fri Oct 7 09:19:22 UTC 2022 x86_64 Linux
Have you rebooted since backing out the sysctl?
I upgraded to 2022.10.03 and OS 9.2 - I’m pretty sure rebooting is automatically part of both of those processes - and for kicks I just rebooted now and it all still works. Note that I did not back out the sysctl change. It happened automatically when I upgraded HAOS.
I have not been able to get my Wemo Stage Controller to bind with Home Assistant after unpairing from Homekit. Every time I enter the code it will say its already been attatched to another device? Is wemo not supported yet on homekit controller?
@spartandrew18 (go green)
Hmm that indicates that either it doesn’t unpair properly (we’ve seen that with a few accessories), the first pairing attempt after unpairing went south, or you need to reboot the device to get it to advertise the unpaired status.
So try a reboot (pull out the battery if needed) and then factory reset and start over (pair to iPhone, unpair, pair to HA).
Oh, make sure you’re on the recently-released 2022.10.5. I think Jc2k got a fix or two in for HAP+Thread.
1 Like
I got it to work. However, I cannot really do much with it since the entities have not been properly created? Any ideas for future work on this?
@spartandrew18 Awesome! I just want to confirm that you’re on 2022.10.5? It contains a fix for that specific device: Paring thread Wemo Stage programmable switch fails · Issue #80133 · home-assistant/core · GitHub