Matter devices are unavailable

Suddenly the connection is back

Check and see if your thread network is on the same channel as your Hue network. If they are, change the Hue channel and see what happens. I have been having periodic device drops. When I ran Thread Doctor, a number of them had very weak connections despite the fact that they were very close to a border router. Once I changed my Hue network from channel 25, the devices all came back online

Maybe this upcoming change will be helpful in identifying and resolving Matter-over-Thread issues:

Source: Homey Pro and Homey Pro mini Changelog | Homey

For people that run a Unifi network, the newest controller beta now has the capability to monitor Matter devices on the network. Nice to see other companies working on tools to diagnose Matter networks.

Well now we will see if Athom have done the right steps / improvements for Thread-Matter troubleshooting because i had a Thread Crash again out of nothing… i already report all details again to Athom, this time with all the requested details from Athom after my last Crash…

Here are some lines out from my request to Athom, i only post this lines because maybe someone could help it to see how you should report the fault case like this to Athom.

Crash again out of nothing - report 8E0333B1
After Homey reboot - report A0EB5C58

…after few weeks of more less stable Thread behavior, my Thread crashed again out of nothing during the night, all devices are in idle mode or off…all people are sleeping.

Well, i have already installed the new Homey software v13.5.1 where Athom implement improvements for the troubleshooting for Thread issues!

The Crash starts exact at 03.102026, on 00:40 am with one device (screenshot) and continue at 03:00am (screenshot) with more then 10 devices, Homey attampted to bring the thread topology back but without success, in the Thread-Matter overview you can see devices come and go, there are moments where are till 2 Devices all are back and then breaks all again more then 10 devices…this behavior repeats and repeats again, see screenshot above and attached…so i create all reports, screenshots, ping test, thread informations and made the Homey reboot, after that all devices are immediately back and the topology looks fine, right now again stable since the last 24h.

Since my last crash i made a change of the BorderRouter, weeks ago, i removed my 3 Apple HomePods because i didnt have any usage for them, so at the moment i have 3 BorderRouter (Homey is the Master all devices are teached directly too them, AppleTV and Aqara G5 Pro) in my system…no Zigbee in use on Homey!

I follow your instructions from last time, i made these steps which you recommend me, below the attachments!*

**Athoms requested instructions:
What to send us (so we can correlate fast)
– Failure timestamp + timezone = 03:00am GMT+2 / 04.10.2026
– Homey diagnostics code at failure = Crash 8E0333B1
– 3–5 Ping screenshots = attached **
– Thread Diagnostics screenshots = attached **
– Any BR/power/network changes = no
– Second diagnostics code after recovery = Reboot A0EB5C58

The Ping Tests are made all to the same Device, in faulty and good conditions, also the Thread informations!

@Hsd1965 please can you share your settings wich you have done on your UDM Pro to see the Thread devices like in your picture?

I ask because I have upgraded my Unifi controller to the version where you now have the Thread-Matter option, for this I had first my UDR updated to v6.0.11, only then I could upgrade the controller version to v11.0.81 (both firmware currently available in “Early Access Mode”.)

But i dont see my thread devices, have you adjust anything afterwords to see the devices?
Where i can make the commissioning - it requires entering the Thread network key (credential sharing) in UniFi or not?
On the screen is a hint: “UniFi has detected Thread border routers, which run hidden Thread networks. Commission devices to view them in your topology. Observability only.”

You need to do the following:

  1. The networks on which the TBR’s reside must have IPv6 enabled.
  2. mDNS must be enabled between the VLANs.

After that you need to pair each Matter device you want to monitor to Unifi. The system does not search and auto-populate the devices from the thread network because it has no access.

So on the Matter device you need to find the option to generate the code needed to pair the device to another network and than pair the device to Unifi. Each device will get an additional fabric called “Unifi Network”.

For Homey Pro the steps are:

  • Select the Matter device in the app, go to “Settings” and then “Advanced Settings”.
  • Select “Share Matter device”.
  • Input the code that is generated in the app in the field “Add Matter client” .
  • The network controller will search and pair the Matter device to the Unifi controller.

Hope this helps.

Thx for your quick reply in this matter…

Yes the IPv6 settings are done already long time ago when i start my setup change too Matter over Thread…correct settings?

I dont have VLANs in my system currently running, i use one single network with three SSID`s,
i know its not the best but at the moment for me is the stable solution…

I will test at the evening your suggestion above, i thought maybe there is i auto mode which i can release / setup anywhere to delivery the Thread details into the Unifi controller, but it isnt, now is clear fro me!

There is a fresh preview firmware version v13.5.2-rc.4 that might resolve some of the issues people are having.

Thread

  • Fixes an issue where all Thread devices could become unreachable due to an occasional address conflict between Zigbee and Thread.

  • Fixes an issue where all Thread devices could become unreachable if Homey Pro is connected to both Ethernet and Wi-Fi.

  • Improves reliability when multiple Thread Border Routers are on the same Thread network as Homey Pro.

Athom answered at the beginning of this week already to my last crash, we had again a lot of e-mail traffic regarding my send datas…at this time 1 level Support was informed from the developer team that Athom will provide this rc.4 update at the end of this week…now its there..i will install and test it…thx for the information!

Since I migrated all my automations to Home Assistant and disabled them on Homey, device drops on Homey no longer affect my automations — but they still happen.

Whenever Homey loses a device, I check HA. Most of the time the same device is still perfectly available there. Occasionally devices disappear from both systems, so there are obviously also genuine Thread/Matter issues. My impression is simply that Homey is much more sensitive to them.

One source of interference in my house is my Eufy S380 base station. It creates its own hidden Wi-Fi network for the cameras and automatically changes channels. My Omada APs use channels 1 and 11, partly to stay away from Thread channel 15.

When Eufy moves to channel 1 or 11, I see congestion on Wi-Fi, but the system copes with it. When it moves to channel 6, however, Thread is affected as well. HA then logs many channel-access errors.

The interesting part is the different behaviour:

  • Homey quickly loses several devices, and they often don’t recover until I switch off the Eufy base.

  • Home Assistant may temporarily lose individual devices as well, but they normally recover by themselves after some time.

A few days ago I had an exceptional event where almost all Thread devices became unavailable on both systems.

I switched everything off and restarted step by step. Starting HA alone brought all devices back. Adding the Apple TBRs one by one made no noticeable difference. But as soon as Homey joined, HA started losing devices again. It took roughly an hour before both systems had recovered.

I repeated the test in the opposite order: Homey first, then the Apple TBRs, and HA last. This time Homey lost only a few devices, and usually only one remained unavailable at a time.

The HA logs gave me a possible explanation.

When HA starts, it initially tries to reconnect to unavailable devices quite aggressively. After repeated failures, however, the retry interval is progressively increased — first to around a minute and eventually much longer.

My hypothesis is that Homey handles this differently and keeps retrying more aggressively for longer. Under bad RF conditions, that could increase channel congestion and affect not only Homey itself but the entire Thread network.

That could also explain why HA sometimes takes a long time to recover after Homey joins: by then HA may already have backed off and scheduled its next retry several minutes later.

The Apple TBRs are probably less visible in my tests simply because they are not directly controlling Matter devices in my setup.

So my current hypothesis is:

HA seems to use a back-off mechanism to avoid continuously congesting an already problematic Thread channel, while Homey may retry more aggressively.

That may help Homey recover a device faster under normal conditions, but under heavy interference it could become counterproductive.

@Doekse, perhaps you can confirm whether Homey’s Matter/Thread implementation uses a similar retry/back-off mechanism or whether my interpretation is wrong.

If not, something similar might be worth considering.

Interesting post from from @Effendi68 , thx for sharing this!

I have a full Ubiquiti setup, everything (still) on the same vlan. Ipv6 enabled:

But still I keep getting “setup failed” when I try to add the id generated from the “share matter device” in Homey:

Any idea how to fix this?

Found it! Disabled IGMP Snooping, restarted my Homey, and then I could successfully add my matter-over-thread devices to Unifi