Matter devices are unavailable

[staeff]

@Doekse this discussion prompted me to build exactly what was just asked for: an app that continuously logs Thread/Matter diagnostics so unavailability can be correlated with the mesh state after the fact.

Thread Diagnostics (test): Thread Diagnostics | Homey
Source: GitHub - stefan-schweiger/dev.schweiger.thread-diagnostics: Homey app that continuously logs Thread mesh and Matter device diagnostics · GitHub

It records role, leader data, partition ID, router/neighbor/child tables and OpenThread history events (role/partition changes, neighbors added/removed, captured between polls too) every 10 s, topology every 60 s, Matter node details every 15 min, and logs every (un)availability change in realtime with the device’s mesh identity. Everything lands in daily log files you can view/export from the app settings, plus Insights graphs.

One caveat: apps can’t call Homey.thread.executeCommand themselves (the homey:manager:api token lacks the required homey.system scope), so the full OpenThread diagnostics need an API key with full access (my.homey.app → Settings → API Keys) pasted into the app settings. Without it you still get topology, Matter nodes and availability logging.

Note that this is meant as a temporary debugging tool, not something to run forever: it writes a few MB of logs per day (capped at 25 MB by default, oldest files are pruned) and polls constantly, so uninstall or pause it once you’ve captured the problem.

@Pascal_Nohl this should cover what you asked for, no scripting needed.

[DaneedeKruyff]

@staeff

an app that continuously logs Thread/Matter diagnostics

Nice! Will you be starting a separate topic for this app?

[staeff]

Here you go [APP][Pro] Thread Diagnostics - Continuously log your Thread mesh & Matter device health

[staeff]

@Doekse anything that can be done about this? otherwise at least for me it’s fine to keep it as a test version, as long as people are still able to access it.

Thank you for submitting Thread Diagnostics to the Homey App Store, and for the effort you have clearly put into building it.

After reviewing your submission, we found that the app relies on a private, undocumented Homey API to retrieve deep diagnostics of the ThreadBorder router. Using private or undocumented Homey APIs is not allowed.

Because of this, we are unable to approve the app for the Homey App Store. You are of course welcome to keep using the app privately on your own Homey.

[Doekse]

To leave it in test permanently is perfectly fine

[smarthomesven]

@staeff

Using private or undocumented Homey APIs is not allowed.

Really? I was building an app using reverse engineered APIs as well. Guess I’ll have to obfuscate my code then

[deejayreissue]

@Pascal_Nohl

If Homey’s practical limit is substantially below the 250+ devices promoted for Thread-based smart homes, that limit should be clearly documented before purchase, not discovered by users only after their systems become unreliable.

It wouldn’t lend itself to very elegant marketing

It’s much more elegant to claim that your smart home hub is the most advanced, in the world

[mluecke]

Hi @Pascal_Nohl,

have you checked the channels of your Thread and Zigbee networks after joining Apple’s TBRs and Homey into a single Thread network? Because of Homey’s combined radio, I would assume they are now all operating on the same channel.

My general recommendation is also not to mix TBRs from different vendors. I’ve seen several issues over the past years after combining TBRs from Apple and Google or Aqara into a single Thread network. For example, not all vendors implement NAT64, and devices like the Nuki Ultra or Tado X require it for their cloud connection. Another issue I’ve seen is Google TBRs disabling their TREL support after joining an Apple Thread network.

If you already have a solid infrastructure with Apple TBR‘s, pair your Thread devices with Apple Home and only share them with Homey. If you don’t need a device in Apple Home, you can also remove it from Apple Home after sharing it with Homey. The device remains connected to the Apple Thread network.

Over the last few years, my Thread network has grown to 90 devices, based on two Apple TVs and two HomePod minis. I control all of my Matter over Thread devices from two fabrics, so the traffic is effectively doubled.

My Homey Pro had several mDNS handling issues before v13.3.0, which led to unavailable devices after changes in the Thread network and required a reboot of Homey. However, since that release, all of these issues have been resolved. If a device now becomes unavailable (effectively only IKEA battery powered devices), it affects all fabrics equally. Besides Homey’s more aggressive resubscription process after a reboot, its handling of Matter over Thread devices is now just as stable as the Home Assistant Matter Server.

EDIT: Avoid Nanoleaf devices! Their current firmware is still buggy and they don‘t work reliable as FTD devices.

[DirkG]

@Doekse

To leave it in test permanently is perfectly fine

Uh, no. I don’t entirely agree with that.
Users who aren’t active here on the forum will never be able to find this app. And forum users will only come across apps like this by chance, if at all.
By the way, this doesn’t just apply to this one, but also to several other apps that never made it past the “testing phase.”
Of course, for apps like these and others to be published in the App Store, they must meet Athom’s requirements.

[Pascal_Nohl]

@Doekse

and that scalability depends on having sufficient routing infrastructure and a healthy mesh.

I agree. In my case, however, there are already more router-capable Thread devices than the network can use as active Routers, so some of them necessarily remain in a non-router role. A lack of potential routing infrastructure is therefore unlikely to be the main limitation here.

But the more important point is that we are not only discussing the capacity of the Thread mesh. We are also discussing the capacity of Homey itself.

Homey has to manage Matter, Zigbee, Z-Wave and Wi-Fi devices, as well as apps, Flows, subscriptions, state updates and many other background processes. All of these consume processor time, memory and internal resources.

I would not expect Athom to guarantee one exact number under every possible condition, nor even necessarily a separate fixed limit for each protocol. Devices differ too much in the number of endpoints, capabilities, reports and messages they generate.

However, considering that Athom knows the hardware, software architecture and internal resource management of Homey, it should certainly be possible to publish a realistic guideline such as:

Designed and tested to handle 150+ devices in a typical mixed smart-home installation.

Or, if the hardware and software support it:

Designed and tested to handle 250+ devices.

That may initially appear less attractive from a marketing perspective than leaving the capacity undefined. In the long term, however, it would be a major advantage.

It would help users design realistic installations, reduce speculation about whether an undocumented limit has been reached, prevent disappointment and probably avoid a considerable number of support cases.

Clear and honest capacity guidance would build far more confidence than allowing users to discover practical limits only after their systems become unreliable.

[deejayreissue]

@mluecke

based on two Apple TVs and two HomePod minis

Well what you’ve done is proven that Homey Pro alone can’t handle the high density Thread mesh. You need multiple TBRs and a Leader with a better chipset?

[Pascal_Nohl]

@Doekse I did not install the app, as actually the system runs stable for some days, aside the Nanoleaf LED. I will replace it by a Philips Hue connected to the HUE hub and expose it to Homey. Then I will turn my night check flow off and see if Homey still has problems. Sorry for the delay, but I’m charged with many other projects for the moment. And no Wifi or IPTV is a no go for the family.

[Pascal_Nohl]

@deejayreissue

Well what you’ve done is proven that Homey Pro alone can’t handle the high density Thread mesh. You need multiple TBRs and a Leader with a better chipset?

That conclusion is not supported by the information provided.

A Thread Leader is not selected because it has the most powerful chipset. The Leader role is assigned dynamically to one of the active Thread Routers and is mainly responsible for administrative functions such as maintaining network data and assigning Router IDs.

It is not a central processor through which all Thread traffic must pass, and it does not handle the Matter logic for the complete smart home.

Likewise, the presence of several Thread Border Routers does not prove that a single Homey Pro is unable to handle the network. Multiple Border Routers are a normal part of the Thread design and provide additional routes and redundancy between the Thread mesh and the Ethernet or Wi-Fi network.

The Matter Controller is also a separate role. Homey may remain the Matter Controller for its commissioned devices even when an Apple TV or HomePod is the current Thread Leader or forwards their traffic through another Border Router.

Therefore, observing that the system works with two Apple TVs and two HomePod minis proves only that the network currently operates with several available Border Routers. It does not prove:

• that Homey Pro alone cannot handle the Thread mesh;
• that a more powerful chipset is required for the Leader role;
• or that the Apple device acting as Leader is responsible for the improved stability.

To support such a conclusion, one would need controlled comparison tests and diagnostic data showing that failures consistently occur when Homey is the only Border Router or becomes Leader, and disappear when an Apple Border Router takes over. Without that evidence, it remains speculation.

[deejayreissue]

Fair enough and I really appreciate the explanation

A bit of confirmation bias from me there then

Could it be at all possible that Homey Pro 2023/2026/mini, can’t handle the routing and ID assignments in the same way that other TBRs can with a high density mesh, but the Antenna and chipset itself is fine.

That’s essentially the problems I experienced. Routing and IPv6 addresses could not be maintained by HP2023 with more than about 25-30 devices.

[Pascal_Nohl]

@Doekse Just a little feedback: I replaced the Nanoleaf LED strip with a Hue LED strip and exposed it to Homey through the Hue Matter bridge. So far, the system has remained stable.

You mentioned that some devices may still be too “chatty”. Wouldn’t it be useful if Homey could identify such devices directly and inform the user?

For example:

“Device X is generating an unusually high number of Matter messages. Please review its reporting interval or related settings.”

Ideally, Homey could also indicate what kind of traffic is considered excessive, such as reports per minute, repeated retries or subscription updates.

That would make troubleshooting much easier than simply telling users that some device may be too chatty without showing which one is responsible.

[Doekse]

@Pascal_Nohl

@Doekse Just a little feedback: I replaced the Nanoleaf LED strip with a Hue LED strip and exposed it to Homey through the Hue Matter bridge. So far, the system has remained stable.

Great to hear that!

@Pascal_Nohl

Ideally, Homey could also indicate what kind of traffic is considered excessive, such as reports per minute, repeated retries or subscription updates.

Good point. I’ll check if we can maybe add the TX/RX and TX error data just like with Zigbee.

[huftfh]

Hello Doekse, I created a diag report several times but your support says it can’t solve this problem. They said it would foprward it to your development team. This was in march and I never heard back. For me it’s IKEA Dirigera and everything has been updated to the latest soft- and firmwares.

[Doekse]

So what is the exact issue you are facing?

[huftfh]

Same as described above, almost everyday I loose all my IKEA devices for them to come back after a few hours.