Wake on LAN with Eddy

Wake on LAN, or WOL, sends a specially formed wake message to a supported network interface. It can help wake equipment that no longer accepts ordinary control commands in its current power state. The target still needs compatible hardware, the correct settings and enough standby power to listen.

What the magic packet does

The wake message identifies the target interface using its MAC address. Receiving it can trigger a wake when the device supports that behavior. The packet is not an ON or OFF toggle, and it does not provide playback, volume or input controls.

Sending a packet successfully does not prove the device woke. Watch the target, then check that its normal control service becomes available before sending the next activity step.

Find the right MAC address

A MAC address identifies a network interface. It is commonly written as six pairs of hexadecimal characters, such as 00:14:22:01:23:45. That is an example format, not an address to copy into your setup.

Use the address of the interface that will receive the wake message. Ethernet and Wi-Fi interfaces on the same device can have different addresses. Addresses can also be locally assigned or randomized; use the current address of the intended interface.

Find the interface address in the equipment’s network settings, the operating system or your router’s device information. Match it with the connection you intend to use instead of selecting an unfamiliar entry by guesswork.

Check the supported power state

Wake support can differ between sleep, hibernation and shutdown. BIOS or firmware settings, operating-system policy, adapter drivers and standby power can all affect it. Enabling one checkbox does not establish that every power state is supported.

Microsoft documents different WOL behavior for Windows sleep, hibernate and hybrid shutdown. Follow the instructions for the OS version and hardware you actually have rather than assuming the same result from every shutdown method. Microsoft’s WOL behavior reference explains that distinction.

Test it through the local Eddy host

1. Keep the Eddy Bridge or supported agent host awake and connected to the target’s local network.
2. Enable the target’s supported WOL settings according to its manufacturer’s instructions.
3. Record the correct interface MAC address.
4. Configure the WOL action with that address in the Eddy version you are using.
5. Put the target in the intended supported low-power state.
6. Send one wake action and check the physical result.
7. Wait for the device’s normal control service to become ready, then test one ordinary command.

The original Bridge setup guide covers the legacy Pi image. The V2 project implements WOL through the new cross-platform agent, but remains a development preview until release availability and your hardware are confirmed. Screens and configuration methods differ between these generations.

When the device stays asleep

First test from the same local network. Confirm the MAC address, the actual power state and the target interface’s standby power. Then review the relevant firmware, driver and operating-system settings. If it wakes from sleep but not shutdown, investigate that power-state difference before changing the Eddy activity.

Guest networks, separate VLANs and router policy can prevent the wake message from reaching its target. WOL is commonly used within a local network; routing it elsewhere requires deliberate network support. Keep remote wake requests behind a supported local agent or an appropriately managed private network rather than exposing a wake port directly to the internet.

For remote Eddy control, prefer the supported outbound agent route: Eddy reaches the awake local agent, and that host sends the wake message inside the home. The sleeping target cannot be the only host expected to send its own wake packet.

Add wake to an activity carefully

Once the wake action works independently, measure how long the target takes to accept its next command. Add that useful delay or a supported readiness check before selecting an input or starting playback. Keep the original remote nearby while testing and avoid repeatedly sending an entire activity when its final state is uncertain.