Based on the historical context and the data you just provided, no, it was not necessary to execute that systemd service or manual route addition first for the specific issue we just solved.
If your system is already working perfectly and you can seamlessly interact with your Matter-over-Thread devices right now, no, you do not need to add the routes manually to Netplan.
Here is why you don't need to add them—and why your setup is working smoothly despite what that guide predicted:
NetworkManager Handles it Automatically: Unlike the old dhcpcd networking layer mentioned in your document (which strictly ignored modern Thread router advertisements), NetworkManager is much smarter. When your Aqara M100 border router broadcasts the Thread network route to your Wi-Fi space, NetworkManager catches the advertisement and installs the route into your routing table automatically on the fly.
You are on a Single, Flat Subnet: Because your Pi Zero 2W, your Aqara M100, and your Tado kit are all sharing the exact same flat Wi-Fi network layer (PLUSNET-37AW2T), your network doesn't have internal firewalls or VLAN boundaries. The automatic neighbor discovery built into modern Debian Trixie is doing exactly what it's supposed to do.
When would you actually need to add those routes?
You would only need to hardcode a static route block into your Netplan YAML file if:
The route randomly drops: If you notice that after a few days of runtime, your Node-RED node randomly loses contact with the Ikea button (giving an ENETUNREACH error) until you reboot the Pi.
You isolate your smart home traffic: If you eventually decide to place your Matter/Thread hubs onto a separate, isolated IoT VLAN or a different subnet split away from your Pi's main connection.
Use this guide if the Node-RED Matter Controller network interface dropdown is blank, or if Matter-over-Thread devices show an ENETUNREACH error after an OS update or system migration.
Run this command to check if the Raspberry Pi's Wi-Fi adapter has bound to a valid local IPv6 address:
ip addr show wlan0
What to look for: A line starting with inet6 fe80::... scope link.
If this line is missing, the Linux kernel has disabled IPv6 on the wireless card, preventing Matter discovery from initializing.
Modern Raspberry Pi OS releases use Netplan to manage networking profiles. If IPv6 is missing, verify that dhcp6: true is explicitly enabled.
File Location: /etc/netplan/ (usually named 90-NM-xxxx.yaml or similar).
Let's look inside that folder to find your configuration file:
ls /etc/netplan/
You will likely see a file named something like 90-NM-xxxxxxxx.yaml or 01-netcfg.yaml. Open whichever .yaml file is in that folder using nano:
sudo nano /etc/netplan/*.yaml
network:
version: 2
wifis:
wlan0:
renderer: NetworkManager
match: {}
dhcp4: true
dhcp6: true
access-points:
"YOUR_SSID_NAME":
auth:
key-management: "psk"
password: "REDACTED_WIFI_HEX_KEY"
networkmanager:
uuid: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
name: "netplan-wlan0-YOUR_SSID_NAME"
passthrough:
proxy._: ""
networkmanager:
uuid: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
name: "netplan-wlan0-YOUR_SSID_NAME"
If you modify this file, never use the Tab key (only use spaces for indentation). Save the file and run the following to apply it:
sudo netplan apply
Modern network managers dynamically install the correct Thread routes broadcast by your Thread Border Router (e.g., Aqara M100). Check your active routing table to ensure it is parsing network data correctly:
ip -6 route show
What to look for: A line mapping your Thread mesh prefix via your Border Router's link-local address, looking similar to this:
fd9e:8866:ba70:1::/64 via fe80::56ef:44ff:fe8a:42db dev wlan0 proto ra ...
If network changes were made at the OS layer, the background Node-RED service must be restarted to re-scan the live network sockets:
sudo systemctl restart nodered
If the wlan0 interface is physically present but still won't appear inside the Matter configuration node:
Click the Network interface + button to force-create a brand new Matter Controller config node.
Select wlan0 from that menu and click Add.
Give the node a placeholder name, click Done, and hit the main red Deploy button in the top right corner of Node-RED to initialize the cryptographic fabric.
This section documents exactly how your Aqara M100 hub, Alexa, and Node-RED share access to your Thread accessories like the Ikea SOMRIG/MYGGBETT button.
Matter introduces a feature called Multi-Admin Commissioning. This allows a single physical accessory—like the Ikea button—to connect securely to multiple smart home controllers (Alexa, Aqara M100, and Node-RED) at the exact same time.
┌──► Alexa App (Ecosystem 1)
│
[Ikea Button] ───────┼──► Aqara M100 (Thread Border Router)
(Thread Device) │
└──► Node-RED Controller (Ecosystem 2 via wlan0)
Unlike older smart home protocols where a device can only pair with one hub, Matter devices can be shared seamlessly across platforms without removing them from your existing smart home setup.
Since your Ikea button is already paired with your Aqara M100 and Alexa, you must generate a temporary sharing token from one of those ecosystems to bring it into Node-RED.
Open the app where the device is currently paired (e.g., the Alexa App).
Navigate to your Ikea Button device settings.
Look for an option named "Share with other services", "Other Assistants", or "Expose via Matter".
The app will generate an 11-digit numeric setup code (and a temporary QR code).
Note: This code is highly time-sensitive and usually expires within 3 to 15 minutes.
Keep your Node-RED browser window open alongside the app.
Ensure your Matter Controller configuration node is deployed and listening on your validated wlan0 interface.
Pass the 11-digit setup code directly into the input of your Matter node as a text string payload:
msg.payload = "12345678901"
Trigger the injection node.
Your Raspberry Pi Zero 2W will look up the Thread route via your Netplan configuration, securely reach out through the Aqara M100's Thread boundary, perform a cryptographic handshake with the Ikea button, and add it as a native device inside your Node-RED flow.
If the device fails to pair with Node-RED and throws an error:
Check the Expiry: Ensure you injected the code into Node-RED before the timer ran out in the smartphone app. If it timed out, simply generate a fresh code and try again.
Verify Routing: Run ip -6 route show to confirm that the Thread mesh prefix route (fd9e:...) is actively present in your Pi's routing table. Without it, the Pi cannot cross over the Wi-Fi network layer into the Thread mesh.
You can copy and paste this directly onto your site. If there are any specific payload layouts (like what data looks like when the Ikea button is single-pressed versus double-pressed) that you want to add to this guide, let me know!
This document explains how to connect a newly installed Raspberry Pi Zero 2W running Raspberry Pi OS (PiOS Trixie) to a Thread Border Router (TBR). It is based on real diagnostic data you provided and the exact steps that resolved connectivity issues between the Pi, Aqara M100, Tado X Starter Kit, and Node‑RED Matter Controller.
rdsc6 installation
bash
sudo apt update && sudo apt install ndisc6 -y
sudo rdisc6 wlan0
A Raspberry Pi running PiOS Trixie uses dhcpcd for IPv6 configuration. It does not automatically install IPv6 Route Information Options (RFC 4191) advertised by Thread Border Routers. When a TBR advertises a Thread subnet as a route rather than a prefix, the Pi hears the advertisement but does not install the route. This results in:
ENETUNREACH
when Node‑RED or Matter tries to reach devices inside that subnet.
To fix this, you must manually add the Thread route and make it persistent.
The following data was supplied and used to diagnose the network:
These are LAN‑side IPv6 addresses, not Thread addresses.
Aqara M100 Wi‑Fi:
ULA: fdc0:ccc3:4b06:47a0:56ef:44ff:fe8a:42db
LLA: fe80::56ef:44ff:fe8a:42db
Tado Starter Kit Wi‑Fi:
ULA: fdc0:ccc3:4b06:47a0:9aa3:16ff:fe21:eeac
LLA: fe80::9aa3:16ff:fe21:eeac
These addresses show both devices are on the same LAN prefix (fdc0:ccc3:4b06:47a0::/64). They do not indicate Thread network membership.
The Pi showed:
inet6 fd32:5f7b:fcb8:8f2:e65f:1ff:fe39:f338/64
This prefix:
fd32:5f7b:fcb8:8f2::/64
is Aqara’s Thread ULA prefix.
This confirms:
The Pi successfully joined Aqara’s Thread network.
Aqara is the active Thread Border Router.
Running:
sudo rdisc6 wlan0
produced:
From Tado:
Route: fd9a:63a3:c8fb:1::/64
Router lifetime: 0
From Aqara:
Prefix: fd32:5f7b:fcb8:8f2::/64
Route: fd9e:8866:ba70:1::/64
Lifetime: 1800
This shows Aqara is advertising:
A Thread prefix (installed automatically)
A Thread route (ignored by PiOS)
Running:
ip -6 route show
always showed:
fd32:5f7b:fcb8:8f2::/64 dev wlan0
fe80::/64 dev wlan0
The Pi never installed the Aqara route:
fd9e:8866:ba70:1::/64 via fe80::56ef:44ff:fe8a:42db
This is the root cause of ENETUNREACH.
PiOS Trixie uses dhcpcd, which:
Installs IPv6 prefixes
Installs default routes when router lifetime > 0
Ignores Route Information Options (RFC 4191)
Aqara advertises its Thread subnet as a route, not a prefix.
Therefore, the Pi hears the route but does not install it.
Node‑RED tries to reach a device inside:
fd9e:8866:ba70:1::/64
Without a route, the kernel returns ENETUNREACH.
You must manually add the route advertised by Aqara.
Run:
sudo ip -6 route add fd9e:8866:ba70:1::/64 via fe80::56ef:44ff:fe8a:42db dev wlan0
This instantly restores connectivity.
Create a systemd service:
sudo nano /etc/systemd/system/thread-route.service
Paste into nano:
[Unit]
Description=Add Aqara Thread Route
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/sbin/ip -6 route add fd9e:8866:ba70:1::/64 via fe80::56ef:44ff:fe8a:42db dev wlan0
[Install]
WantedBy=multi-user.target
After pasting that block into nano, the next step is simply to save and close the editor. Enable the service:
sudo systemctl enable thread-route.service
...after enabling the service should see
Created symlink /etc/systemd/system/multi-user.target.wants/thread-route.service → /etc/systemd/system/thread-route.service.
Reboot:
sudo reboot
Verify:
ip -6 route show
You should now see the Aqara route installed:
fd9e:8866:ba70:1::/64 via fe80::56ef:44ff:fe8a:42db dev wlan0
Once the Pi has the route:
Node‑RED can reach Thread devices.
Matter commissioning works.
Attribute reads and subscriptions work.
ENETUNREACH disappears.
This is required for any fresh PiOS installation connecting to Aqara’s Thread network.
To connect a fresh Raspberry Pi OS installation to a Thread Border Router:
Confirm the Pi receives the Thread prefix via rdisc6.
Identify the Thread route advertised by the TBR.
Add the route manually using ip -6 route add.
Make the route persistent with a systemd service.
Verify the route after reboot.
This ensures the Pi can reach all devices inside the Thread mesh and prevents ENETUNREACH errors in Node‑RED Matter.
sudo rdisc6 wlan0
ip -6 addr show
ip -6 route show
sudo ip -6 route add <subnet> via <link-local> dev wlan0