@spartandrew18 Oh! This is probably like my Zigbee button. There aren’t entities, but it fires events. Go to the Developer Tools → Events & listen for… state_changed events, I think. You’ll key your HA automation off of those events.
I am not getting anything showing up when I click the button.
Yeah I see that now. Thanks for the help!
I wish home assistant had entities to show when pressed. Would make it easier to see what’s happening.
root@server:~# ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
12: bond0: <BROADCAST,MULTICAST,PROMISC,MASTER,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::e63d:1aff:fe3d:e6f0/64 scope link
valid_lft forever preferred_lft forever
13: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2601:647:cc00:f4:e63d:1aff:fe3d:e6f0/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86295sec preferred_lft 14295sec
inet6 fe80::e63d:1aff:fe3d:e6f0/64 scope link
valid_lft forever preferred_lft forever
15: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::42:2ff:fe3c:dc93/64 scope link
valid_lft forever preferred_lft forever
17: vethe6ae3a9@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::5429:6aff:fe29:6fff/64 scope link
valid_lft forever preferred_lft forever
19: vethf27ab3b@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::147a:b8ff:feba:cb98/64 scope link
valid_lft forever preferred_lft forever
21: vethda52dc1@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::cfd:1bff:fe9d:7dcc/64 scope link
valid_lft forever preferred_lft forever
23: vetha517c94@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::145c:a5ff:fe30:e38/64 scope link
valid_lft forever preferred_lft forever
25: veth3427e67@if24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::28ec:aeff:feda:f7/64 scope link
valid_lft forever preferred_lft forever
27: vetha6bcd33@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::a809:bbff:fe2e:5b20/64 scope link
valid_lft forever preferred_lft forever
29: veth2523961@if28: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::983c:d7ff:fe96:4515/64 scope link
valid_lft forever preferred_lft forever
31: vetheeaea72@if30: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::e8ba:d5ff:fe80:f1fa/64 scope link
valid_lft forever preferred_lft forever
33: veth538d3c4@if32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::7889:3cff:fe11:7558/64 scope link
valid_lft forever preferred_lft forever
35: vethd44e3c3@if34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::3cae:66ff:fee7:adcc/64 scope link
valid_lft forever preferred_lft forever
37: veth1dea03c@if36: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::28d9:dbff:fea3:2ef6/64 scope link
valid_lft forever preferred_lft forever
root@server:~#
Mac and Unraid can ping each other over ipv6
What about the ifconfig on the Mac?
bash-3.2$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
anpi1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether ca:a2:ed:08:ab:6a
inet6 fe80::c8a2:edff:fe08:ab6a%anpi1 prefixlen 64 scopeid 0x4
nd6 options=201<PERFORMNUD,DAD>
media: none
status: inactive
anpi0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether ca:a2:ed:08:ab:69
inet6 fe80::c8a2:edff:fe08:ab69%anpi0 prefixlen 64 scopeid 0x5
nd6 options=201<PERFORMNUD,DAD>
media: none
status: inactive
ap1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether 3e:57:dc:24:00:06
media: autoselect
en3: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether ca:a2:ed:08:ab:49
nd6 options=201<PERFORMNUD,DAD>
media: none
status: inactive
en4: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether ca:a2:ed:08:ab:4a
nd6 options=201<PERFORMNUD,DAD>
media: none
status: inactive
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=460<TSO4,TSO6,CHANNEL_IO>
ether 36:7d:62:e6:a7:40
media: autoselect <full-duplex>
status: inactive
en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=460<TSO4,TSO6,CHANNEL_IO>
ether 36:7d:62:e6:a7:44
media: autoselect <full-duplex>
status: inactive
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
ether 1c:57:dc:24:00:06
inet6 fe80::c0a:4080:662c:7855%en0 prefixlen 64 secured scopeid 0xb
inet6 fd3f:4d46:8539:4967:4b3:a503:c80f:1cf8 prefixlen 64 autoconf secured
inet 192.168.0.162 netmask 0xffffff00 broadcast 192.168.0.255
inet6 2601:647:cc00:f4:189c:7fc7:8ccc:4065 prefixlen 64 autoconf secured
inet6 2601:647:cc00:f4:45f3:90a:93b9:cb1a prefixlen 64 autoconf temporary
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=63<RXCSUM,TXCSUM,TSO4,TSO6>
ether 36:7d:62:e6:a7:40
Configuration:
id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
ipfilter disabled flags 0x0
member: en1 flags=3<LEARNING,DISCOVER>
ifmaxaddr 0 port 9 priority 0 path cost 0
member: en2 flags=3<LEARNING,DISCOVER>
ifmaxaddr 0 port 10 priority 0 path cost 0
nd6 options=201<PERFORMNUD,DAD>
media: <unknown type>
status: inactive
awdl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
ether fa:92:4d:bc:b4:f8
inet6 fe80::f892:4dff:febc:b4f8%awdl0 prefixlen 64 scopeid 0xd
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
llw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether fa:92:4d:bc:b4:f8
inet6 fe80::f892:4dff:febc:b4f8%llw0 prefixlen 64 scopeid 0xe
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::2419:a809:d764:c8e4%utun0 prefixlen 64 scopeid 0xf
nd6 options=201<PERFORMNUD,DAD>
utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
inet6 fe80::1e57:7fe8:3685:e94e%utun1 prefixlen 64 scopeid 0x10
nd6 options=201<PERFORMNUD,DAD>
utun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1000
inet6 fe80::ce81:b1c:bd2c:69e%utun2 prefixlen 64 scopeid 0x11
nd6 options=201<PERFORMNUD,DAD>
utun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::378c:b610:4d2:d2b1%utun3 prefixlen 64 scopeid 0x12
nd6 options=201<PERFORMNUD,DAD>
utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::bb2:c3a2:7c16:45d4%utun4 prefixlen 64 scopeid 0x13
nd6 options=201<PERFORMNUD,DAD>
utun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::ed7e:3522:793a:4d20%utun5 prefixlen 64 scopeid 0x14
nd6 options=201<PERFORMNUD,DAD>
utun6: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::cc36:1f7a:5bdc:e8a6%utun6 prefixlen 64 scopeid 0x15
nd6 options=201<PERFORMNUD,DAD>
Comparing your unraid box and your mac:
13: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2601:647:cc00:f4:e63d:1aff:fe3d:e6f0/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86295sec preferred_lft 14295sec
inet6 fe80::e63d:1aff:fe3d:e6f0/64 scope link
valid_lft forever preferred_lft forever
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
ether 1c:57:dc:24:00:06
inet6 fe80::c0a:4080:662c:7855%en0 prefixlen 64 secured scopeid 0xb
inet6 fd3f:4d46:8539:4967:4b3:a503:c80f:1cf8 prefixlen 64 autoconf secured
inet 192.168.0.162 netmask 0xffffff00 broadcast 192.168.0.255
inet6 2601:647:cc00:f4:189c:7fc7:8ccc:4065 prefixlen 64 autoconf secured
inet6 2601:647:cc00:f4:45f3:90a:93b9:cb1a prefixlen 64 autoconf temporary
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
Your Mac has a fe80 land address, a 2601 GLA address and an fd ULA. Your unraid box does not have the fd ULA.
Thread uses a ULA, so I think this is the problem.
Unfortunately i know nothing about unraid and where to start unpicking why its ignoring the router advertisements from your border router. It’s probably that you have a br0 and its configured to do ip forwarding? I think linux will ignore router advertisements on interfaces that act as forwarders.
https://sysctl-explorer.net/net/ipv6/accept_ra/
You probably want to set net.ipv6.conf.br0.accept_ra to 2 so that it will accept the ra’s. But please look into the implications of this, its presumably not the default for a reason.
After changing this setting it might take 10-20 minutes for your border router to retransmit an RA.
If it still doesn’t work, I found i also needed to set net.ipv6.conf.all.accept_ra_rt_info_max_plen to 64. But we don’t understand when this is/isn’t needed, so don’t change it unless nothing else works.
This doesn’t seem to have worked. net.ipv6.conf.all.accept_ra_rt_info_max_plen also isn’t available for me.
Do I need to add additional routes for the fd ULA here?
After waiting a bit longer, I now get this on the Unraid box:
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.3 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fd3f:4d46:8539:4967:e63d:1aff:fe3d:e6f0 prefixlen 64 scopeid 0x0<global>
inet6 2601:647:cc00:f4:e63d:1aff:fe3d:e6f0 prefixlen 64 scopeid 0x0<global>
inet6 fe80::e63d:1aff:fe3d:e6f0 prefixlen 64 scopeid 0x20<link>
ether e4:3d:1a:3d:e6:f0 txqueuelen 1000 (Ethernet)
RX packets 366110151 bytes 66446017608 (61.8 GiB)
RX errors 0 dropped 98 overruns 0 frame 0
TX packets 54980973 bytes 539622473251 (502.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
I would avoid static config of the fd ip ranges, as (a) we can easily mess up things like the scope and (b) I can’t say how often theyll change and (c) it might not work if you have multiple border routers.
I’ll have a think about what to try next when I’m at my desk.
To clarify, I didn’t add any static configs. In the screenshot, that fd route showed up automatically a while after setting net.ipv6.conf.br0.accept_ra=2. Similarly, the fd ipv6 address showed up automatically after a while.
Still no successful pings to the thread devices from the Unraid box, though
Be good to see the output of ip -6 route I guess. Also, how are you with tcpdump?
root@server:~# ip -6 route
::1 dev lo proto kernel metric 256 pref medium
2601:647:cc00:f4::/64 dev br0 proto ra metric 213 pref medium
2601:647:cc00:f4::/64 dev br0 proto kernel metric 256 expires 86277sec pref medium
fd3f:4d46:8539:4967::/64 dev br0 proto ra metric 213 pref medium
fd3f:4d46:8539:4967::/64 dev br0 proto kernel metric 256 expires 1754sec pref medium
fe80::/64 dev br0 proto kernel metric 256 pref medium
fe80::/64 dev bond0 proto kernel metric 256 pref medium
fe80::/64 dev vethe6ae3a9 proto kernel metric 256 pref medium
fe80::/64 dev docker0 proto kernel metric 256 pref medium
fe80::/64 dev vethf27ab3b proto kernel metric 256 pref medium
fe80::/64 dev vethda52dc1 proto kernel metric 256 pref medium
fe80::/64 dev vetha517c94 proto kernel metric 256 pref medium
fe80::/64 dev veth3427e67 proto kernel metric 256 pref medium
fe80::/64 dev vetha6bcd33 proto kernel metric 256 pref medium
fe80::/64 dev veth2523961 proto kernel metric 256 pref medium
fe80::/64 dev vetheeaea72 proto kernel metric 256 pref medium
fe80::/64 dev veth538d3c4 proto kernel metric 256 pref medium
fe80::/64 dev vethd44e3c3 proto kernel metric 256 pref medium
fe80::/64 dev veth1dea03c proto kernel metric 256 pref medium
multicast ff00::/8 dev br0 proto kernel metric 256 pref medium
multicast ff00::/8 dev bond0 proto kernel metric 256 pref medium
multicast ff00::/8 dev wg0 proto kernel metric 256 pref medium
multicast ff00::/8 dev vethe6ae3a9 proto kernel metric 256 pref medium
multicast ff00::/8 dev docker0 proto kernel metric 256 pref medium
multicast ff00::/8 dev vethf27ab3b proto kernel metric 256 pref medium
multicast ff00::/8 dev vethda52dc1 proto kernel metric 256 pref medium
multicast ff00::/8 dev vetha517c94 proto kernel metric 256 pref medium
multicast ff00::/8 dev veth3427e67 proto kernel metric 256 pref medium
multicast ff00::/8 dev vetha6bcd33 proto kernel metric 256 pref medium
multicast ff00::/8 dev veth2523961 proto kernel metric 256 pref medium
multicast ff00::/8 dev vetheeaea72 proto kernel metric 256 pref medium
multicast ff00::/8 dev veth538d3c4 proto kernel metric 256 pref medium
multicast ff00::/8 dev vethd44e3c3 proto kernel metric 256 pref medium
multicast ff00::/8 dev veth1dea03c proto kernel metric 256 pref medium
default via fe80::929a:4aff:fe31:cfa3 dev br0 proto ra metric 213 pref medium
default via fe80::929a:4aff:fe31:cfa3 dev br0 proto ra metric 1024 expires 1677sec hoplimit 64 pref medium
No experience with tcpdump
If we just look at br0 and not the container interfaces thats:
2601:647:cc00:f4::/64 dev br0 proto ra metric 213 pref medium
2601:647:cc00:f4::/64 dev br0 proto kernel metric 256 expires 86277sec pref medium
fd3f:4d46:8539:4967::/64 dev br0 proto ra metric 213 pref medium
fd3f:4d46:8539:4967::/64 dev br0 proto kernel metric 256 expires 1754sec pref medium
fe80::/64 dev br0 proto kernel metric 256 pref medium
multicast ff00::/8 dev br0 proto kernel metric 256 pref medium
default via fe80::929a:4aff:fe31:cfa3 dev br0 proto ra metric 213 pref medium
default via fe80::929a:4aff:fe31:cfa3 dev br0 proto ra metric 1024 expires 1677sec hoplimit 64 pref medium
No idea why yours has duplicates like that.
Mine is:
# ip -6 route
fd59:86c6:e5a5::/64 via fe80::1423:d0cd:3961:8e4c dev vlan101 metric 1024 expires 0sec
fd69:3e50:e165:4bf8::/64 dev vlan101 metric 256 expires 0sec
fe80::/64 dev vlan101 metric 256
multicast ff00::/8 dev vlan101 metric 256
So there are 2 ipv6 networks in play. The accept_ra change we made seems to have allowed your unraid box to see one of them (fd3f). But you are missing an equivalent to this route:
fd59:86c6:e5a5::/64 via fe80::1423:d0cd:3961:8e4c dev vlan101 metric 1024 expires 0sec
When i didn’t get this route it was because i didn’t have the sysctl net.ipv6.conf.all.accept_ra_rt_info_max_plen configured.
If you run something like this:
tcpdump -n -vvv -e -i br0 icmp6
You’ll eventually see something like this (be patient, it can be a while between broadcasts):
22:51:28.322971 04:99:b9:64:1b:eb > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 126: (flowlabel 0xb0400, hlim 255, next-header ICMPv6 (58) payload length: 72) fe80::1423:d0cd:3961:8e4c > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 72
hop limit 0, Flags [none], pref medium, router lifetime 0s, reachable time 0ms, retrans timer 0ms
source link-address option (1), length 8 (1): 04:99:b9:64:1b:eb
0x0000: 0499 b964 1beb
prefix info option (3), length 32 (4): fd69:3e50:e165:4bf8::/64, Flags [onlink, auto], valid time 1800s, pref. time 1800s
0x0000: 40c0 0000 0708 0000 0708 0000 0000 fd69
0x0010: 3e50 e165 4bf8 0000 0000 0000 0000
route info option (24), length 16 (2): fd59:86c6:e5a5::/64, pref=medium, lifetime=1800s
0x0000: 4000 0000 0708 fd59 86c6 e5a5 0000
If you do see a record like this (the crucial bit is the “route info option”) then you your kernel is just dropping the hint from the border router.
Key thing is the router advertisements? I captured a few of those:
17:09:14.459085 f0:b3:ec:1e:52:1b > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 94: (flowlabel 0xc0700, hlim 255, next-header ICMPv6 (58) payload length: 40) fe80::1895:b54d:d176:6a82 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 40
hop limit 0, Flags [none], pref medium, router lifetime 0s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): f0:b3:ec:1e:52:1b
0x0000: f0b3 ec1e 521b
route info option (24), length 16 (2): fd5e:3f71:7692::/64, pref=medium, lifetime=1800s
0x0000: 4000 0000 0708 fd5e 3f71 7692 0000
17:09:13.548640 04:99:b9:73:9a:e4 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 94: (flowlabel 0x90f00, hlim 255, next-header ICMPv6 (58) payload length: 40) fe80::14d3:b385:2f65:9d64 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 40
hop limit 0, Flags [none], pref medium, router lifetime 0s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 04:99:b9:73:9a:e4
0x0000: 0499 b973 9ae4
route info option (24), length 16 (2): fd5e:3f71:7692::/64, pref=medium, lifetime=1800s
0x0000: 4000 0000 0708 fd5e 3f71 7692 0000
17:11:45.073837 f4:34:f0:0d:a9:da > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 126: (flowlabel 0x20a00, hlim 255, next-header ICMPv6 (58) payload length: 72) fe80::75:3e:28a4:d2fb > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 72
hop limit 0, Flags [none], pref medium, router lifetime 0s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): f4:34:f0:0d:a9:da
0x0000: f434 f00d a9da
prefix info option (3), length 32 (4): fd3f:4d46:8539:4967::/64, Flags [onlink, auto], valid time 1800s, pref. time 1800s
0x0000: 40c0 0000 0708 0000 0708 0000 0000 fd3f
0x0010: 4d46 8539 4967 0000 0000 0000 0000
route info option (24), length 16 (2): fd5e:3f71:7692::/64, pref=medium, lifetime=1800s
This may be a little off-topic, but for those using Essentials bulbs with Home Assistant I’ve created a workaround for transitioning brightness using a script that can be called from your automations or even other scripts. I hope this helps someone out there.
Hello all thank you for all the hard work getting this up and going. Had a hell of a time getting the bulb to pair with HA after getting it on thread with HomePod mini. When pinging from HA, packet loss was 98%, when pinging from another computer on the network, packet loss was around 10%. Had timeout after timeout when trying to pair in HA. What finally got it paired was actually pinging from HA terminal then immediately pairing. Not sure if the bulb is going into some kind of sleep mode but I have factory reset and retried and this technique is reproducible. For everyone having issues actually pairing this might help out.
It is probably something with my network since I can’t ping6 anything reliably from the rPi host but that’s for another day.
Cheers
My nanoleaf strip drop off the network in the middle of the night. This morning I tried:
- Reload the integration - no success
- Remove/reapply power to the strip - no success.
- Reboot HA - no success
- Various combinations of the above - no success
- All of the above again and again hoping for a different result - no success
Then I realized the only thing I hadn’t tried … rebooting the homepod mini. SUCCESS. The strip came back up immediately. Because the homepod mini just sits there in the corner, playing music, I completely forgot about it.
Just wanted to post that in case it helps somebody else.
Would a second thread border router have helped here (ie: would the strip have switched to the other BR when the homepod BR functional failed?)
Yes, a thread device will use any/all available border routers to keep connectivity. A thread network may in fact have multiple border routers and the specification allows for devices to pick the best route to reach a destination. In thread 1.3, service discovery and registration is a standard feature of border routers, allowing thread devices to register and discover mdns services. A HomeKit controller/hub keeping track of an accessory must stay subscribed to mdns service discovery updates for _hap._udp services and update accessory addresses as they change. Matter will use another service type, but otherwise work in a similar manner.