Issue with Matter on self hosted Homey

[Rudy_De_Vylder]

I have an OTBR running on Home Assistant and from day one I was facing the 0x00AC error.
What made this particularly frustrating is that sharing worked perfectly fine with my other border routers (Nest Hub and Homey Pro 2023). IPv6 in my setup was working correctly as well, and I could reach my Thread devices without issues using tools like NetShoot. So this was clearly not a “broken IPv6” or “basic network” problem.

To add some context about the environment: this SHS setup is running on a TrueNAS system on which I reliably host multiple apps and containers without any issues. This is a stable setup that has been in use for quite some time, not an experimental or misconfigured test environment.

After updating to v12.11, everything suddenly works flawlessly. I’m genuinely happy that I now finally have a fully working SHS.

That said, I do want to address the support experience, which I personally found disappointing.

After spending roughly two weeks actively following in multiple Matter and Thread-related forum topics, without any resolution, I decided to log a ticket with Homey. In my ticket, I explicitly stated that I had already searched and followed the forum extensively, and that there were multiple posts from users encountering the same 0x00AC error on different hosts.

The response I received was that Homey unfortunately could not provide support for my setup, that the 30-day trial exists for a reason, and that I should look on the forum for help, despite having clearly stated that I already did exactly that.

In my opinion, this is not customer-friendly, not to say arrogant.

What made it worse was that some forum members joined in by confidently stating that Homey could not possibly offer a solution here, and that the root cause must certainly be the user’s own installation or lack of knowledge. This was said without any understanding of the background or experience of the people they were responding to.

Everyone was a beginner at some point. Being addressed this way on a forum that is meant to help people is, frankly, discouraging.

For context: I installed my first Home Assistant instance back in 2014.
So yes, some of those comments were quite misplaced, and those members may feel addressed by this post.

I’m glad the issue is resolved with v12.11. I just hope that, going forward, both support responses and forum interactions can be handled with a bit more openness and respect, specially when multiple users report the same technical issue.

[Bram_H]

I completely agree. It was very poor.

In the forums I got the same response you did and on my support ticket an identical response. The Homey-SHS page states it supports Matter, but never did it mention I needed additional hardware for Thread. Maybe I could have known… but that set me back. Nevertheless I did have a Thread border router and it did not work. So the fact that I did not know that I needed it, made everyone say “you don’t understand how things work, it must be you”.

I started digging, but got lost since hardware I bought new (Matter-over-Wifi) did not work either… and now they said; “Yep! Confirmed! It’s your router, Docker config or you”.

This is the response I got in my support ticket:

… I understand the confusion about needing another hub other than the Homey Bridge to have a Thread border router.

The simplest answer is that this is a generational issue. The Homey Bridge does not support Matter/Thread and is equipped with a Zigbee 2.0 chip. The Homey Bridge arrived on the scene when Matter and Thread were still being developed and perhaps future generations will be able to act as border routers on their own.

For now this is all I can do for you, which is why I’m closing your ticket.

but… after this update, everything works.
So now, I hope the same.

[allexiel]

@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:

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:

netstat -rn -f inet6 | egrep 'fd29|default'

In my case, macOS had a route like:

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:

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:

sudo docker run --rm -it --network container:<HOMEY_CONTAINER_ID> nicolaka/netshoot sh
ip -6 route

Then test connectivity to a Thread device:

nc -6 -vz -w 3 <fd29:...device-ipv6> 5540

Before the fix, it always timed out:

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:

sudo sysctl net.ipv6.conf.eth0.accept_ra

Set to 2 (accept RAs even if forwarding is enabled):

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.:

fd29:.../64 -> fe80:...

Then on Synology I added the same route (without the %iface part):

sudo ip -6 route add fd29:.../64 via fe80:... dev eth0 metric 50

Confirm it exists:

ip -6 route | grep fd29

3) Re-test Matter reachability

Inside netshoot / Homey namespace:

nc -6 -vz -w 3 <fd29:...device-ipv6> 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:

/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 ↩︎

[philthynz]

I haven’t had these issues with SHS v13.0.0 in kubernetes. I installed it using this guide Homey Self Hosted Server in Kubernetes · GitHub.

It has an IP on my network using macvlan.

In the homey app. Open devices, add new device, matter, scan QR code.