Hi
I often see that Homey Pro 2026 looses connection to several of my units (Matter).
All those units work in HomeApp and their respective app like Aqara or Nanoleaf - just not in Homey.
Any suggestions to this issue?
I’d rather not reconnect each unit each time 
/Thomas
Have you tried adding Nanoleaf devices via the LAN connection instead of Matter?
They are added with that app, so I guess that part is ok?
Maybe you can check if you can add it by choosing a non-Matter device from the list (then it will use LAN connection).
Do you loose only Matter over Thread devices or also Matter over Wifi devices ?
Do they come back for some time when you reboot Homey ? - and go unavailable after some time ?
You can also add Aqara devices via ZigBee
I’m not sure where to check that?
At the moment I have lost connection to some LIFX bulbs, that via the app (LAN).
And Eve Energy Matter versioner + Aqara DoorWindow Sensors and Presense Sensors.
Will try …
In the settings of the device, under Advanced Settings you see the Network type.
My Homey just lost Matter over Thread devices. Homey has some bigger problems as Zigbee and Thread share one chip one antenna and one channel, that’s called multiprotocol and that’s often a problem, even in Home Assistant.
You can not set the channel, you can only reshuffle the channel as often as required to come close to the channel you want. Warning: doing so you will loose all Zigbee and Thread devices and you have to repair them all and to repair your flows.
I did it until I got channel 15 and then I started tweaking my Wifi. Separate 2.4. Ghz channel for IoT, 20 Mhz, not 40 Mhz, beam forming off, radio power a little bit lower, etc. But unfortunately my Wifi system does not give me access to all granular settings. Since then, Thread seams relatively stable, but I’m unable to reach one of my Matter over Wifi devices (I suggest lower Wifi radio power is the culprit) and a Nanoleaf LED stripe comes and goes from time to time (did the same thing undr Apple Home, so I suggest this is a Nanoleaf thing).
I also plan to switch my Wifi over to an Omada system, to get even more control, but that’s an investment for later.
I do not know if this helps you much, but I wanted to share my experience and to show you that you are not alone with these problems on Homey.
You may connect your devices that are Zigbee and Thread over Zigbee, but it will not solve the general problem.
Often, these Matter over WiFi devices can also be added without Matter via a (community) app specific to that brand (which is often more stable). I would recommend checking out other communication methods for your Matter over WiFi device like LAN or Cloud connectivity
Seems like a big job and my skills aren’t so good at this 
So I should avoid mixing ZigBee and Thread? Will that help?
I have only 1 ZigBee unit - T1 Lightstrip from Aqara, but it’s connected to an Aqara Hub M3 with ZigBee and then the Hub is Thread/Matter to Homey.
I don’t agree. Matter is actually very stable and has many advantages. The problem is the transport protocol. I use Matter for all my devices for the following reasons:
For my Sonoff MINIR4M that I can’t reach with my actual Wifi settings, I will try a Shelly One Mini GEN 4 with Matter support. The Sonoff is also known to have a weaker Wifi radio as the Shellys. But I will use Matter, no Shelly app anymore.
I prefer Matter too and less apps …
I have a Sonoff MINIDIM with matter, works great!
I use Matter for none of my devices for the following reasons:
I would also need to link Matter devices to Homey via Google Home and virtual devices or eWeLink CUBE, since my Homey 2019 doesn’t natively support Matter.
So for me, Matter is simply not worth the effort and security risks.
That statement mixes up what Matter is with the network it runs on. Matter is an application-layer standard on top of IP, and it runs over Thread, Wi-Fi, or Ethernet. If devices “can’t be found” or “go offline”, the root cause is usually the transport / discovery path (Thread Border Router health, Wi-Fi reliability, multicast / mDNS handling, controller bugs), not “Matter itself.”
Often yes in practice, especially for discovery: Matter commonly relies on mDNS / multicast, and that traffic typically does not cross subnets/VLANs by default. You can make segmented networks work, but you usually need mDNS reflection / gateway rules (and correct firewalling) so the controller can discover and reach devices. If you are talking about pro security features, you should be able to configure this. Or your LAN and Wifi system is consumer grade and you don’t have full control or full knowledge.
This can be true Many Matter devices are designed to be controlled primarily through a Matter controller (Apple Home / Google Home / SmartThings / Home Assistant / Homey, etc.). If you only commissioned the device to Homey and Homey is down, you may indeed lose control.
However, Matter’s multi-admin feature allows you to add the same device to multiple controllers (“fabrics”), so you can keep a second ecosystem as fallback if Homey goes offline.
That’s a valid practical limitation. If your hub can’t act as a Matter controller (or doesn’t support Thread where needed), you can’t expect a modern Matter setup to work “natively” on it. But, that is not a technological choice against Matter but a practical one.
Yes, I have two. One works great. The other one worked also great until I turned Wifi power a little bit down to interfere less with Thread. Now it ist probably out of the Wifi range. The Shelly has a stronger radio built in, that’s why I plan to replace it and test it.
The Sonoff MINIR4M ist a good device, but has weaker radio (technical description). From my memory : Sonoff 15db, Shelly 20db.
I use pfSense with a Zyxel Nebula AP, and those can be configured to have multiple networks (VLANs) and client devices can be configured on a specific VLAN based on what SSID is used and password they use for connecting to that SSID (DPPSK). I have configured many devices to block local network access entirely (most devices are cloud-connected anyway), I’m quite hesitant with local LAN communications in general, since you would essentially have a point of entry into your IoT network for attackers (if the cloud service that the device uses gets compromised, they might be able to reach other IoT devices inside my IoT network). For this reason, I only allow local communications when strictly necessary. Homey is still able to reach devices since it’s on the “safe” IoT VLAN and return traffic is allowed for the “unsafe” IoT VLAN, but most devices are isolated from reaching each other, which means that discovery (mDNS) is not possible.
The only way Homey (or any other controller) can reach the device is by manually entering its IP, which is AFAIK not possible with Matter.
I think we actually agree more than it looks like.
With your pfSense + VLAN + DPPSK setup you can run Matter securely without increasing risk, as long as you keep the same security principles:
Keep “unsafe IoT” devices isolated from each other (no east-west).
Place the controller (Homey) in a “safe/controller” VLAN.
Allow only controller → device traffic (stateful return only), with tight firewall rules.
Enable mDNS/DNS-SD only between those two VLANs (reflection/relay limited to controller↔IoT), rather than opening multicast broadly.
This preserves your zero-trust posture while still allowing Matter discovery/commissioning to work.
Also, “cloud-only” isn’t automatically safer — it just moves the risk:
you reduce local attack surface and lateral movement, but you increase dependency on vendor accounts/backends, availability, and the blast radius of an identity/backend compromise, especially for China brands. So it’s a trade-off, not a clear win.
In short: your current design is valid (and very strict), but it intentionally breaks local discovery. If you want Matter, you can keep it just as locked down by allowing a minimal, controlled local channel instead of going “flat LAN”.
