Since you are running Debian Trixie (Testing) on your Raspberry Pi Zero 2W, it utilizes NetworkManager by default. However, nmcli connection targets the profile name (usually your Wi-Fi SSID) rather than the physical interface name (wlan0). This explains why it returned the "unknown connection" error.
Let's locate the exact name of your active connection profile, enable IPv6 on it, and fix the underlying routing issue.
Run this command to see the exact name of your active Wi-Fi profile:
nmcli connection show --active
Look under the NAME column. It will likely be your Wi-Fi network's SSID (e.g., MyHomeWiFi or preconfigured).
Once you have the name from Step 1, run the following commands, replacing YOUR_SSID_NAME with that exact profile name (keep the quotation marks):
sudo nmcli connection modify "YOUR_SSID_NAME" ipv6.method auto
sudo nmcli connection up "YOUR_SSID_NAME"
(Note: If you want to strictly restrict it to local-only traffic, you can use link-local instead of auto, but auto is generally preferred on Debian Trixie to ensure all multicast routing tables are automatically built).
Now, let's check if the physical network layer successfully generated an IPv6 link-local address. Run:
ip addr show wlan0
Look at the text block that prints out. You want to see a line that looks like this:
inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link
If you see an inet6 fe80::... line, your operating system is officially ready for Matter. At that point, simply restart your Node-RED service (sudo systemctl restart nodered), and the network interface dropdown will populate!
If the inet6 line is still missing after updating the NetworkManager profile, paste the output of ip addr show wlan0 here so we can see the exact hardware state of the card.
The IPv6 address fe80::e65f:1ff:fe39:f338/64 belongs to an Aqara device (such as the Aqara M100 series or an Aqara Hub), not the Tado X.
How to Find Out (The Methodology)
When dealing with a link-local IPv6 address (which always starts with fe80::), the address is often automatically generated from the device’s physical hardware MAC address using a standard process called Modified EUI-64. You can reverse-engineer this to extract the MAC address and identify the manufacturer. [1, 2]
Step 1: Reconstruct the MAC Address
Modified EUI-64 takes a 48-bit MAC address, splits it in half, and inserts ff:fe in the middle. It also flips the 7th bit of the first byte. [1]
Take the last 64 bits of your IPv6 address: e65f:01ff:fe39:f338 (expanding the shortened 1ff to 01ff).
Remove the middle ff:fe filler, leaving you with: e65f01 39f338.
Look at the first byte: e6 in hexadecimal is 11100110 in binary.
Flip the 7th bit back (change it from 1 to 0): 11100100 in binary, which is e4 in hex.
Combine them to get the actual MAC address: E4:5F:01:39:F3:38.
Step 2: Use a MAC Lookup Tool
The first 6 characters of a MAC address (E4:5F:01) are the Organizationally Unique Identifier (OUI), which tells you who manufactured the network chip. [1, 2]
If you input E4:5F:01 into an IEEE database tool like MAC Address Lookup or MACAddressLookup.io, it returns the registered vendor: Lumi United Technology Co., Ltd. [1, 2]
Lumi is the parent and manufacturing company behind Aqara smart home hardware.
By comparison, Tado GmbH devices use completely different MAC prefixes (such as 00:1B:C5 or EC:E5:12). [1]
Alternative Ways to Double-Check
If you want to verify this on your own network without doing math, you can use these methods:
Check your Router's Client List: Log into your home router's admin panel. Look under the active devices or DHCP table for the MAC address E4:5F:01:39:F3:38. The router will usually display a human-readable name next to it (like "Aqara-Hub"). [1]
Use a Network Scanner App: Download a free network discovery tool like Fing on your phone. It scans your local network and automatically matches IPv6/MAC addresses to real product names, distinguishing your Aqara gear from your Tado X starter kit.
1. For your Aqara Devices (Hub / Sensors)
Since your working window sensor and other accessories are bridged via your Aqara Hub:
Open the Aqara Home App on your phone.
Go to the settings page for the Aqara Hub (or the individual child device if it was paired via Matter directly).
Look for "Matter", "Share via Matter", or "Pairing Mode".
Tap it to generate a fresh 11-digit Setup Code (or QR code numeric string).
Paste that code into your Node-RED Commission Matter node, give it a clean name right away (like Blind Sensor Active), and inject it.
2. For your Tado Devices
Open the Tado App.
Go to Settings ➔ Smart Home Services ➔ Matter.
Generate a new pairing code or multi-admin code.
Input it into your Tado commissioning node in Node-RED and trigger it.
Why this extra step is worth it right now:
Matter relies on tight cryptographic handshakes. Because you are creating a brand-new connection fabric from scratch, generating fresh pairing codes ensures that no duplicate IDs or ghost network routes can ever return
.Your Node-RED backend will be pristine, your dropdown menus will feature only your cleanly named active devices, and your automation loops will run flawlessly.
How to Purge Only the Controller File
The Matter Bridge virtual devices save their files with prefix strings like bridge or device-. The Controller saves its paired fabric database under a unique prefix string starting with controller- or fabric-.
You can safely delete just the controller database via a targeted Linux command, which preserves all your virtual bridge settings and pairings for Alexa:
Step 1: Run the Targeted File Purge
Instead of nuking the whole directory, run this precise command via a Node-RED Exec Node or your Pi terminal:
bash
rm -f /home/pi/.matter/controller-* && rm -f /home/pi/.node-red/.matter/controller-*
Step 2: Restart Node-RED
Restart your Node-RED instance (sudo systemctl restart nodered or reboot the Pi).
Why this option is a great shortcut:
The Controller is completely wiped: Your listDevices array drops cleanly to [], permanently evicting the defunct 8263842698019378757 ID and fixing the TypeError.
The Bridge stays alive: Your Alexa connections remain perfectly intact. Because you didn't touch any files starting with bridge-, Alexa will still see and control your existing virtual devices without requiring you to re-pair or re-discover anything on the Amazon side.
The initial step to Force Link-Local IPv6 using NetworkManager failed
sudo nmcli connection modify "wlan0" ipv6.method link-local
Error: unknown connection 'wlan0'.pi@piZero2:~ $pi@piZero2:~ $
Run the command
nmcli connection show --active
The output shows that your network configuration is actually managed by Netplan, which passes its configurations down to NetworkManager (hence the profile prefix netplan-wlan0-).
Because it is generated by Netplan, changing configuration profiles directly via nmcli will often get overwritten or fail to apply permanently. The proper way to fix this on Debian Trixie when Netplan is active is to explicitly enable IPv6 in your Netplan configuration file.
Netplan stores its configuration files in /etc/netplan/. 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
Inside that file, look for your wlan0 interface section. It will probably look similar to this. You need to add link-local: [ ipv6 ] under it (or change dhcp6: true if your router assigns IPv6 addresses).
Modify it to look like this (making sure your indentation uses spaces, not tabs, as YAML is strict):
network:
version: 2
wifis:
wlan0:
dhcp4: true
dhcp6: true
access-points:
"PLUSNET-37AW2T":
auth:
password: "your_wifi_password"
(If dhcp6: true is already there, adding link-local: [ ipv6 ] forces the Linux kernel to assign the mandatory fe80:: address that Matter requires , but shouldn't be required in Trixie).
Explicitly adding link-local: [ ipv6 ] to your network configuration YAML file is generally unnecessary because IPv6 link-local addresses (fe80::/10) are automatically generated by the Linux kernel for every network interface as soon as IPv6 is enabled. [1]
Because Raspberry Pi OS (Trixie) has IPv6 enabled by default, the interface automatically assigns itself a link-local address. Since Matter and Thread communication rely heavily on these link-local scoped addresses to discover and talk to nearby devices (like your Aqara U100/A100 lock) on the same local network segment, the setup will work flawlessly without you having to define it manually in your YAML..
Previously recommended including adding accept-ra: true to the YAML, that also appears to be unnecessary. Omitting accept-ra: true works because Router Advertisement (RA) acceptance is already enabled by default for standard physical network interfaces on modern Linux network stacks. [1]
Whether your network configuration is managed by systemd-networkd (the underlying engine for Debian/Trixie server environments) or standard kernel configurations, the system behaves as if accept-ra is already turned
Save and exit (Ctrl+O, Enter, Ctrl+X).
Tell Netplan to validate and apply your updated configuration:
sudo netplan apply
Now test if wlan0 has bound its IPv6 address by checking the status:
ip addr show wlan0
If you see a line starting with inet6 fe80::... scope link, you are good to go!
Finish up by restarting Node-RED to force its discovery library to scan your newly enabled IPv6 interface:
sudo systemctl restart nodered
Give those steps a try. If netplan apply gives you any parsing errors, paste the contents of your .yaml file here and we'll fix the formatting together.