# Issue with Matter on self hosted Homey

**URL:** <https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203>\
**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:** 12\
**Page:** 5

<div class="post-metadata">

**Author:** ![Rudy\_De\_Vylder](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/rudy_de_vylder/32/114133_2.png) [@Rudy\_De\_Vylder](https://community.homey.app/u/Rudy_De_Vylder)\
**Post date:** [January 24, 2026, 7:57am UTC](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203/81 "2026-01-24T07:57:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Bram\_H](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/bram_h/32/52477_2.png) [@Bram\_H](https://community.homey.app/u/Bram_H)\
**Post date:** [January 24, 2026, 4:05pm UTC](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203/82 "2026-01-24T16:05:10Z")

</div>

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.

---

<div class="post-metadata">

**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")

</div>

> [@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:<HOMEY_CONTAINER_ID> nicolaka/netshoot sh
> ip -6 route
> 
> ```
> 
> Then test connectivity to a Thread device:
> 
> ```auto
> nc -6 -vz -w 3 <fd29:...device-ipv6> 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 <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:
> 
> ```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

---

<div class="post-metadata">

**Author:** ![philthynz](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/philthynz/32/122218_2.png) [@philthynz](https://community.homey.app/u/philthynz)\
**Post date:** [March 15, 2026, 1:32am UTC](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203/84 "2026-03-15T01:32:40Z")

</div>

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](https://gist.github.com/philthynz/be7f7dee81c260f9585981a4c9980cb7).

It has an IP on my network using macvlan.

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

---

<div class="post-metadata">

**Author:** ![Grayman](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/grayman/32/165398_2.png) [@Grayman](https://community.homey.app/u/Grayman)\
**Post date:** [June 2, 2026, 4:51pm UTC](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203/85 "2026-06-02T16:51:43Z")

</div>

This is my problem and I believe your fix will work, BUTT I tried to start with your Step 1 Ensure RA is enabled and got command not found.

Step 2 completely fries my brain and I don’t have a Mac to do this on either. So I guess I can’t find the next “hop”

---

<div class="post-metadata">

**Author:** ![Mantlet](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/mantlet/32/121247_2.png) [@Mantlet](https://community.homey.app/u/Mantlet)\
**Post date:** [June 4, 2026, 8:53am UTC](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203/86 "2026-06-04T08:53:11Z")

</div>

This guide also helped me to setup matter over thread. Since I don’t have a Mac either, I’ve looked up the WIndows Powershell equivalent of the netstat command. I have found the IPv6 routing to my Google TV 4K, that acts as my Thread Border Router with this command:

```auto
Get-NetRoute -AddressFamily IPv6 | Where-Object { $_.DestinationPrefix -like "fd*" }

```

The result contains something like this:

```auto
DestinationPrefix : fd__:::1::/64
NextHop : fe:::::
ifIndex : 12

```

You can then paste this information in the script that @majorzoltanpepe proposed as boot-script:

```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

```

So, if the rest of your network and TBR are setup correctly and you skip all trouble-shooting steps this is all you need: Run powershell script, paste results in boot-script and reboot your Synology NAS.

@majorzoltanpepe Thanks very much for the extensive guide!

---

<div class="post-metadata">

**Author:** ![Bjorn\_Boxstart](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/bjorn_boxstart/32/73758_2.png) [@Bjorn\_Boxstart](https://community.homey.app/u/Bjorn_Boxstart)\
**Post date:** [August 19, 2026, 8:26pm UTC](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203/87 "2026-08-19T20:26:56Z")

</div>

For me adding an additional route also fixed it. First try it failed because I used the wrong address. I have multiple appliances that act as a border router in my network (Nets hub gen 2, Ikea Dirigera, Google TV streamer, Homey Pro 2023).

Some info that Copilot told me to keep (in Dutch)

Symptoom:

- Matter-over-Thread pairing op SHS faalt

- Werkt wel op Homey Pro

- Werkt wel via HomeyLink

Belangrijkste aanwijzing:

- avahi-browse ziet Matter devices op fd07:a96:830:1::/64

- ping6 gaf: “Network is unreachable”

Oorzaak:

- Synology kende geen route naar het Thread prefix

Oplossing:

- IPv6 route toegevoegd naar fd07:a96:830:1::/64

via het juiste fe80:: adres van Homey Pro

Resultaat:

- Matter-over-Thread pairing werkt op SHS

---

<div class="post-metadata">

**Author:** ![Siepje](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/siepje/32/9441_2.png) [@Siepje](https://community.homey.app/u/Siepje)\
**Post date:** [August 20, 2026, 6:47am UTC](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203/88 "2026-08-20T06:47:11Z")

</div>

**Matter-over-Thread timeout on Homey SHS / Synology with Google Nest Hub**

I’m trying to pair an IKEA TIMMERFLOTE (Matter-over-Thread) with Homey Self-Hosted Server, but pairing consistently ends with:

Could not pair node (Matter code: TIMEOUT (0x0032))

My setup:

- Homey SHS 13.3.1
- Homey app 10.0.0.2028
- Synology DS725+ / Container Manager
- network\_mode: host
- Homey Bridge
- TP-Link Archer AXE75
- KPN native IPv6
- Google Nest Hub 2nd generation as Thread Border Router
- The TIMMERFLOTE is already working on the Google/Nest Thread network

I have done quite a bit of troubleshooting and have ruled out several potential issues.

**IPv6 is working inside the Homey container.** The container sees Global IPv6, ULA and link-local addresses on eth0:

2a02:a457:5d76:ff00:…/64  
fd34:27c3:6391:5a72:…/64  
fe80::…/64

Homey Matter also starts with:

net.ipv6.conf.eth0.disable\_ipv6=0  
net.ipv6.conf.eth0.accept\_ra=2

The Matter service is listening on IPv6:

udp6 0 0 :::5540 :::\* 18488/com.athom.mat

Using tcpdump on eth0, I can see IPv6 mDNS traffic to ff02::fb, including actual Matter traffic:

\_matter.\_tcp.local

Homey also already has an existing Matter connection over IPv6:

Connection update: null → fe80::5e6a:41d8:f31d:e186%eth0

When trying to add the TIMMERFLOTE, the Homey log shows:

[Pairing] Start  
Got status update: SEARCHING  
Starting pairing with payload  
Pairing to device…  
Finished with error: Could not pair node (Matter code: TIMEOUT (0x0032))

What caught my attention is the IPv6 routing table on the Synology:

2a02:a457:5d76:ff00::/64 dev eth0  
fd34:27c3:6391:5a72::/64 dev eth0  
fe80::/64 dev eth0  
default via fe80::42ae:30ff:feb6:10d8 dev eth0

There is no separate /64 route to the Thread mesh.

I’ve read in this topic that other Synology/SHS users with similar Matter-over-Thread timeouts managed to solve the issue by manually adding a route to the Thread prefix via the link-local IPv6 address of their Thread Border Router.

**My question:** has anyone managed to get this working specifically with a **Google Nest Hub 2nd generation** as the Thread Border Router?

If so, how can I determine the correct **Thread /64 prefix** and the **link-local IPv6 next-hop address** of the Google Nest Hub, so I can temporarily add the route to the Synology and test it?

I’d rather not add IPv6 routes blindly without first confirming the correct Thread prefix and next hop for the Google Thread network.

---

<div class="post-metadata">

**Author:** ![Bjorn\_Boxstart](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/bjorn_boxstart/32/73758_2.png) [@Bjorn\_Boxstart](https://community.homey.app/u/Bjorn_Boxstart)\
**Post date:** [August 20, 2026, 12:30pm UTC](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203/89 "2026-08-20T12:30:22Z")

</div>

Hi, I kind of sorted it out for my (Synology DS 918+ based) based Homey SHS on Docker issue. My NAS is using latest version of the OS, but that’s using version 4.4.x of the Linux kernel. This version of the kernal has an issue in translating IPV6 RA’s (Route Advertisements) into entries in the routing table.

I fixed it first by adding a static route, but that’s not a really stable solution. Today I improved the solution by working with Copilot to create a script that listens for RA’s and creates route entries in the routing table based on the RA’s. It has been running for a few hours now and seems to do the job.

There can be more than one border router that is sending RA’s. That’s not a problem, because the route is registered for a certain prefix. My expectation is that it also will cover your scenario.

The following command (run it from an ssh shell) is important. It will listen for RA’s and show the details. It might provide you with the info you’re looking for.

`sudo tcpdump -i ovs_eth0 -n -vv 'icmp6 and ip6[40] == 134'`

Your network connector might have a different name though.

---

<div class="post-metadata">

**Author:** ![Siepje](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/siepje/32/9441_2.png) [@Siepje](https://community.homey.app/u/Siepje)\
**Post date:** [August 22, 2026, 6:32am UTC](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203/90 "2026-08-22T06:32:13Z")

</div>

Thank you Bjorn, I will try this

---

<div class="post-metadata">

**Author:** ![Mantlet](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/mantlet/32/121247_2.png) [@Mantlet](https://community.homey.app/u/Mantlet)\
**Post date:** [August 29, 2026, 4:48pm UTC](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203/91 "2026-08-29T16:48:52Z")

</div>

It appears Google TV regularly changes the ULA prefix, so the `fd...` route in your routing table needs to be updated accordingly.

I’ve created a script that runs as a scheduled task on my Synology. It actively sends out a Router Solicitation (RS), which triggers all routers on the network to respond with a Router Advertisement (RA). The script filters the RA that contains the Thread network prefix and compares it with the currently installed route. Only if the prefix has changed, it updates the routing table. This way the Synology always has a valid route to the Thread mesh without any manual intervention.

```bash
#!/bin/bash
IFACE="eth0"

# Stuur Router Solicitation en vang de RA's op
RDISC_OUTPUT=$(/sbin/rdisc6 "$IFACE" 2>&1)

# Extraheer Thread-prefix (ULA, begint met fd)
NEW_PREFIX=$(echo "$RDISC_OUTPUT" | grep -Eo 'fd[0-9a-f:]+::/[0-9]+' | head -1)

# Extraheer TBR link-local adres (from-regel na de Thread-prefix)
TBR_LINK_LOCAL=$(echo "$RDISC_OUTPUT" | \
  grep -A4 "$NEW_PREFIX" | \
  grep "from" | \
  grep -Eo 'fe80::[0-9a-f:]+' | head -1)

# TBR niet gevonden — foutmelding en stop
if [-z "$NEW_PREFIX"] || [-z "$TBR_LINK_LOCAL"]; then
  echo "=== FOUT: Thread-prefix of TBR niet gevonden $(date) ==="
  echo "$RDISC_OUTPUT"
  exit 1
fi

# Haal huidige geïnstalleerde Thread-route op
CURRENT_PREFIX=$(ip -6 route show dev "$IFACE" | grep "^fd" | awk '{print $1}' | head -1)

# Geen wijziging — stilletjes stoppen, geen output, geen mail
if ["$NEW_PREFIX" = "$CURRENT_PREFIX"]; then
  exit 0
fi

# Prefix is gewijzigd of ontbreekt — bijwerken en rapporteren
echo "=== Thread route bijgewerkt $(date) ==="
echo "Oude prefix : ${CURRENT_PREFIX:-'(geen)'}"
echo "Nieuwe prefix: $NEW_PREFIX"
echo "TBR : $TBR_LINK_LOCAL"

# Verwijder oude Thread-routes
ip -6 route show dev "$IFACE" | grep "^fd" | awk '{print $1}' | \
  while read -r OLD; do
    ip -6 route del "$OLD" dev "$IFACE" 2>/dev/null
  done

# Voeg nieuwe route toe
ip -6 route add "$NEW_PREFIX" via "$TBR_LINK_LOCAL" \
  dev "$IFACE" metric 50 2>/dev/null || true

# Zet RA-acceptatie goed
/sbin/sysctl -w net.ipv6.conf.all.accept_ra=2 > /dev/null
/sbin/sysctl -w net.ipv6.conf.default.accept_ra=2 > /dev/null
/sbin/sysctl -w net.ipv6.conf.eth0.accept_ra=2 > /dev/null

```

---

<div class="post-metadata">

**Author:** ![Siepje](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/siepje/32/9441_2.png) [@Siepje](https://community.homey.app/u/Siepje)\
**Post date:** [September 22, 2026, 5:14am UTC](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203/92 "2026-09-22T05:14:49Z")

</div>

Thank you, with the help of Chat gpt, I converted this script to my situation. And now it works!

[Previous page](https://community.homey.app/t/issue-with-matter-on-self-hosted-homey/147203.md?page=4)