#New Thread network spontaneously created and took my Apple TV border router with it

1 messages · Page 1 of 1 (latest)

ocean cargo
#

I had to shut down all of my Apple TVs and HomePods yesterday for a few minutes, when they came back up, I noticed all of my Matter devices in HA were disconnected. Looking at the Thread integration, it appears Apple(?) created a new Thread network and moved the Apple TV to it. My preferred network, to which all of my Matter devices are connected, does not have a Thread border router anymore.

Not wanting to remove and re-add all of my Matter devices, I wondered if I could just share the credentials for the new network in the companion app with HA, and start using the new network. I get the checkmark like it's done, but I'm never left with an option of setting the new network as preferred.

Interestingly, when I went into <companion app>/Debugging/Thread and I allow HA to access my Network, I see ONLY the old Thread network in my Keychain. It's almost like HA thinks there's a new Thread network, but my Keychain doesn't see it or have any credentials for it. So, I'm probably sharing the old network credentials with HA, which explains why it's not doing anything with the new network.

When I open the Nanoleaf app and look at my Thread network, I see only the NEW network, and it has a name and Extended PAN ID, but that's it.

I would love to figure out how to move the Apple TV back over to the original preferred network OR activate the new network and move my Matter devices over to it. I would also like to figure out why this happened and to prevent it from happening again in the future.

I tried shutting down all Apple hubs and restarting them. Tried removing Thread integration and rebooting HA and re-adding it, etc. Nothing seems to be resolving the issue. Any ideas?

2-9-2025_10-04-29.png 2-9-2025_10-01-03.png
zealous rampart
#

Do you have matter devices directly in iOS Home, and do they still work there?

ocean cargo
#

I do have Matter devices added directly to iOS HomeKit and they are NOT working in HomeKit. Obviously, not in HA also. I turned off all of my HomeKit hubs for about 15 minutes and turned them back on. Now the newly created MyHome130 network is gone in the Thread integration, and I still have the MyHome125 network, but it does not have a Thread border router. I tried sharing credentials, but for some reason I can't get the border router recognized (Apple TV). So I've got a preferred network with no border router even though the Apple TV is on the network.

Looking in the Nanoleaf app I can see both the MyHome130 network with the Apple TV and the MyHome125 network greyed out. When I go through the steps to add a Nanoleaf bulb to a Thread network, it only offers me the MyHome125 network (with no border router) and then fails without an error message.

Something is confused somewhere.

zealous rampart
#

I don’t have any answers but: there is a mechanism in thread for network migrations. It’s called a pending data set. The mesh can coordinate a large change and say.. in 15 minutes apply the following change. And (in theory) the whole mesh will migrate at the same time. If that is what had happened, I’d expect that (a) the devices would still work in iOS and (b) there’d theoretically be a way to undo it

#

Because they don’t work in iOS I think all your devices are still using the old network details, and I don’t think there’s a reliable way to get an iOS TBR to join a different thread mesh. We’ve seen it happen accidentally with google where they’d swap identities between google and Apple once a day

#

The only thing I can think of is if there’s some other network factor at play and your HomePods are now broadcasting the correct thread network, but it’s not reachable by the apps you are using.

#

Eg when I first set up thread years ago I moved HomePods between WiFi networks (because I had vlans, which are problematic for thread). Sometimes the HomePod would randomly connect to the wrong ssid and that meant it was on the wrong vlan. Chaos would ensue.

#

So can you confirm there have been no network config changes or new hardware and that you have no vlans.

#

And can you see the HomePod with an ordinary mdns application? I’d expect them to show up under _airplay._tcp.local

#

Do they also show up in _meshcop._udp.local?

ocean cargo
#

Hey there! Thanks for the reply. Really appreciate it!

I can confirm that I made no network changes. I don't remember the exact sequence of events but I was reverting to an earlier backup of Home Assistant to avoid another issue that arose during an upgrade, and at one point I had both HomePods and the Apple TV off at the same time. When everything came back online, none of my Matter devices were responding and I discovered the new Thread network in the Thread integration.

According to HA, all of my matter devices are still looking for my "125" network, which originally had the Apple TV border router.

I added the Discovery app to my iPhone and looked under _airplay._tcp.local and see my Apple TV and both HomePods. Under _meshcop._udp.local, I see only my Apple TV, and under "nn=" I see the name of the MyHome130 (the new) thread network. (Should I see the HomePods here, too?) So I guess this means my Apple TV created this new network. Now the question is how do I get Home Assistant to see it? Here's the full contents of _meshcop._udp.local with some stuff redacted:

Apple-TV-Library.local:XXXXX
192.168.0.8:XXXXX
fe80::4..............................3
fdc8:7.............................3
fdc8:7..........................3

at = <000067a7 b7b80000>
bb = <f0bf>
dd = <1ae189ce 07fddd93>
dn = DefaultDomain
mn = BorderRouter
nn = MyHome130XXXXXX
pt = <b9ab0345>
rv = 1
sb = <000001b1>
sq =
tv = 1.3.0
vn = Apple Inc.
xa = <1XXXXXXXXXXXXX3>
xp = <c87XXXXXXXXXX89>

I suppose the first step would be to get my iPhone to see it so I can share the credentials. Looking at Debugging > Thread in the companion app, I still see only the MyHome125 network in my Keychain. Obviously, that's not the Thread network my Apple TV is using. Any ideas?

ocean cargo
#

Shouldn't "sq" have a value?

zealous rampart
#

You should see all your border routers under meshcop

#

The fact that you can’t points to something weird still being in progress

#

If Apple really has jettisoned the old network details you are going to have to factory reset all your devices.

zealous rampart
#

Technically HA doesn’t need to know about the new thread network. You can add a matter device to Apple Home and then share it with HA, and it never even sees the thread credentials that way.

#

Oh, don’t suppose the HomePods are connected to the Apple tv are they?

#

When you do that it used to create a private network between the ATV and HomePods which would bugger thread up

#

Anyway if you can’t make a matter device work with just Apple (and no HA) then I think it’s factory reset time on the Apple side

ocean cargo
#

@zealous rampart Thank you again... super helpful!

OK, I only see the Apple TV under meshcop, so I suppose something is wrong there. It sounds like I should factory reset my Apple TV and possibly the HomePods, too. The HomePods are not connected to the Apple TV.

Luckily, I'm kind of just playing around with a handful of Thread/Matter devices and the best way to set them up before we move into a new house next month and I have 80 light switches and a slew of other Thread/Matter devices. I'm determining "best practices" for a stable and possibly redundant network. We are both iPhone and Siri users. My thought is that if either HK or HA went down, I could still use my devices in the other. So do you suggest commissioning everything in HomeKit and then pairing with HA? Do I even need the Thread integration in that case?

Thank you for being so helpful!

#

@zealous rampart Also, I wonder if it would be wise to turn my mini PC running HA into a Thread border router, too, using a SkyConnect or whatever, all on the same fabric? That way, if my Apple devices went offline, I believe the SkyConnect would keep the Thread fabric alive. Is that right?

zealous rampart
#

so i like to make an analogy to WiFi; you have a 'control' part (the admin page, or on something more advanced like unifi you have a dedicated control server or device) and a 'data' part

#

wifi doesn't really standardize the control part, so if you have wifi AP's from multiple vendors you have to try and keep any settings in sync between both systems

#

but data wise, if it follows the standards and is bug free, it might work

#

in practice though you might find weird handover issues

#

imo, thread is the same

#

on paper, having a diverse range of TBR's is great, but there is no unified control over them all

#

and we do so bugs in interoperability

#

for some people it does work, but others there is just weird 5h1t - like when google fights ios for control of the mesh

ocean cargo
#

In reality, HA is much more likely to go down (say, during an upgrade) than HK, so maybe just have several Apple TBRs and leave HA out of it...

zealous rampart
#

if you have a completely apple mesh, you get a feature that lets it tunnel thread packets over your wifi network, taking load off your thread mesh AND helping avoid thread partitioning

#

the skyconnect should support that too, but certainly in the past there were a couple of compatibility issues that cropped up when using it

ocean cargo
#

Ah, and I suppose if Apple decided to change my Thread network from one name to another, that would be pretty seamless to me...

zealous rampart
#

so all in all if you already well in the apple ecosystem, i'd just add more homepods rather than anything else

ocean cargo
#

Thanks, this is very helpful. I think that's what I'll do. I'm not sure what caused my current Thread problem, but I first noticed it in HA after a bunch of backup and restoring of HA. I'm hoping I can trust Apple to keep things stable for me in the new home.

zealous rampart
#

As for commissioning, there are 3 options AIUI (i'm more HomeKit over thread than matter over thread). Add device to HomeKit, then share to HA. Add device to HA, then share to HomeKit (at a matter level). Or finally, add device to HA then use the HomeKit bridge to export it back to HomeKit.

#

I think largely for historical reasons i've added stuff to HomeKit, then shared it to HA

#

but the first 2 options are largely the same - your device ends up being a member of 2 fabrics.

#

this does put more pressure on your thread mesh, so some people have gone for the 3rd option

#

i haven't because i want the native app's (like Eve's) to work

#

most of my devices are zigbee, so i don't struggle with thread bandwidth yet.

#

i don't know what caused your original issue. i suspect your HA change just caused you to notice it, but it was broken for another reason already, mostly because HA wouldn't be able to influence the thread network in your configuration

#

HA should only have the ability to break its fabric, certainly not Apple's fabric and certainly not the thread network

ocean cargo
#

So, I did read that HA and HK create separate fabrics, but on the same Thread network. I don't think I can trust the 3rd option enough (Adding to HA and then bridging to HK). I've been playing around with HA for a couple of years now, and updates end up breaking stuff. I don't want my entire house going offline because of a HA update problem. In fact, right now, in upgrading to Core 2025.2, my HomeKit bridge completely broke. If I were doing option 3, my home would be entirely offline!

I think I'm going to do what you are doing -- HK first and then HA.

zealous rampart
#

i should add that HA rarely breaks on update for me. the last time it happened it was because i ignored a deprecation warning for a year and it was finally removed, the time before it was a custom component

ocean cargo
#

Yeah, figured that HA wouldn't be able to affect the HK thread network. So I'm at a loss here...

zealous rampart
#

and esp homekit, the dev that maintains the bridge has multiple test environments with hundreds and hundreds of devices

ocean cargo
#

Interesting. Yeah, my HK bridge broke on my two machines each running HA. One of the machines was a brand new install of HA. No add ons or integrations or devices yet.

zealous rampart
#

what was wrong with it?

ocean cargo
#

Everything was fine until I upgraded to Core 2025.2. All HK bridge devices were unresponsive in HK. I restored back to 2024.1.4, and all were working again. So as an experiment I installed HK bridge on my brand new machine/install, made one input Boolean, and same problem-- worked in 2024.1.4, but not 2025.2 and later.

A lot of people are having NO problems with their bridges after upgrading. The fact that I have problems on both of my machines that are completely separate from each other makes me believe there's something inherent to my network or something, rather than some software incompatibility.

zealous rampart
#

thats why im fishing

ocean cargo
zealous rampart
#

multicast problems could cause some of the matter issues you had AND HK bridge issues

ocean cargo
#

Can you elaborate?

zealous rampart
#

so if multicast from those machines to your appletv or homepods was getting dropped for some reason, then HK bridge's port wouldn't get announced so the ios ecosystem wouldn't be able to see the bridge any more

#

and likewise multicast problems could explain why we can't see _meshcop etc

ocean cargo
#

There's a limit to my technical abilities here ... but what do you mean by "multicast" exactly?

zealous rampart
#

so normally when computer A talks to computer B it establishes a unicast connection - a direct connection

#

and networking gear like switches are smart enough to learn which things are talking to each other, so on an 8 port switch only the 2 ports involved in that unicast connection actually see the packets

#

but for home networks in particular, you want to be able to discover what is on the network

#

so you can send multicast packets which go to every device on the network

#

BUT multicast is contained within a single layer 2 network - and is why the first thing we ask about is vlans

#

if your wifi was on 192.168.0.0/24 and your lan was on 192.168.1.0/24, thats 2 seperate layer 2 networks, they can't have multicast between them, things will break

#

but its not that simple, because multicast traffic can be noisy so some WiFi devices try to be clever and filter it

#

that can also break homekit and matter in weird and wonderful ways, and it can work sometimes and then suddenly fail

#

WiFi repeaters are especially bad for this

ocean cargo
#

So in my case, what's specific about my setup that you think might be causing these multicast problems?

zealous rampart
#

well, its more like a hunch that you've had weird problems with 2 integrations for protocols that rely heavily on multicast

#

and because its also such a common problem for multicast to be implicated

ocean cargo
#

So two HA machines? Or between HA and HK?

zealous rampart
#

so 2 HA machines - what are they? are they wifi? LAN?

ocean cargo
#

LAN

zealous rampart
#

the homepods - they are WiFi

#

AppleTV?

ocean cargo
#

HomePods WiFi, Apple TV LAN

zealous rampart
#

do you have multiple AP's? or just the one backed into your router?

ocean cargo
#

All I did on that second HA machine was install HA. It wasn't actually performing any other function. I didn't even have the Thread integration installed when my problems started.

zealous rampart
#

well the thread integration is irrelevant, its just an API for other integrations to share the thread network connection string

ocean cargo
#

I don't have any APs. Just the router. Smallish house. But in the new house we'll have several APs throughout.

zealous rampart
#

what router?

#

any switches?

#

are the HA machines Pis? VMs?

ocean cargo
#

I have a C4000XG router supplied by our internet provider.

#

I have one switch

#

The HA machines are a pi4 and a Beelink EQ14

#

The new one is the Beelink

#

I plan to use it in the new house and get rid of the pi

zealous rampart
#

theres a lot of people complaining about AirPlay and the C4000XG, with people suggesting it has problems with.. multicast

#

AirPlay is another protocol that uses it heavily

ocean cargo
#

Interesting

zealous rampart
#

i would repeat the HomeKit bridge experiment

#

and use the same Discover app to look for _hap._tcp

#

if both the pi and beelink are connected to your switch, you should be able to use the homekit_controller integration on one to test the bridge integration on the other

#

so if your phone cant see _hap._tcp but e.g. your Pi HA discovers it, that would strongly point the finger at your router

ocean cargo
#

Let me check how I'm set up

#

The pi is connected to the router, the Beelink is connected to the switch

#

This experiment might be a little over my head, technically. By HomeKit_controller integration, what do you mean... ?

#

I think you are referring to HomeKit Device

zealous rampart
#

Yes

#

I’m it’s maintainer

ocean cargo
#

Ah!

zealous rampart
#

It got renamed a few releases ago but internally it’s called HomeKit controller

#

Because it implements the controller side of the HomeKit spec

#

If there are unpaired HomeKit accessories on your network, HA will see them

#

And they should appear on the devices page ready to be configured

ocean cargo
#

I haven't used it yet ... I think I understand what you're getting at. I'll play around with it and see what I can find. I'll be out of this house and setup in a month or so, so what really matters is how I'll be set up in the new house. I don't want marital disharmony because our switches stop working!

zealous rampart
#

Basically if your beelink has a new unpaired bridge, the pi HA should see it

#

If it does, and the phone doesn’t - WiFi problems

#

But right now I’d be tempted to blame your router

ocean cargo
#

Just tried installing HK Device on my pi and it says "No unpaired devices could be found."

#

The Beelink bridge is paired (because I got it to work in 2024.1) but the devices show no response in HK

#

Ah, just realized I uninstalled Bridge on the Beelink

#

OK, on the Beelink, just installed Bridge. Trying to add the Bridge to HK and its timing out -- accessory not found. For the heck of it went to the pi and tried to add HK Device and still getting "no unpaired devices" but it sounds like I need to put them both on the same switch for it to work. Will do that.

#

@zealous rampart ok both machines are on the same switch. The Beelink bridge remains unlinked. Tried installing HK Device on the pi and it's still showing no unpaired devices.

#

As I mentioned, reverting back to 2025.1.4 fixes everything in bridge without making any changes to my network, so something about the upgrade breaks what previously worked. I think I'm just hoping at this point when I put it all together in the new house, I'll have a stable Thread network as well as a working HomeKit bridge for when I need that!

zealous rampart
#

When you reverted to 2025.1.4 did it appear in your pi?

#

(BTW, I can see why for you it’s “it’s a HA bug, downgrading HA fixes it”. But from my pov, HK bridge is one of the largest integrations. That issue from earlier only has a few users and most of the people in the issue you linked to were running a problematic custom integration which you aren’t. So you have 2 obscure issues which, which you can recreate on multiple machines. It makes my bones itch. There’s something funny happening there.)

#

The zeroconf occasionally gets stricter about the standards it’s following, I wonder if that’s why the upgrade broke things.

#

Zeroconf (the standard, not the integration) is a bit of a mess (some devices and apps DOS themselves in extreme cases)

ocean cargo
#

To answer your question. When I reverted my pi to 2025.1.4, HomeKit bridge worked again on my pi -- meaning all of my "no reponse" bridged devices in HomeKit started working again. Same thing with my Beelink. Upgrade to 2025.2 and it stops working, go back and it works again.

zealous rampart
#

I’m interested in HK Device behaviour

ocean cargo
#

Ah, I haven't used HK Device.

zealous rampart
#

Right

ocean cargo
#

But I did try it in my experiment... And on my pi, using 2025.2.1, HK Device says it can't find any unpaired devices. Hope that's what you were asking. I have not tried to revert the pi back to 2025.1 to test that out, but I can.

zealous rampart
#

so the question is, can any version of hk device not see the bridge when the bridge is on 2025.2, and then it appears when the bridge is on 2025.1.4?

ocean cargo
#

And when you say "the device" -- just to be clear. I have an unpaired Bridge on my Beelink and that's the device you are hoping HK Device sees on my pi. Right?

zealous rampart
#

Yes

#

When the bridge is on 2025.2 AND when the bridge is on 2024.1

ocean cargo
#

OK, so I'll move the Beelink back to 2024.1 and retry the experiment. I've got to leave for a bit, but I'll report back. I'll get the Beelink moving back to 2024 now.

zealous rampart
#

Cheers

#

You are running HAOS on both, right?

ocean cargo
#

Yes HAOS on both. So, both machines are on 2025.2.1 right now. I have an unpaired bridge on the Beelink. The QR code notification for that bridge is naming it HASS Bridge:21064. I have a paired bridge on my pi. That one is called Homekit Bridge:51828. All devices in HK for this bridge are showing no response.

I just tried to install HomeKit Device on the pi. Now it is seeing something (previously it did not -- maybe bc I was on an ipad?). It asking me if I want to pair with HASS Bridge 618104. That's a totally different bridge name than the other two. Does that tell you anything?

#

I haven't hit submit yet on that pairing to see what happens. OK, got to run but I'll check in later.

zealous rampart
#

thats just weird

#

so, the name comes from zeroconf aka multicast DNS

#

so for it to be wrong i'd normally think that you had a VLAN and you had a broken router that was acting as an mDNS repeater (they frequently screw up mDNS data they are repeating)

#

but, you don't, and there isn't a router involved because both are plugged into the switch

#

i'd be interested in whether your iPhone/iPad Home app could see any unpaired bridges - be it 21064 or 618104

#

i'd also be interested in whether 618104 goes away if you restart HA on the pi

#

if after that restart there are no unpaired bridges showing, then downgrade from 2025.2 to 2024.1 and see if one appears

ocean cargo
#

OK, I'm back. So, on the pi, I went ahead and paired with Bridge 618104 using the pairing code generated on the Beelink for Bridge 21064. It worked and I can now see that input boolean I made on the Beelink. Back on the Beelink, the QR code went away as the bridge was now paired.

#

Very strange to me that the bridge name (which I think is the port it's using) on my Beelink is different from what HK Device saw on the pi. But it was obviously the same bridge.

I was not able to pair this bridge using the QR code in HomeKit.

I wonder if this is the crux of my HomeKit Bridge problems?

#

I can assure you I don't have a VLAN. My network setup is pretty basic. A modem, a router and a switch to give me more Ethernet ports. Both the pi and Beelink are def HAOS on bare metal. Both are definitely plugged into the switch which is plugged into the router.

I have never seen anything in the Home app about unpaired bridges. Not even sure Home would notify me of that.

ocean cargo
#

OK, on the pi, I just deleted the HomeKit Device integration. Went back to the Beelink and the QR code showed back up in Notifications since the bridge is now unpaired again, and it's showing the name 21064 again there. For the heck of it, I tried to pair it with HomeKit again using my iPhone and no luck ("Accessory Not Found").

It seems to me HomeKit Device is working at you'd expect. So probably no reason to downgrade again to 2025.1.4. I would expect the same behavior.

Does this give you any clues about why HomeKit Bridge stopped working with the update?

ocean cargo
#

More data: I removed the HK bridge on the Beelink and I downgraded it to 2025.1.4. Created a new bridge and it gave it the same name: 21064. Went back to the pi running 2025.2 and added the HomeKit Device integration. It's showing two unpaired devices now: The 618104 and 023A77.

I first used the pairing code to add Bridge 618104, and it worked. Deleted it, went back and used the same pairing code to add 023A77 and it worked again. In both cases I could see the one test input boolean I created. So two identical bridges were exposed and was able to pair each one using the same pairing code.

In HomeKit Device I clicked Add Entry to see if I could add both copies at the same time, and it offered to add bridge 618104. I tried but it said that the bridge was already paired. So, no.

Deleted HomeKit Device, freeing up the bridge again. Used the iphone camera to add it to HomeKit and it worked instantly. It gave it the default name 023A77. I can see the Input Boolean in HomeKit.

In other words, it works just fine when I'm using core 2024.1.4 or earlier. Upgrade to 2025.2 or later and it stops working.

Do all of these bridge names indicate a bug or is it just naming conventions between services? I wonder if this info would be helpful for the HomeKit Bridge developers. Do you know any of them?

#

You'll have a lot to see in the morning! 🙂

zealous rampart
#

ok so i have a hunch that in our test, even though there are 2 discovered bridges, there arent really

#

so one of the more annoying bugs i have in homekit device for thread is when you migrate from bluetooth to thread you end up with ghost discoveries

#

suspect this is a variant of that

#

basically, the discoveries never time out

#

you downgrade HA on the beelink, the old discovery is still in memory on the pi

#

it comes up and advertises a new zeroconf record for the same bridge - same ip, same port, same code. just a different name (for reasons)

#

so it /looks/ like 2 bridges, but its actually 2 mdns records pointing at the same bridge

#

so really you need to restart HA on the pi after downgrading HA on the beelink to rule that out

#

i do know the bridge maintainer quite well; they are also a contributor to hk devices, and responsible for the bluetooth stack in HA, and most of the performance work, and are reviewers and contributors to lots of other integrations. so quiiiiite busy... if we find a smoking gun i'll definitely loop them in, but we aren't there yet.

#

to recap from my side

#

you have a pi running HA and a beelink running HA. they are connected through a switch. the beelink is running 2025.2 and has an unpaired homekit bridge. in this configuration the homekit device integration can see the bridge is available for pairing. this shows that the bridge is capable of broadcasting mdns records that another HA instance can parse. and it can pair with it. however an iphone's home app cannot. you get an "Accessory not found" error - which is the error i'd expect with an mdns failure. when you downgrade the beelink to 2025.1 the same bridge can now be found and can connect instantly.

#

if those broadcasts from 2025.2 were missing, the pi would not be able to add your bridge

#

if they were malformed, i do not understand why e.g. my iphone (latest ios) would be able to parse them, but yours not

#

the biggest difference is that ios has to go through your router, which is known to screw up multicast

#

so why does downgrading fix it?

#

my best guess is there is a change, but its something innocuous for most of HA's 67k bridge users, but causes your router to choke

#

if you are in the apple ecosystem, do you have a macbook?

#

i believe there is a mac version of the discover app you are using

#

what i'd want to do would be connect the macbook to your lan via the switch and see if it can see the _hap._tcp domain

#

then unplug it and check again over wifi

#

that would make me shut up about your router OR prove that you need a new one

#

if its not your router, there would have to be a bug in the mdns broadcast that came from your environment and was quite rare. but given we are using the same docker container images, and the contents of those records are largely static... the only things that change are the names of things and the ip addresses

#

by using a pi and beelink you've also ruled out an architecture bug, its not something thats specific to the hardware that you are running on.

#

could there really be an ip address coming from your beelink that was so offensive it broke ios, but NOT homekit device, and it only mattered in 2025.2?

#

feels like it'd be really unlikely

ocean cargo
ocean cargo
ocean cargo
#

I saw there was a new Core release 2025.2.2. Tried it on the pi and no change.

#

Can't help but wonder if all of my problems are related. The HomeKit bridge was the first problem I noticed. Then, in trying to fix that by going back and forth between backups, I saw my Matter devices go offline and I've been having the Thread problems, as you know. Is there a link?

If the Thread integration just looks at the Thread network rather than affects it, I wonder why my pi running 2025.2.2 is showing only my former "MyHome125" preferred network but with no TBR. But, my Beelink shows only the "new" MyHome130 network, with the Apple TV as the TBR, but I can't seem to be able to share credentials with it so I can use it.

My iPhone keychain credentials are still for the 125 network. But looking at meshcop my Apple TV is broadcasting the 130 network.

I know you said I should reset my Apple TV and HomePods. I suppose that's the next step for tomorrow.

zealous rampart
#

Yes it’s certainly weird

#

So there are bits of it that make sense under the lense of a zeroconf problem

#

Like I said the thread integration doesn’t actually do anything. There are some APIs to share the secrets. And there is a debug panel to basically browse the meshcop data as the HA instance sees it

#

If there is a network in that panel but no TBRs then it’s a network that HA has the keys for / the preferred network.

#

So another way to phrase this is that pi running 2025.2 can’t see any meshcop records, your phone can only see meshcop for your tv, and your beelink (running 2025.1? Or .2?) can only see the tv too.

#

So there id want to confirm what version the beelink is on when it can’t see the TV meshcop records. And does changing to the other version help?

#

It sounds like your phone has only the old creds, so I’d want to check it was signed in to the same Apple account as the HomePods and Apple TV.

#

So far, we can’t see your HomePods (over WiFi) from anywhere, and your phone can’t see your HomeKit bridge (but only the latest version of HA) - that is also over WiFi. But the pi can’t see your appletv over LAN. Is the Apple TV connected to the same switch as the pi and beelink?

warm dagger
#

This sounds like some network issues. I have seen this before if the Apple TV "thinks" its on another network, it also generates a new Thread network. I would suggest restarting network switches/routers to begin with but next step is make sure the various devices are on the same dumb network switch. If there is a smart switch in between, look at IGMP/MLD snooping settings and toggle those

zealous rampart
#

The router is known to have multicast issues, and some of the reproducible problems are when we cross the routers network path, so I’m firmly on board with chucking it in the bin

ocean cargo
#

@warm dagger and @zealous rampart -- thanks to you both. I've upgraded to Core 2025.2.2 on both HA machines. Also, I moved the Ethernet Applet TV to the same dumb switch as both of my HA computers. I didn't expect anything to change with that, and I wasn't wrong!

Now I'm going through the process of rebooting everything one at a time and waiting in between. I've rebooted both the modem and router (together rather than separately, not sure if that matters). In about 30 minutes, I'll move to the switch. 30 mins later the Apple TV, then the HomePods, finally both HA computers. I'll let you know if that helps with anything.

#

Since I will be moving out of this house in about a month and into a new house, I can't think about replacing the C4000XG at the moment. But I will have a new, state of the art router at that time.

zealous rampart
#

I’m hoping that fixes everything for you, but I was hoping we could prove it in the mean time

ocean cargo
ocean cargo
zealous rampart
#

We established that HomeKit bridge discovery seemingly broke between 2025.1 and .2, but only for your phone (on WiFi) and not your other HA (on LAN)

#

Just looking for patterns like that

ocean cargo
#

@warm dagger and @zealous rampart -- Home Bridge is fixed. I rebooted my modem, waited 30 mins, then the router, another 30 mins, the switch, 30 mins, the Apple TV, 30, HomePods, 30, the hosts of both HA computers. The HomeKit bridge items were showing up sometime after either I rebooted the router or the switch. Either way, that part is working just fine.

ocean cargo
#

However, my Matter devices are still non-functional. For whatever reason, my Thread credentials are still out of date in my iCloud keychain, where I still see network MyHome125. But my Apple TV has moved on to MyHome130, and I can see that in meshcop.

#

Both of my HA setups see the MyHome130 network. If I could just get my iPhone or iPad to receive the credentials... Any ideas?

#

Besides completely resetting my Apple TV and HomePods?

zealous rampart
#

Well, the devices are still on MyHome125. So what happens if you reset a device and add it to your iOS Home app? Does it fail? I’d imagine it’d get added to 130 and for that your iPhone would have to get the creds from the apple tv via iCloud or something

#

I don’t think you are getting out of resetting the matter devices tho

ocean cargo
#

I tried resetting a device to factory settings and re-adding it, and it failed in HK. I know that trying to re-add a device that you removed can cause problems, but I don't have any brand new Thread devices to add at the moment.

#

I really feel like this must be an apple problem at this point. When I'm adding a device, you would think apple is checking for the latest thread network and pulling the creds. But it might just as well be trying to use the outdated credentials on my iPhone and failing.

violet wagon