# Issue with Matter on self hosted Homey **URL:** \ **Category:** Homey Self-Hosted Server\ **Tags:** matter\ **Created:** [December 18, 2025, 8:09am UTC](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203 "2025-12-18T08:09:08Z")\ **Posts on this page:** 1\ **Showing post:** 83
**Author:** ![allexiel](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/allexiel/32/155404_2.png) [@allexiel](https://community.homey.app/u/allexiel)\ **Post date:** [February 17, 2026, 8:44pm UTC](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203/83 "2026-02-17T20:44:50Z")
> [@majorzoltanpepe](#): > > ## Solved: Homey SHS (Synology/Docker host mode) can’t add Matter-over-Thread devices (stuck on “Searching…”) > > Hi All, I had the same issue, and it was very annoying after I’ve spent 100+ EUR on IKEA sensors 🙂 It took me a day but I’ve managed to find the solution, and now it’s working. Here are the details: > > * * * > > ### Symptoms > > - Homey Self-Hosted Server (SHS) runs on **Synology DSM / Container Manager** (Docker). > - Matter-over-Thread devices: > - Pair fine in **Apple Home** (HomePod minis as Thread border routers). > - Pair fine when running SHS on a **MacBook**. > - **Fail only on Synology SHS** : QR/code is accepted, then Homey keeps **“searching”** and eventually times out. > > - Matter-over-Wi-Fi devices work normally. > > ### Root cause (what it turned out to be) > > Homey SHS on the Synology could **discover** Matter devices via mDNS, but it could not **reach** the Thread devices’ IPv6 mesh addresses (ULA prefix like `fd29:...`) on TCP **5540** (Matter). > The Synology host was missing an IPv6 route to the Thread mesh prefix that macOS had automatically. > > * * * > > ## Analysis / How to confirm it > > ### 1) Check that Synology sees Matter services (discovery works) > > SSH into Synology and run: > > ```auto > avahi-browse -rt _matter._tcp > > ``` > > You should see `_matter._tcp` endpoints and IPv6 addresses like `fd29:...` (Thread mesh ULA). > > ### 2) Compare IPv6 routes: MacBook vs Synology > > On a Mac (where SHS worked), check IPv6 routes: > > ```auto > netstat -rn -f inet6 | egrep 'fd29|default' > > ``` > > In my case, macOS had a route like: > > ```auto > fd29:....../64 -> fe80::xxxx%enX > > ``` > > Meaning: “send Thread mesh prefix traffic to this link-local next hop” (HomePod mini border router). > > On Synology, check routes: > > ```auto > ip -6 route | egrep 'fd29|default' > > ``` > > **No `fd29:.../64` route existed** , only default route. > > ### 3) Verify Homey container inherits the same routing (host mode) > > My Homey container was running in **host networking**. > To inspect from inside Homey’s namespace, I used a netshoot container: > > ```auto > sudo docker run --rm -it --network container: nicolaka/netshoot sh > ip -6 route > > ``` > > Then test connectivity to a Thread device: > > ```auto > nc -6 -vz -w 3 5540 > > ``` > > Before the fix, it always timed out: > > ```auto > failed: Operation timed out > > ``` > > That’s why Homey pairing hung on “searching”. > > * * * > > ## ✅ Solution: Add the missing IPv6 route for the Thread mesh prefix > > ### 1) Ensure RA acceptance is enabled (good practice) > > On Synology: > > ```auto > sudo sysctl net.ipv6.conf.eth0.accept_ra > > ``` > > Set to 2 (accept RAs even if forwarding is enabled): > > ```auto > sudo sysctl -w net.ipv6.conf.eth0.accept_ra=2 > sudo sysctl -w net.ipv6.conf.all.accept_ra=2 > sudo sysctl -w net.ipv6.conf.default.accept_ra=2 > > ``` > > ### 2) Add an IPv6 route for the Thread prefix via the border router (HomePod mini) > > From the Mac route table (`netstat -rn -f inet6`) I found the next hop (link-local) used for `fd29:.../64`, e.g.: > > ```auto > fd29:.../64 -> fe80:... > > ``` > > Then on Synology I added the same route (without the `%iface` part): > > ```auto > sudo ip -6 route add fd29:.../64 via fe80:... dev eth0 metric 50 > > ``` > > Confirm it exists: > > ```auto > ip -6 route | grep fd29 > > ``` > > ### 3) Re-test Matter reachability > > Inside netshoot / Homey namespace: > > ```auto > nc -6 -vz -w 3 5540 > > ``` > > After adding the route, Homey SHS could finally reach the device and pairing succeeded. > > ### 4) Pair again in Homey > > After the route was added, I could successfully add Matter-over-Thread devices in Homey SHS. > > * * * > > ## Making it persistent (important!) > > The route will disappear after reboot. Create a DSM **boot-up task** : > > DSM → Control Panel → Task Scheduler → Create → Triggered Task → User-defined script > Event: **Boot-up** > User: **root** > Script example: > > ```auto > /sbin/sysctl -w net.ipv6.conf.all.accept_ra=2 > /sbin/sysctl -w net.ipv6.conf.default.accept_ra=2 > /sbin/sysctl -w net.ipv6.conf.eth0.accept_ra=2 > > /sbin/ip -6 route add fd29:.../64 via fe80:... dev eth0 metric 50 2>/dev/null || true > > ``` > > ⚠ Note: if Apple switches the active Thread border router to another HomePod, the link-local next hop may change. For stability, consider: > > - disabling “Automatic Selection” for Home Hubs in Apple Home, or > - updating the route if the active border router changes. > > * * * > > ### Summary > > If SHS on Mac works but SHS on Synology hangs on “searching”, check IPv6 routes. > **Missing `fd29:.../64` route on Synology was the cause.** Adding the route fixed Matter-over-Thread pairing in Homey SHS. > > * * * > > If it is too technical I recommend paste this solution into chatGPT and ask it to walk you through the process step by step. Hope it helps. Cheers, Pepe Hi all, sharing another Matter-related fix for Homey SHS on Docker. This is a different issue from Pepe’s IPv6 routing fix (great post!), but equally frustrating. It took some digging but the fix is permanent and clean. * * * **Symptoms** - Homey SHS runs on a NAS (UGREEN DXP2800) in Docker with network\_mode: host - Matter daemon fails to initialize on startup - Homey logs show: ENDPOINT\_POOL\_FULL (0x00c1) - Other Homey features (Zigbee, Z-Wave, Wi-Fi devices) work fine - Restarting Homey sometimes fixes it temporarily, especially if you stop other containers first **Root cause** The Matter stack uses the CHIP SDK, which tries to bind a UDP socket on every host network interface at startup. There’s an internal limit of roughly 16–18 endpoints in the pool. On a NAS running multiple Docker stacks, the host interface count explodes because: - Each Docker bridge network creates 1 host interface - Each bridge-connected container creates 1 veth pair (another host interface) - Add libvirt bridges, loopback, your physical NIC… it adds up fast In my case I had 24 interfaces — well over the limit. The CHIP SDK ran out of endpoints trying to bind them all, and Matter never started. How to check if this is your problem SSH into your NAS and count interfaces: ip link show | grep -c ‘\[1\]’ If this number is above ~16, and you see ENDPOINT\_POOL\_FULL in your Homey logs, this is likely your issue. You can also see what’s eating up interfaces: # Docker bridge networks (1 interface each) docker network ls # veth pairs from bridge-connected containers ip link show | grep veth **Solution: reduce host interfaces by consolidating Docker networks** The idea is simple: instead of each Docker Compose stack creating its own bridge network, make them all share a single one. Then use the sidecar pattern to group containers that can share a network namespace (= 1 veth for the whole group instead of 1 per container). **High-level steps:** 1. Create one shared Docker network: docker network create --driver bridge shared 2. Move all stacks to the shared network. In each docker-compose.yml, replace per-stack networking with: networks: shared: external: true 3. And on each service: networks: - shared 4. Group related containers as sidecars. If containers don’t need to talk to the outside world independently make one the “anchor” and attach the rest: # Homey Matter logs (should show clean init, no ENDPOINT\_POOL\_FULL) docker logs homey-shs | grep -i matter **Important notes** - The sidecar pattern means if the anchor container restarts, its sidecars temporarily lose network. They recover once the anchor is back. - All ports for a sidecar group must be declared on the anchor service. - Host-mode containers (like Homey SHS itself, Zigbee2MQTT, Mosquitto) don’t create veths — they’re already fine. - When adding new containers in the future, always use the shared network or sidecar pattern. Never let a stack create its own bridge network, or your interface count will creep back up. Hope this helps someone else. The error message ENDPOINT\_POOL\_FULL is pretty opaque and there’s not much about it online in the context of Docker. Cheers! * * * 1. 0-9 --- _[View the full topic](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203)._