WakeOnLan Cluster
Cluster ID: 0x0503 |
Endpoint: Media endpoint (TV, set-top box, game console, etc.) |
Role: Server (Read-only, no commands)
WakeOnLan is a very simple yet practical Cluster in Matter media devices — it contains no commands, only exposes the device's MAC address and IPv6 link-local address, allowing external systems to remotely wake devices in standby or sleep mode by sending WoL Magic Packets.
This Cluster is typically used in conjunction with LowPower Cluster (0x0508): LowPower handles putting the device into low-power standby (Sleep command), while WakeOnLan provides the network address information needed for waking. One manages "sleep", the other manages "wake".
After the device enters deep sleep, Matter's IP communication stack may have shut down and cannot receive normal Matter messages. However, the NIC hardware still listens for Ethernet frames matching a specific pattern (Magic Packet), and upon receipt, triggers a hardware interrupt to wake the entire system. This is why a dedicated Cluster is needed to expose the MAC address — the wake operation occurs below the Matter protocol layer.
Attributes
The WakeOnLan Cluster has only 2 attributes, all read-only, with no commands or events. Both attributes are optional, but at least one must be supported; otherwise this Cluster serves no practical purpose.
| ID | Name | Type | Required | Description |
|---|---|---|---|---|
0x0000 |
MACAddress | string | Optional | Device's 48-bit MAC address |
0x0001 |
LinkLocalAddress | octstr (bytes) | Optional | Device's IPv6 link-local address |
MACAddress — MAC Address (0x0000)
The Ethernet MAC address used by the device to receive WoL Magic Packets.
Format is a standard 48-bit MAC, represented as a colon-separated hexadecimal string, e.g., AA:BB:CC:DD:EE:FF.
This address is typically the device's wired NIC address. For WiFi-only devices, it can be the wireless NIC's MAC, but WoL reliability over WiFi is much lower than wired connections (requires router support for WiFi WoL forwarding).
The Matter specification requires MACAddress to be stored as a uppercase hex + colon-separated string format,
e.g., "AA:BB:CC:DD:EE:FF". In practice, case-insensitive handling is recommended.
Max length is 32 bytes (including separators, covering both 48-bit and 64-bit EUI formats).
LinkLocalAddress — Link-Local Address (0x0001)
The device's IPv6 link-local address, stored as a byte array, fixed at 16 bytes.
Link-local addresses start with fe80:: and are valid only within the same network link (same subnet/VLAN).
The purpose of this address is to let the waking party know which link the device is on, so the Magic Packet can be sent to the correct network segment. For cross-subnet wake scenarios, directed broadcast or subnet forwarding is also needed.
When the network has multiple subnets or VLANs, MAC address alone is not enough — different broadcast domains mean the Magic Packet cannot reach the target device. LinkLocalAddress helps the waking party determine which link the target device is on, selecting the correct network interface to send the wake packet. In a simple single-subnet environment (common for home networks), MACAddress alone is usually sufficient.
WoL Wake Mechanism
Wake-on-LAN (WoL) is a decades-old network standard that allows remotely waking devices in standby, sleep, or powered-off states by sending a special Ethernet frame (Magic Packet). Matter's WakeOnLan Cluster does not send this packet; it simply tells you "which address to send to".
Magic Packet Structure
The Magic Packet format is very simple: a 6-byte 0xFF sync header,
followed by the target MAC address repeated 16 times, totaling 102 bytes.
It can be encapsulated in a UDP packet (commonly port 7 or 9) or sent directly as an Ethernet frame.
// WoL Magic Packet structure (102 bytes total)
FF FF FF FF FF FF // Sync header: 6 bytes of 0xFF
AA BB CC DD EE FF // Target MAC address, repeated 16 times
AA BB CC DD EE FF
AA BB CC DD EE FF
AA BB CC DD EE FF
AA BB CC DD EE FF
AA BB CC DD EE FF
AA BB CC DD EE FF
AA BB CC DD EE FF
AA BB CC DD EE FF
AA BB CC DD EE FF
AA BB CC DD EE FF
AA BB CC DD EE FF
AA BB CC DD EE FF
AA BB CC DD EE FF
AA BB CC DD EE FF
AA BB CC DD EE FF
Wake-up Process
- Read
MACAddressfrom the device's WakeOnLan Cluster (cache in advance while device is online) - Device enters standby/sleep (may be triggered by LowPower Cluster's Sleep command)
- When wake-up is needed, construct a Magic Packet containing the target MAC
- Send via UDP broadcast (or directed broadcast) to the target network segment
- Device NIC hardware detects the matching Magic Packet, triggers interrupt to wake the system
- After device boots, it rejoins the Matter Fabric and resumes normal communication
Whether WoL works depends on hardware and firmware support: the device NIC must remain powered and listening for network frames during sleep, and WoL must be enabled in the BIOS/firmware. Not all devices support this — especially WiFi-only devices, where WoL support and reliability over wireless are much lower than wired Ethernet.
Relationship with LowPower Cluster
In Matter media devices, WakeOnLan and LowPower (0x0508) are a complementary pair of Clusters:
| Cluster | Responsibility | Direction |
|---|---|---|
| LowPower(0x0508) | Put the device into standby/sleep (Sleep command) | Controller → Device: "Go to sleep" |
| WakeOnLan(0x0503) | Provide network address needed to wake the device | Controller reads address and sends Magic Packet itself: "Wake up" |
Typical media devices (such as TVs, set-top boxes) implement both Clusters simultaneously. When the user says "Turn off the TV", LowPower's Sleep is invoked; when they say "Turn on the TV", a Magic Packet is sent using WakeOnLan's address.
Example Data
Read a smart TV's WakeOnLan Cluster attributes:
{
// --- Wake-on-LAN Addresses ---
"0x0000": "AA:BB:CC:DD:EE:FF", // MACAddress = device's wired NIC MAC address
"0x0001": "fe80::a8bb:ccff:fedd:eeff" // LinkLocalAddress = IPv6 link-local address
}
WakeOnLan attribute values typically do not change throughout the device's lifecycle (MAC address and Link-Local address are both fixed). It is recommended to read them once when the device first joins the network and cache locally, with no need for frequent polling. This way, even if the device is already asleep and cannot respond to Matter requests, you still have the address to send a Magic Packet.
Common Scenarios
Scenario 1: Voice assistant wakes the TV
The user tells the smart speaker "Turn on the living room TV". The TV is currently in standby mode, with Matter communication disconnected.
- The smart speaker (Hub) looks up the living room TV's WakeOnLan info from local cache (cached when it joined the network)
- Retrieve
MACAddress = "AA:BB:CC:DD:EE:FF" - Construct Magic Packet (6 bytes 0xFF + MAC repeated 16 times = 102 bytes)
- Broadcast to the local network via UDP port 9
- TV NIC detects the Magic Packet and wakes the system
- After the TV boots, it rejoins the Matter Fabric, and the Hub detects the device coming online
- The Hub can optionally send OnOff Cluster's On command to ensure the TV is fully powered on
Key point: Wake address must be cached in advance. Attributes cannot be read via Matter after the device sleeps; without a cache, you can only wait for the user to manually power on.
Scenario 2: Automation integration (Home Mode)
The user has set up a "Home Mode" automation: when the phone connects to the home WiFi, automatically wake the TV and switch to the frequently watched input source.
- Hub detects the user's phone connecting to home WiFi (trigger condition)
- Automation engine starts the "Home Mode" action sequence
- Step 1: Send Magic Packet with cached MAC address to wake the TV
- Step 2: Wait for the TV to come back online (poll device status or listen for mDNS broadcasts)
- Step 3: Switch to HDMI 1 (set-top box) via MediaInput Cluster (0x0507)
- Simultaneously: Adjust living room light brightness to 60% via LevelControl
Note: It takes time from wake-up to full device online status (typically a few seconds to tens of seconds). The automation engine needs to wait for the device to be ready after sending the Magic Packet before executing subsequent Matter commands. Sending commands immediately in succession will fail because the device's Matter stack has not yet started.