A smart-home device can have internet access and still be unreachable from Home Assistant.

That is because local control depends on more than “the Wi-Fi works.”

For Matter, two ideas are especially important:

  • local IPv6 communication;
  • local discovery traffic such as multicast.

When those are blocked, a healthy endpoint can look unpairable.

Matter can use IPv6 locally without an IPv6 internet service

This distinction prevents a common misunderstanding.

Matter uses IPv6 for its IP communication.

That does not mean the household must have an IPv6 internet connection.

A home can use ordinary internet service while Matter devices communicate with IPv6 addressing inside the local network.

The important question is whether the relevant local devices and controllers can communicate across the LAN.

Discovery is part of the control path

During commissioning, several components may need to find and reach one another:

  • the endpoint;
  • the commissioning phone;
  • Home Assistant;
  • the Matter controller or server;
  • the Border Router if Thread is involved;
  • the local network infrastructure.

A product may be powered correctly and connected to a radio network yet still fail because discovery traffic is not crossing the boundary you created.

Check the simplest local path first

Before adding segmentation, prove a known-good baseline.

For a new Home Assistant installation, a simple trusted LAN is easier to validate than a design with:

  • multiple VLANs;
  • guest-network rules;
  • multicast relays;
  • complex firewall exceptions;
  • unusual IPv6 blocking.

Segmentation can be useful.

It also creates more places where local discovery can fail.

Start simple, confirm the system works, then add boundaries deliberately.

Guest networks can be the wrong place for commissioning

Guest Wi-Fi often isolates clients intentionally.

That is useful for visitors.

It can be a problem for commissioning because the phone may be prevented from reaching Home Assistant or local devices.

If pairing fails, check:

  • Is the phone on the expected home SSID?
  • Can the phone reach Home Assistant locally?
  • Is wireless client isolation enabled?
  • Is the endpoint itself on a network that cannot communicate with the controller?
  • Did an “IoT isolation” feature block the required local peer traffic?

A device appearing in a vendor app does not prove the Home Assistant path is healthy.

The vendor app may be using a different control path.

VLANs need a deliberate discovery design

Advanced users often separate IoT devices onto their own network.

That can improve containment.

It can also break discovery if the rules were designed only around ordinary IPv4 connections.

If you segment the smart home:

  1. begin from a working flat-network baseline;
  2. document which traffic must cross boundaries;
  3. account for IPv6 as well as IPv4;
  4. provide the required multicast discovery path deliberately;
  5. test commissioning as well as normal control;
  6. change one firewall or routing rule at a time.

Security that silently breaks local control and leads to broad emergency exceptions is not automatically better security.

Do not block all IPv6 as a generic hardening rule

Rules copied from unrelated network guides can conflict with the technology you chose.

If Matter requires local IPv6, a blanket “disable or block IPv6 everywhere” policy can break the system you are trying to secure.

Security design should begin with the actual protocols and control paths in use.

A useful network troubleshooting sequence

When Matter commissioning times out:

1. Define the symptom

Did the QR code scan?

Did the device join Wi-Fi or Thread?

Did it fail before or after Home Assistant appeared to see it?

2. Confirm the phone path

Make sure the phone is on the intended home network and can reach Home Assistant.

3. Identify the transport

Do not look for a Thread Border Router if the endpoint is Matter-over-Wi-Fi.

If it is Matter-over-Thread, identify the intended Thread network and Border Router.

4. Review recent network changes

Did the failure begin after:

  • a router replacement;
  • new access points;
  • a VLAN migration;
  • enabling guest or client isolation;
  • firewall changes;
  • multicast-related settings;
  • an IPv6 policy change?

Restore or reproduce the working baseline before resetting multiple endpoints.

5. Test another known-good device

If every Matter device fails at once, look at the shared controller or LAN.

If only one endpoint fails, keep the scope narrow.

Wired infrastructure reduces variables

Where practical, fixed infrastructure such as:

  • the Home Assistant host;
  • main access points;
  • bridges;
  • routers;

can benefit from stable wired paths.

The point is not bandwidth.

It is removing a wireless variable from the nodes that everything else depends on.

Keep an infrastructure list

Record the roles, not just the product names:

  • Home Assistant host;
  • router;
  • access points;
  • Thread Border Router;
  • Zigbee or Z-Wave coordinator;
  • vendor bridges.

For each, note its connection and why it exists.

The exact products will change.

The roles remain useful during a failure.

Change one layer at a time

Do not solve a commissioning failure by simultaneously:

  • factory-resetting the endpoint;
  • rebooting the router;
  • changing VLAN rules;
  • removing the Matter integration;
  • changing Thread credentials.

That destroys the evidence needed to identify the cause.

Preserve the symptom, identify the first uncertain layer, change one variable, then verify.

Continue with the Home Assistant Matter commissioning troubleshooting checklist. If the endpoint uses Thread, also check Thread Border Router networks, credentials, and coverage.