BETA — Open to testers. Tell us what to fix on @vomehome or via a tester code.

When devices are not discovered

Why UPnP, DLNA, Chromecast and Matter cannot find hardware that is definitely switched on — and the two ways to fix it.

Updated 26 August 2026 networkingtroubleshootinghomelink


Device discovery works by broadcasting a question to everything on the local network and listening for replies. Those broadcasts are designed never to leave the network they were sent on — routers must not pass them along.

So a Home Assistant that is not on the same network segment as your devices will never hear them, however fast or reliable the connection between them is. This is not a fault to be tuned away; it is the protocol working as intended.

Your devices Router Hosted HA "who is out there?" stops here "device at 192.168.1.31, are you there?" — works fine
Broadcasts stop at the router by design. Asking a device you can name passes straight through, which is why ESPHome, MQTT and Bluetooth proxies are unaffected.

Matter is stricter again: it needs IPv6 on the local segment, which an ordinary routed tunnel does not provide at all.

Two ways to fix it

Add the device by address. Many integrations accept a hostname or IP directly. Give the device a fixed address on your router first so it cannot move.

Use HomeLink L2 mode. This extends your home network itself to the hosted server, so it shares one broadcast domain with your devices. Discovery and Matter then behave exactly as they would on a machine plugged into your switch. How it is set up, what it changes, and the faults that look like a broken VPN, are in HomeLink L2. The steps, and why they are shaped that way, are Set up HomeLink L2.

L2 mode changes how your home network is bridged

It is set up deliberately rather than by default, and it installs with an automatic rollback: if anything goes wrong and the connection is lost, it undoes itself without anyone visiting the house.

When L2 is up but Matter still is not

Matter and Thread need IPv6 on the local segment. A tunnel that is perfectly healthy for IPv4 discovery — UPnP, Chromecast, ordinary mDNS — can still drop IPv6.

The signature we have seen: devices appear, then go unavailable the moment anything tries to talk to them. On the first L2 customer that was bridged IPv6 being dropped by the host firewall while IPv4 mDNS worked perfectly — and, separately, multicast snooping black-holing IPv6 toward the tunnel. Neither is something you can fix in Home Assistant.

Home Assistant also picks a NIC per service. With two interfaces it can advertise Matter onto the management network while the house LAN full of real devices goes unused. L2 servers keep the house NIC as primary and strip the gateway from management so it stops competing.

Matter-over-Thread needs two more things that are nothing to do with the tunnel: a border router — a Thread radio, which has to be inside your house — and a Bluetooth path for pairing. Pairing is Bluetooth; day-to-day is Thread. The picture is how Thread and Matter actually work. What you need on a hosted instance is Thread and Matter with a hosted Home Assistant, and "your device requires a Thread border router" is usually about your phone rather than your server. Appearing in the Thread panel is not the same as Home Assistant holding the Thread credentials.

Tell support if you see it; include that IPv4 discovery works and Matter does not. A healthy IPv4 test proves nothing about IPv6.

Rather not do this alone?
The Vome assistant will walk you through this guide a step at a time, and can do some of it for you.
Sign in for AI help

Something wrong or missing here? Tell us — these pages are written from real work, so corrections are welcome.