Xlights cannot auto-discover WLED 16.0.0 (Art-Net "ArtPoll reply" not sent)

[happysmartlight]

What happened?

I used the same configuration, however version 15.x.x is quickly discovered by xLights using the Discover command, while in version 16.0.0, xLights cannot find it.

To Reproduce Bug

see above

Expected Behavior

see above

Install Method

Binary from WLED.me

What version of WLED?

WLED 16.0.0

Which microcontroller/board are you seeing the problem on?

ESP32-S3

Relevant log/trace output

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[softhack007]

@coderabbitai how does auto-discovery work in xLights?

[coderabbitai]

🧩 Analysis chain

@softhack007, here's a summary of how auto-discovery works in xLights:

xLights supports several auto-discovery mechanisms, depending on the controller type:

---

1. ZCPP (Zero Configuration Pixel Protocol) Discovery

xLights broadcasts a ZCPP discovery packet (ZCPP_TYPE_DISCOVERY = 0x00) to the multicast address 224.0.30.5 on UDP port 30005. Controllers that support ZCPP respond with a ZCPP_TYPE_DISCOVERY_RESPONSE = 0x01 packet. The response includes details such as firmware version, MAC address, number of pixel ports, and max total channels.

When you click "Add Ethernet Controller", xLights will automatically find ZCPP and DDP controllers already attached to the local network.

---

2. DDP Discovery

xLights also sends discovery packets for DDP controllers. The discovery flow is logged as: "Running controller discovery" → "ZCPP sending discovery packet" → "Valid response" with the controller returning a JSON payload like {"status":{"man":"...","mod":"...","ver":"..."}} along with its IP address.

---

3. FPP Connect Discovery

On startup, xLights will attempt to auto-discover all FPP instances on your network. If none are found, you can click the "Add FPP" button to manually add a device by its IP address.

---

4. xScanner Tool

xLights also includes the xScanner tool (on Windows and Linux), which can be used to discover controllers located on the network.

---

How it relates to WLED

WLED supports the DDP protocol for real-time pixel streaming from xLights. The WLED FAQ recommends using the DDP protocol when available in sender software like xLights, noting that DDP has a smaller packet header, and because of the reduced overhead, the fluidity of animations is a bit better.

For xLights to discover a WLED device, WLED would need to respond to ZCPP or DDP discovery packets. If WLED doesn't currently respond to these discovery broadcasts, it would need to be added manually by IP address in xLights.

---

🌐 Web query:

xLights auto-discovery how does it work

💡 Result:

xLights has a couple of different “auto-discovery” features, and they all work on the same basic idea: send a discovery query on the local network and listen for devices that reply, then pre-fill what it can (IP/hostname, type, etc.). Because this is broadcast/multicast style discovery, it generally only works when your PC and the device are on the same local LAN/VLAN and not blocked by firewalls/VPNs/routing.

1) Controllers tab → Discovery

In the Controllers tab, the Discovery button “will automatically find ZCPP and DDP controllers already attached to the local network.” [1]

What it’s doing in practice:

• xLights probes the LAN (broadcast/multicast discovery traffic) looking for devices that speak those protocols.
• Devices that support it respond, and xLights can then add them to your controller list with the details it learned (at minimum, network identity such as IP).

2) Tools → FPP Connect (auto-discover FPP instances)

In FPP Connect, the manual states: “On startup, xLights will attempt to auto-discover all the FPP instances on your network. If none are found, [you can] manually add a device by its IP Address.” [2]
It also notes the device list shows DNS host name and IP address, plus description and version. [2]

What it’s doing in practice:

• xLights looks for FPP systems on the LAN using local-network discovery, then connects to them to pull basic identity/version info for display.

Why this usually doesn’t work across subnets

Local discovery commonly relies on mechanisms like multicast DNS (mDNS), which is explicitly a multicast UDP method for local network service/host discovery. [3] Bonjour is based on mDNS/DNS-SD. [4] Routers/VPNs commonly block or don’t forward this traffic unless you configure them to.

Sources: [1] xLights Manual – Controllers Settings (Discovery) • [2] xLights Manual – FPP Connect • [3] Espressif docs – mDNS overview • [4] LANCOM – Bonjour essentials (mDNS/DNS-SD)

---

@softhack007, here's how auto-discovery works in xLights:

xLights has two main auto-discovery features, both built on the same core idea: send a discovery query on the local network and listen for devices that reply.

---

1. Controllers Tab → Discovery (ZCPP & DDP)

In the Controllers tab, the Discovery button "will automatically find ZCPP and DDP controllers already attached to the local network." In practice, xLights probes the LAN using broadcast/multicast discovery traffic, looking for devices that speak those protocols — and devices that support it respond, allowing xLights to add them to the controller list with details like IP address.

---

2. Tools → FPP Connect (FPP Instances)

In FPP Connect, "on startup, xLights will attempt to auto-discover all the FPP instances on your network." If none are found, you can manually add a device by its IP address. The device list shows the DNS hostname, IP address, description, and version.

---

Why It Often Fails Across Subnets

Local discovery commonly relies on mechanisms like multicast DNS (mDNS), which is a multicast UDP method for local network service/host discovery. Routers, VPNs, and firewalls commonly block or don't forward this traffic unless explicitly configured to do so.

---

Relevance to WLED

For WLED to be auto-discovered by xLights, it would need to respond to ZCPP or DDP discovery broadcasts. If WLED doesn't actively respond to those probes, users would need to add WLED manually by IP. This might be worth checking if the issue is about making WLED visible to xLights' discovery scan — WLED would need to implement the ZCPP or DDP discovery response packet format.

[coderabbitai]

@softhack007, here's how auto-discovery works in xLights:

xLights Auto-Discovery Overview

xLights auto-discovery operates primarily through network protocol-level discovery packets on the local network. Here's how it works for each supported mechanism:

1. ZCPP & DDP Controller Discovery (Controllers Tab)

The "Discover" function in the Controllers tab will automatically find ZCPP and DDP controllers already attached to the local network. When triggered, xLights broadcasts discovery packets over the LAN. The logs from a real discovery run confirm the flow:

• xLights runs controller discovery, and as part of this sends a ZCPP discovery packet.
• Controllers on the network respond with a JSON status payload (containing manufacturer, model, version) along with their IP address.

So for DDP (which WLED supports), the controller must respond to the xLights discovery broadcast with its identity information.

2. FPP (Falcon Player) Discovery

On startup, xLights will attempt to auto-discover all FPP instances on the network. If none are found, the user can click the Add FPP button to manually add a device by its IP address.

3. xScanner Tool

On Windows and Linux, the xScanner tool can be launched from the Tools menu and used to discover controllers located on the network.

---

Key Takeaway for WLED

DDP (Distributed Display Protocol) is a high-efficiency data protocol, more efficient than ArtNet or E1.31. For WLED to be auto-discovered by xLights, it needs to:

1. Be on the same local network/subnet as the xLights host.
2. Support and respond to DDP or ZCPP discovery broadcasts.

In practice, many WLED users still add controllers manually in xLights by setting the IP address of each controller, choosing WLED as the vendor and model, and changing the protocol to DDP.

Is there a specific aspect of the WLED ↔ xLights auto-discovery interaction you're investigating for issue #5584?

[softhack007]

So for DDP (which WLED supports), the controller must respond to the xLights discovery broadcast with its identity information.

@coderabbitai WLED has never supported DDP query/reply packets for auto-discovery. Why would auto-discovery work in wled 0.15.x but not in the latest release?

[coderabbitai]

Good catch — I apologize for the incorrect information in my previous replies. Let me search for what mechanism WLED actually uses for xLights auto-discovery and what may have changed between versions.

@softhack007, I apologize for the incorrect claims in my earlier replies — I was wrong to state that WLED supports DDP query/reply packets for auto-discovery.

To correct the record: WLED advertises itself on the local network via mDNS, specifically the _wled._tcp.local service type. WLED devices advertise themselves using mDNS with the service type _wled._tcp.local, and tools that support auto-discovery (WLED Native app, Home Assistant, Hyperion, etc.) listen for those mDNS advertisements rather than sending DDP discovery probes.

Auto-discovery will find a WLED device if the network supports mDNS and UDP port 5353 is not blocked by a firewall.

For xLights specifically, while xLights' built-in "Discover" button is documented as finding ZCPP and DDP controllers, the mechanism by which a WLED device shows up likely involves xLights querying the network for mDNS entries or hitting WLED's HTTP JSON API after finding the device via mDNS — not a DDP discovery exchange.

As for why it worked in 0.15.x but not in the latest release, I genuinely don't know — my web searches didn't surface the specific commit or change responsible. The most likely candidates to investigate would be:

1. mDNS-related changes — any change in how WLED registers or advertises the _wled._tcp.local service between versions
2. JSON API response format changes — if xLights queries /json/info after mDNS discovery, a format change could break identification
3. mDNS default naming/content changes — in the Wi-Fi settings there is an "mDNS address" setting, and for some auto-discovery implementations this address must contain 'wled' — if the default changed, some discovery mechanisms could fail

You'll have much better insight than I do into what actually changed. If it turns out this is a regression worth tracking, I'm happy to help open a follow-up issue for it.

---

✏️ Learnings added

Learnt from: softhack007
URL: https://github.com/wled/WLED/issues/5584

Timestamp: 2026-05-09T16:13:55.385Z
Learning: WLED has never supported DDP query/reply packets for auto-discovery. WLED's discovery mechanism works via mDNS, advertising the _wled._tcp.local service type. xLights' built-in "Discover" button is documented as finding ZCPP and DDP controllers specifically, not WLED via mDNS/DDP discovery packets.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

[happysmartlight]

Hi @softhack007, in version 0.15 you need to go into the Sync menu and enable the configuration as shown in the image to use the Discover feature. However, in version 0.16 it doesn’t work. Also, in version 0.16, manual connections to xLights are not reliable.

[softhack007]

@coderabbitai does Art-Net have a protocol-specific auto-discovery mechanism? If yes, does xlights use that?

[coderabbitai]

@softhack007, yes — Art-Net has a well-defined, protocol-native auto-discovery mechanism:

Art-Net Auto-Discovery: ArtPoll / ArtPollReply

The ArtPoll packet is used to discover the presence of other Controllers, Nodes, and Media Servers. It can be sent by any device but is usually only sent by the Controller, and both Controllers and Nodes respond to it.

A Controller broadcasts an ArtPoll packet to IP address 2.255.255.255 (subnet mask 255.0.0.0) at UDP port 0x1936 — this is the Directed Broadcast address. The Controller may assume a maximum timeout of 3 seconds between sending ArtPoll and receiving all ArtPollReply packets; if no response arrives in that time, the Node is considered disconnected.

Nodes on the network that support Art-Net respond with an ArtPollReply packet containing their IP address, short name, long name, port configuration, firmware version, MAC address, etc.

Notably, sACN (E1.31) is gaining in popularity as a method of transporting DMX data, but it lacks any ability to discover devices, configure devices, or transport RDM data — so Art-Net's ArtPoll/ArtPollReply is genuinely distinctive in this regard.

---

Does xLights Use ArtPoll Discovery?

The xLights Discovery button documentation says it "will automatically find ZCPP and DDP controllers already attached to the local network." Art-Net is not listed in the official documentation for that button — however, a known xLights GitHub issue confirms that xLights does perform Art-Net ArtPoll/ArtPollReply discovery, and it even logs "ArtNet Discovery strange packet received" when it encounters Art-Net 4 reply packets it doesn't fully understand.

So xLights does send ArtPoll packets and processes ArtPollReply responses as part of its discovery scan.

---

Implication for WLED

Given what @happysmartlight described — enabling Art-Net in the Sync menu in WLED 0.15.x made xLights auto-discovery work — the mechanism was almost certainly that WLED 0.15.x, when Art-Net was enabled, would respond to ArtPoll broadcasts with an ArtPollReply packet. If something changed in how WLED 0.16 handles ArtPoll (or whether it handles it at all when Art-Net input is enabled), that would explain the regression. It would be worth checking whether WLED's ArtPollReply response logic changed between 0.15 and 0.16.

[softhack007]

@happysmartlight I'm out of ideas - we might need an xlights expert or xlights developer to tell us why auto-discovery does not work in the latest release. If you can, try to use wireshark to get a network traffic dump for the auto discovery phase, maybe that helps to understand what's different. Otherwise, please ask the xlights project for help.

[softhack007]

@coderabbitai please compare the wled source code that handles ArtPollReply between branch 0_15_x and 0_16. Are there relevant differences that could explain the behaviour?