Matter devices are unavailable

[Pascal_Nohl]

@JMDPC

However, if I pair the device to Homey first and then share it to Apple Home, the device drops from Homey and does not come back online, even though it is still active in Apple Home.

That is actually very similar to what I reported when I first started using Homey.

At that time, all my Matter-over-Thread devices were commissioned to Apple Home first and then added to Homey using Multi-Admin.

I personally avoid the word “shared”, because Multi-Admin does not really mean that one controller shares the device with another. The device is commissioned into an additional Matter fabric and receives another set of credentials. It then communicates independently with both controllers in parallel.

And I saw exactly the same symptom: devices became unavailable in Homey while they were still perfectly reachable in Apple Home.

At the time I was advised that it would be better to commission the devices directly with Homey first. My understanding of Thread was much more limited then, and I assumed this somehow meant using a different Thread network, so I eventually migrated everything to Homey.

Now I am doing almost the reverse and gradually commissioning the devices with Home Assistant and adding Homey through Multi-Admin. The important difference is that I now know that the Thread network itself remains the same.

For me, this gives us a useful way to separate possible causes:

• If the same Matter-over-Thread device fails at the same time in both HA and Homey, the Thread network or the device itself becomes a much stronger suspect.
• If it remains fully responsive in HA while Homey loses it, that points much more strongly towards Homey’s Matter/Thread handling.
• If Matter-over-Wi-Fi devices show the same Homey-only failures, then the Matter stack becomes a stronger suspect than Thread itself.
• And if Thread really is the problem, HA gives us considerably more topology, routing and link-quality information to investigate it.

That is actually the main reason I am doing this migration step by step rather than simply switching everything over at once: it gives us a period where the same devices and the same Thread network can be observed through two independent Matter controllers.

Edit

One very useful tool in Home Assistant is its automatic timeline/logbook, which records state changes and actions without requiring the user to build complex logging manually. That alone makes debugging much easier.

HA also has a simple “Write to log” action in the visual automation editor. This makes it very easy to add additional information to the timeline when needed. For example, when motion is detected, I can also write the current luminance value to the log at exactly that moment.

So even without creating a dedicated diagnostic system, it is quite easy to build up a useful history of what happened, when it happened, and under which conditions.

This is really missing in Homey. It’s a fundamental debugging tool.

[Pascal_Nohl]

@Doekse
This Flow worked only 3 out of 10 times, and I currently have no explanation why.

There was no device-unavailable state and no error reported by Homey. It simply looks as if the device sometimes does not respond to the command.

There is another strange detail in my existing logs. Closing the window also triggers another Flow that controls the heating in that zone. The close event definitely triggers the Flow, but 30 seconds later the zone is reported as open:

So the closing event is received, yet shortly afterwards Homey apparently evaluates the state as open again. I don’t yet know whether this is related to the same problem.

For comparison, I rebuilt the locking automation in Home Assistant and disabled the corresponding Homey Flow:

So far, the HA automation triggers correctly every time:

And the detailed HA logs make it much easier to see exactly which state changes and actions occurred and in which order.

At this point I am not drawing a conclusion about the cause, but it is another case where Homey reports no error while the expected physical action does not reliably happen, whereas the same logic currently works consistently through HA.

[Doekse]

As mentioned, I can’t really do much without a diagnostic report.

At this stage I also don’t have a clear overview over which Flows control what so I also can’t really comment about that.

[Pascal_Nohl]

@Doekse

I can’t really do much without a diagnostic report.

The question is whether a diagnostic report will actually contain anything useful when Homey does not report an error at all. In the past I was repeatedly told that if no error was recorded, there was often very little to see in the diagnostics.

Anyway, when to create a report if the problems are not happening always and no visible feedback is available ? - I don’t even see the error in my own logs.

What concerns me more is that the behaviour seems to have changed over the last two updates.

Before those updates, affected Matter devices typically became unavailable and Homey threw an error. Since then, I increasingly see something different: the device remains available, Homey reports no error, the Flow continues down the success path — but the physical device simply does not react.

I have now observed this with several devices, so in my installation it is starting to look less like an isolated incident and more like a general pattern.

That does not prove that the updates caused it, of course. But the change from “device unavailable + error” to “device available + no error + command not executed” is significant enough that I think it is worth investigating specifically.

[smarthomesven]

@Pascal_Nohl

But the change from “device unavailable + error” to “device available + no error + command not executed” is significant enough that I think it is worth investigating specifically.

At least for LAN/Cloud/BLE apps, the developers need to specifically run setUnavailable() on the device instance in order for the device to be marked as unavailable. Not sure if this is also the case for the more standard protocols like Zigbee, Z-Wave and Matter, but if the developer didn’t implement the unavailable status correctly, it can get shown as available in the app while the device is actually unreachable. I know not all app developers set the unavailable state when the device is unreachable.

I just want to say that Unavailable is only a flag that apps can set in the device instance. It’s not an error either, devices aren’t automatically set to unavailable when an error occurs.

[Pascal_Nohl]

@smarthomesven

It’s not an error either, devices aren’t automatically set to unavailable when an error occurs.

Again, that misses the point.

Nobody said every error makes a device unavailable. We are talking about Homey losing communication with a Matter device, after which the system may mark that device unavailable.

That is not the same thing as “an error flag set by a programmer”.

My point was simply: before, communication failures often resulted in unavailable + error. Now I increasingly see available + no error + device does nothing.

Those are two different failure modes.

[smarthomesven]

But if we have this code for example:

try {
  const temperature = await this._deviceApi.getTemperature();
  await this.setCapabilityValue("measure_temperature", temperature);
} catch (err) {
  this.error("Failed to set capability", err);
}

If this fails, then a diagnostics report can still contain something useful while the error is not visible. Just because you don’t see any errors, doesn’t mean that there are no errors.

[Pascal_Nohl]

@Doekse

Created diagnostic report 83C18F4B.

Some devices are unavailable again, but let’s look at this one in particular:

Homey reports it as unavailable.

At exactly the same time, the same physical device was available in Home Assistant and I could control it without any problem:

Both controllers use the same single Thread network, just different Matter fabrics.

So at that moment the device was clearly still reachable through the Thread mesh. Of course HA may have used a different Border Router or route, but the device itself was not simply absent from the Thread network.

That should hopefully make this diagnostic report particularly useful, because we now have a concrete case where Homey considers the device unavailable while another Matter controller can still communicate with it normally over the same Thread network.

[Pascal_Nohl]

With the 2026.9 update, Home Assistant now includes a map for the Matter network — in other words, all Matter devices in the fabric, regardless of whether they communicate over Wi-Fi or Thread.

The nice part is that the map finally shows the actual device names instead of cryptic IDs.

And simply hovering over a device immediately shows the relevant details:

And hovering over the link show the link details and quality:

EDIT:
Also this is a missing information in Homey:

@Doekse
And a new one after restart: EA840A9E
Homey does not recover. 26 devices are unavailable.

[Pascal_Nohl]

@Doekse
And anther diagnostic report: F0B8F43D
2/3 of the devices not available.

And a new one after restart: EA840A9E
Homey does not recover. 26 devices are unavailable.

[Mike_Nono]

All my Matter over Thread was offline this morning. (the matter over wifi was good)
First time ever on my homey.
(Except one bulb that is far away from homey, it has gone offline once before)

But yesterday I connected the ethernet homey adapter, and I was using wifi only before.
So now I had wifi and the ethernet connected at the same time. It was ok till this morning.

So I did disable/block the wifi.
And only have the ethernet connected.

And all of the MoT came online. (Did not reboot)

So now I just have to wait and see if it’s still going to be ok.
Since Wifi and Ethernet was not playing well together.

[Rammstein]

Do you have enable the automatic update funktion because Athom release in the night the new version v13.5.0 where they upgrade the thread up to 1.4, maybe this caused the crash? Out from my experience if i change anything on network side or in the thread network itself i must always reboot my homey to get back a stable thread network…also in my crashes which i had reported all to Athom it was the same, without reboot my Thread on Homey Pro 26 will never run again…by the way, Athom recommend if you use the ethernet connection to disable the Wlan…however i had never understand it why and i guess in my setup currently Wlan is on although i use Ethernet as well…everything is running well in the moment…but I don’t want to jinx it, because whenever I said or wrote that, my next crash came shortly afterwards.

[Mike_Nono]

No I did not update homey, still on 13.4.1. (auto update off)
All I did was to connect the ethernet adapter and left wifi on aswell, but it did not work well.

I will not do an update and change other stuff at the same time, since then I don’t know what was the failure in case something fails. Like now

[Rammstein]

Did you take a report in fault situation? In one of my post above i wrote already what Athom expect and need to be able to analyze a Thread Crash…important is to report the problem with Report in fault situation and after in stable situation but there are many other things which Athom request as well…

[Mike_Nono]

No I did not report. I will check if everything is ok using the adapter only, and no wifi
Then I might connect wifi and ethernet again and let it crash if it does and report.

Edit: Other thing I just noticed was the CPU Temp when from 62° to 55° after I turnd of wifi

[UlfsHomey]

Hi, same for me Lafaer Presence Sensor was offline some days ago

restart of homey, wlan and reset of sensor didn’t change anything.
I deleted the device and tried to re connect, without any success.
First i though the sensor was broken, but i tried to add a second matter device as well without a result. Thus mybe the matter chip of homey is broken, but if more people have same problems, maybe it is a homey software probleme? I have installed 13.5.0
My diagnostic id: D87588F2

I hope there is a quick solution, as the presence sensor is a central device in my home automation as you could imagine

regards

[Valerii_Ianchenko]

@UlfsHomey

I have installed 13.5.0

After I’ve installed 13.5.0, I’ve lost all IKEA Matter devices. Reconnecting doesn’t help. I’ve tried turning Homey off for 1 hour, and after turning it on, I’ve waited at least 24 hours. All Bluetooth and Zigbee devices works well.

[UlfsHomey]

hi Valerii,

I got already an answere from the support

This issue is a known issue at the moment, which has also been reported by several other Homey users, and is actively being investigated by our development team. Unfortunately, such investigations take some time, and testing and publishing a fix for this issue as well.

I can’t give you a specific timeframe yet in which this issue will be resolved, but know that this issue is getting the attention it deserves.

I guess this information is also of value for you

[Valerii_Ianchenko]

I’ve brought all devices back to life after the IKEA app restarted. I’m not sure if this app is getting any updates this week.

[Eek]

Same problem. The mather over thread devices lost connection. Had a homey update, but also an iOS/tvos27 update.

any news?