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