Artnet test resolume now working (for ewoud)

[brammdg]

Ik heb Moonlight geïnstalleerd op mijn DIG-OCTA van QuinLED. De controller is met een ethernetkabel verbonden aan mijn MacBook. Met WLED werkt die kabel gewoon, maar met Moonlight niet. Daarom denk ik dat het mogelijk met de pinnen of de manier waarop de DIG-OCTA de verbinding uitleest te maken heeft.

Wat wel goed werkt: ik kan alle 20 LED-bars gebruiken, met 94 leds per bar. Ik kan ze allemaal inschakelen en er zonder problemen vaste kleuren of effecten overheen zetten. Dat werkt stabiel.

Voor de aansturing gebruik ik panels, zodat ik alles goed kan mappen op basis van mijn layout. In de panel-instellingen gebruik ik bij X en Y een configuratie van 2 bij 5, met 94 hoog. Of snake aan of uit staat, maakt in dit geval geen verschil. Bij de parallel LED driver gebruik ik de standaardinstellingen. Ook op de DIG-OCTA zelf heb ik niets bijzonders aangepast; alles staat nog op de normale settings.

Het probleem begint zodra ik Art-Net wil gebruiken via de parallel LED driver. Dan gebeurt er niets. In mijn netwerkinstellingen op de MacBook verschijnt bij Ethernet ook geen actieve verbinding. Er brandt aan beide kanten geen lampje. De kabel of poort is niet kapot, want met WLED werkt dezelfde opstelling wel. Daarom lijkt het erop dat het probleem specifiek zit in hoe de DIG-OCTA met Moonlight of deze netwerkconfiguratie omgaat.

Een extra belangrijk punt is mijn doel met deze setup. Ik wil Resolume gebruiken, zodat ik de LED-bars handmatig op hun juiste positie kan zetten. Daarna wil ik daar via Syphon video overheen mappen, zodat ik in TouchDesigner effecten kan maken en die direct naar de installatie kan sturen.

Via wifi zie ik de controller soms wel verschijnen, maar ik kan er niet mee verbinden. Op dit moment zit ik op het schoolnetwerk, dus dat kan daar ook mee te maken hebben. Het is dus niet helemaal duidelijk of dat probleem in de wifi-instellingen zit of ergens anders.

Daarom wil ik dat het juist via ethernet goed werkt. Dat is voor mij de belangrijkste route, omdat ik dan een stabiele verbinding kan gebruiken en mijn setup op 50 fps kan laten draaien. Dat is nodig om Resolume, Syphon en TouchDesigner soepel samen te laten werken en de video-effecten netjes over de LED-bars te mappen.

[ewowi]

@coderabbitai, Submitter wants to connect to a moonlight instance using esp32-d0-16mb directly via a laptop.

I think that doesn't work yet because with Ethernet no dns is enabled. Is that correct ? Can that be added ?

Submitter also says when using WiFi (in AP mode) it sometimes shows up (assigning 4.3.2.2 to the laptop showing dns is active)

Submitter wants the laptop to send artnet by Resolume Arena to the MoonLight device, artnet in has been added.

My take is that it should work with WiFi (but submitter reports it isn't), for Ethernet dns should be enabled.

please analyze this issue and propose solutions

[coderabbitai]

Coding Plan

Summary

• The Ethernet connectivity failure is caused by missing W5500 SPI pin assignments in the QuinLED Dig-Octa V2 board preset
• The fix requires adding five pinAssigner.assignPin() calls with the correct GPIO numbers for the DIG-OCTA's W5500 module
• Once pins are assigned, the existing readPins() mechanism automatically calls initEthernet(), bringing up the Ethernet interface
• No changes to the Art-Net protocol implementation are needed—the existing code will work once Ethernet is functional

Design Choices

Design Choice 1: W5500 Ethernet module SPI pin mapping for QuinLED DIG-OCTA

Options Considered:

1. Use default ESP32-S3 SPI pins from EthernetSettingsService.h (SCK=-1/MISO=44/MOSI=43/CS=41/IRQ=2) as a starting template
2. Reference QuinLED official documentation or community resources for the exact pin mapping
3. Allow user-configurable pins via the existing "modded" pin assignment UI

Chosen Option: 2

Rationale: The pin assignments must match the actual hardware wiring. Consult QuinLED DIG-OCTA documentation for the W5500 module's GPIO connections (typically labeled on the PCB or in product specs). If documentation is unavailable, the "modded" mode (Option 3) allows users to manually configure pins, but the preset should contain the correct defaults once confirmed.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Add Ethernet SPI Pin Configuration to QuinLED Dig-Octa V2 Board Preset

This phase addresses the root cause by extending the board preset to include the W5500 Ethernet module's SPI pin assignments, enabling automatic Ethernet initialization.

Task 1: Extend the QuinLED Dig-Octa V2 Board Preset with Ethernet Pins

Add the five required Ethernet SPI pin assignments to the existing board_QuinLEDDigOctaV2 case in the setBoardPresetDefaults() function.

• Locate the board_QuinLEDDigOctaV2 case in src/MoonBase/Modules/ModuleIO.h (around line 435)
• Add pinAssigner.assignPin() calls for each of the five Ethernet SPI pins: pin_SPI_SCK, pin_SPI_MISO, pin_SPI_MOSI, pin_PHY_CS, pin_PHY_IRQ
• Use the GPIO numbers from QuinLED DIG-OCTA hardware documentation (must be confirmed before implementation)
• Follow the existing pattern used by board_SE16V1 or board_LightCrafter16 presets for reference

Task 2: Verify Automatic Ethernet Initialization Path

Confirm the existing readPins() auto-initialization mechanism will trigger correctly when the new pins are assigned.

• Review the conditional block in readPins() (around line 814) that checks all five Ethernet pins are non--1 before calling ess->initEthernet()
• Ensure no additional changes are needed to EthernetSettingsService for the DIG-OCTA board
• Verify that v_ETH_PHY_TYPE = ETH_PHY_W5500 (the default) is correct for the DIG-OCTA's Ethernet module

Task 3: Add PHY Reset Pin Handling (If Applicable)

Determine whether the DIG-OCTA's W5500 module has a reset pin that needs to be managed.

• Check QuinLED documentation for W5500 reset pin wiring
• If a reset pin exists, add pinAssigner.assignPin(gpio, pin_PHY_RST) to the preset (note: the current readPins() sets v_ETH_PHY_RST = -1 unconditionally—this may need adjustment)
• If no reset pin is wired (common for many W5500 modules), no change is needed

🤖 Prompt for AI agents

This phase fixes the root cause of missing Ethernet connectivity by adding the
five W5500 SPI pin assignments to the `board_QuinLEDDigOctaV2` preset in
`src/MoonBase/Modules/ModuleIO.h`.

- Locate the `board_QuinLEDDigOctaV2` case inside the `setBoardPresetDefaults()`
function (around line 435)
- Add `pinAssigner.assignPin()` calls for the following five Ethernet SPI pins,
using GPIO numbers confirmed from QuinLED DIG-OCTA hardware documentation:
  - `pin_SPI_SCK`
  - `pin_SPI_MISO`
  - `pin_SPI_MOSI`
  - `pin_PHY_CS`
  - `pin_PHY_IRQ`
- Use the existing pattern from `board_SE16V1` or `board_LightCrafter16` presets
as a reference for how to structure these assignments
- After adding the pins, review the conditional block in `readPins()` (around
line 814) to confirm it checks all five Ethernet pins are non-`-1` before
calling `ess->initEthernet()` — no changes should be needed here, just verify
- Confirm that `v_ETH_PHY_TYPE = ETH_PHY_W5500` (the default) is appropriate for
the DIG-OCTA's Ethernet module
- Check QuinLED documentation for whether a W5500 reset pin is wired on the
DIG-OCTA:
- If yes: add `pinAssigner.assignPin(gpio, pin_PHY_RST)` to the preset and
review whether the unconditional `v_ETH_PHY_RST = -1` assignment in `readPins()`
needs to be updated
  - If no: no further changes are needed for reset pin handling

Phase 2: Validate Art-Net Functionality Over Ethernet

Once Ethernet links up, verify that Art-Net In correctly receives packets from Resolume and drives the LED bars.

Task 1: Confirm Art-Net In Configuration for the User's Setup

Review the Art-Net In driver settings to ensure they match the user's panel configuration (2×5 panels, 94 LEDs high).

• The user has 20 LED bars × 94 LEDs = 1880 total LEDs
• With 3-channel RGB: 1880 × 3 = 5640 bytes → requires ~11 Art-Net universes (512 bytes each)
• Ensure universeMin and universeMax in the Art-Net In driver are configured to span the required universe range
• Confirm channelsPerLight matches the LED strip's channel count (typically 3 for RGB or 4 for RGBW)

Task 2: Add Division-by-Zero Guard in Art-Net Handlers

Prevent a potential crash if channelsPerLight is zero (edge case identified during exploration).

• In src/MoonLight/Nodes/Drivers/D_ArtnetIn.h, add an early-return guard at the start of handleArtNet() and handleDDP() functions
• Check if (layerP.lights.header.channelsPerLight == 0) return; before any division operations
• This is a defensive fix to prevent undefined behavior

🤖 Prompt for AI agents

This phase validates Art-Net functionality over Ethernet and adds a defensive
guard against a potential crash in the Art-Net handlers.

- In `src/MoonLight/Nodes/Drivers/D_ArtnetIn.h`, add an early-return guard at
the beginning of both `handleArtNet()` and `handleDDP()` functions:
- Add `if (layerP.lights.header.channelsPerLight == 0) return;` before any
division operations that use `channelsPerLight`
- This prevents undefined behavior in the edge case where `channelsPerLight` is
zero
- No changes to the Art-Net protocol logic itself are needed; the existing
implementation is correct once Ethernet is functional
- Verify that the Art-Net In driver's `universeMin` and `universeMax` settings
are able to span the required universe range for the user's setup (20 bars × 94
LEDs = 1880 LEDs; 3-channel RGB = 5640 bytes ≈ 11 Art-Net universes)
- Confirm `channelsPerLight` is set to match the LED strip's channel count (3
for RGB, 4 for RGBW)

Research

MoonLight's board configuration system lives in src/MoonBase/Modules/ModuleIO.h, which defines board presets via setBoardPresetDefaults(). Each preset uses PinAssigner to map GPIO numbers to functional roles. For ESP32-S3 boards with W5500 Ethernet modules, five SPI pins must be assigned (pin_SPI_SCK, pin_SPI_MISO, pin_SPI_MOSI, pin_PHY_CS, pin_PHY_IRQ). When readPins() detects all five pins are configured, it automatically calls ess->initEthernet() to bring up the Ethernet interface. The current QuinLED Dig-Octa V2 preset only assigns LED pins, relay, and button—no Ethernet pins—which is why the W5500 never initializes.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase fixes the root cause of missing Ethernet connectivity by adding the
five W5500 SPI pin assignments to the `board_QuinLEDDigOctaV2` preset in
`src/MoonBase/Modules/ModuleIO.h`.

- Locate the `board_QuinLEDDigOctaV2` case inside the `setBoardPresetDefaults()`
function (around line 435)
- Add `pinAssigner.assignPin()` calls for the following five Ethernet SPI pins,
using GPIO numbers confirmed from QuinLED DIG-OCTA hardware documentation:
  - `pin_SPI_SCK`
  - `pin_SPI_MISO`
  - `pin_SPI_MOSI`
  - `pin_PHY_CS`
  - `pin_PHY_IRQ`
- Use the existing pattern from `board_SE16V1` or `board_LightCrafter16` presets
as a reference for how to structure these assignments
- After adding the pins, review the conditional block in `readPins()` (around
line 814) to confirm it checks all five Ethernet pins are non-`-1` before
calling `ess->initEthernet()` — no changes should be needed here, just verify
- Confirm that `v_ETH_PHY_TYPE = ETH_PHY_W5500` (the default) is appropriate for
the DIG-OCTA's Ethernet module
- Check QuinLED documentation for whether a W5500 reset pin is wired on the
DIG-OCTA:
- If yes: add `pinAssigner.assignPin(gpio, pin_PHY_RST)` to the preset and
review whether the unconditional `v_ETH_PHY_RST = -1` assignment in `readPins()`
needs to be updated
  - If no: no further changes are needed for reset pin handling
===============================================================================

Task: 2

This phase validates Art-Net functionality over Ethernet and adds a defensive
guard against a potential crash in the Art-Net handlers.

- In `src/MoonLight/Nodes/Drivers/D_ArtnetIn.h`, add an early-return guard at
the beginning of both `handleArtNet()` and `handleDDP()` functions:
- Add `if (layerP.lights.header.channelsPerLight == 0) return;` before any
division operations that use `channelsPerLight`
- This prevents undefined behavior in the edge case where `channelsPerLight` is
zero
- No changes to the Art-Net protocol logic itself are needed; the existing
implementation is correct once Ethernet is functional
- Verify that the Art-Net In driver's `universeMin` and `universeMax` settings
are able to span the required universe range for the user's setup (20 bars × 94
LEDs = 1880 LEDs; 3-channel RGB = 5640 bytes ≈ 11 Art-Net universes)
- Confirm `channelsPerLight` is set to match the LED strip's channel count (3
for RGB, 4 for RGBW)

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[ewowi]

@coderabbitai, regarding

Extend the QuinLED Dig-Octa V2 Board Preset with Ethernet Pins

I thought a normal esp32-d0 board with Ethernet doesn't need pins to be configured as it as hardware fixed ?

Regarding dns: I guess I mean dhcp: If you connect directly to MoonLight with a cable to a laptop , it needs to get an ip address from MoonLight. WiFi AP does it right ? What about Ethernet AP?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check for DHCP server setup in Ethernet code
rg -rn "dhcp" --type=cpp --type=h -i -C3

echo "=== Ethernet init ==="
rg -rn "initEthernet\|ETH_PHY\|ETH\.begin\|dhcpServer\|DHCP" --type=cpp --type=h -C2

echo "=== Board esp32-d0 references ==="
rg -rn "esp32.d0\|d0.16mb\|esp32d0" --type=cpp --type=h -i -C3

echo "=== WiFi AP DHCP ==="
rg -rn "softAP\|WiFi.*AP\|AP.*dhcp\|dhcpServer" --type=cpp --type=h -i -C3

Length of output: 889

---

🏁 Script executed:

#!/bin/bash
echo "=== EthernetSettingsService.cpp ==="
cat lib/framework/EthernetSettingsService.cpp

echo ""
echo "=== EthernetSettingsService.h ==="
cat lib/framework/EthernetSettingsService.h

echo ""
echo "=== WiFiSettingsService.cpp (AP section) ==="
cat lib/framework/WiFiSettingsService.cpp

echo ""
echo "=== Search softAP and DHCP server broadly ==="
rg -rn "softAP\|dhcpServer\|DHCP_Server\|leaseIP\|WiFi\.softAP" -C3

echo ""
echo "=== Search for board preset files ==="
fd -e json -e yaml -e h "board" | head -20

echo ""
echo "=== platformio.ini or board env for esp32d0 ==="
cat platformio.ini 2>/dev/null | head -80 || cat platformio.ini 2>/dev/null

Length of output: 34760

---

🏁 Script executed:

#!/bin/bash
echo "=== AP Settings Service ==="
fd -e cpp -e h "AP" | xargs grep -l "softAP\|dhcp\|DHCP" 2>/dev/null | head -5

echo ""
echo "=== APSettingsService files ==="
fd "APSettings" | head -10

echo ""
echo "=== softAP usage ==="
rg -rn "softAP\|AP_Start\|WiFi.softAP\|APService\|apService" -C3

echo ""
echo "=== firmware/esp32-d0 board ini ==="
fd -e ini "esp32-d0" | head -5

echo ""
echo "=== firmware folder listing ==="
ls firmware/ 2>/dev/null || ls */firmware/ 2>/dev/null || fd -e ini . firmware/ | head -20

echo ""
echo "=== Board ini files ==="
fd -e ini . | xargs grep -l "esp32-d0\|eth\|ethernet" 2>/dev/null | head -10

Length of output: 453

---

🏁 Script executed:

#!/bin/bash
echo "=== APSettingsService.cpp ==="
cat lib/framework/APSettingsService.cpp

echo ""
echo "=== APSettingsService.h ==="
cat lib/framework/APSettingsService.h

echo ""
echo "=== firmware/esp32-d0.ini ==="
cat firmware/esp32-d0.ini

Length of output: 15522

---

@ewowi — great questions, both clarifications are correct. Here's what the code confirms:

---

1. ESP32-D0 Ethernet Pins

You are right. The esp32-d0 (and esp32-d0-16mb) boards define -D CONFIG_IDF_TARGET_ESP32=1 in firmware/esp32-d0.ini. In EthernetSettingsService.cpp, the configureNetwork() function has this branching:

`#ifdef` CONFIG_IDF_TARGET_ESP32S3 
    // SPI-based W5500: needs pin config (SCK, MISO, MOSI, CS, IRQ)
    if (v_ETH_SPI_SCK != -1) {
        SPI.begin(v_ETH_SPI_SCK, v_ETH_SPI_MISO, v_ETH_SPI_MOSI);
        ETH.begin(v_ETH_PHY_TYPE, v_ETH_PHY_ADDR, v_ETH_PHY_CS, v_ETH_PHY_IRQ, v_ETH_PHY_RST, SPI);
    } else 
        ETH.begin();
`#else` // CONFIG_IDF_TARGET_ESP32 — built-in Ethernet MAC/PHY
    ETH.begin();  // ← No SPI pins needed; RMII pins are hardware-fixed
`#endif`

So for ESP32-D0, Ethernet uses the built-in MAC with an external RMII PHY (like LAN8720) on fixed hardware pins — no pin assignment is needed in software. The previous plan's "SPI pin configuration" only applies to the QuinLED Dig-Octa V2 (ESP32-S3 + W5500 SPI module). The ESP32-D0 just needs ETH.begin().

---

2. DHCP for Direct Ethernet Connection

You've identified the real issue. Here's the comparison:

Connection	DHCP Server?	How?
WiFi AP	✅ Yes	WiFi.softAP() in APSettingsService.cpp → Arduino-ESP32 automatically runs a DHCP server (hands out 192.168.4.x addresses)
Ethernet (direct cable)	❌ No	ETH.config(INADDR_NONE, ...) only enables DHCP client mode — no DHCP server is ever started

When a laptop plugs in via Ethernet directly, neither side is running a DHCP server, so the laptop can't get an IP automatically — this is why it doesn't work.

Proposed Solutions

Option A — Static IP (quickest workaround):
Configure a static IP in MoonLight's Ethernet settings (e.g. 192.168.5.1 / 255.255.255.0) and manually set the laptop's Ethernet adapter to a matching static IP (e.g. 192.168.5.2). No code changes needed.

Option B — Add a DHCP server for Ethernet (proper fix):
When Ethernet is up in a "no upstream router" scenario (i.e., direct connection), start a lwIP DHCP server on the Ethernet netif. This is more complex but mirrors what WiFi AP mode already does. In ESP-IDF / Arduino, this requires calling dhcps_start() on the ETH netif.

A minimal approach would be to add a flag/option like ethernetApMode in EthernetSettingsService — when enabled, assign a static IP to the Ethernet interface AND start a DHCP server on it, analogous to WiFi AP mode.

Would you like me to plan the code changes for Option B (Ethernet DHCP server)?

[ewowi]

@coderabbitai,

regarding

The previous plan's "SPI pin configuration" only applies to the QuinLED Dig-Octa V2 (ESP32-S3 + W5500 SPI module).

where can I buy this, afaik this isn't an existing thing.

Regarding:

The ESP32-D0 just needs ETH.begin(). What about this info:

https://quinled.info/quinled-dig-octa-brainboard-32-8l-pinout-guide/

Do some pins need to be assigned ?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
echo "=== Check board_QuinLEDDigOctaV2 preset in ModuleIO.h ==="
rg -n "QuinLED\|DigOcta\|board_QuinLED" --type=h -C5

echo ""
echo "=== EthernetSettingsService.cpp full ==="
cat lib/framework/EthernetSettingsService.cpp

echo ""
echo "=== ModuleIO.h Ethernet / board preset section ==="
fd "ModuleIO.h" | xargs grep -n "QuinLED\|DigOcta\|ETH\|Ethernet\|PHY\|SPI\|SCK\|MISO\|MOSI" 2>/dev/null | head -60

Length of output: 7236

---

🌐 Web query:

QuinLED DIG-OCTA BrainBoard 32-8L Ethernet LAN8720 pinout GPIO

💡 Result:

QuinLED DIG-OCTA BrainBoard 32-8L uses an onboard LAN8720A (10/100 Ethernet PHY). (quinled.info)

Ethernet (LAN8720A) ⇄ ESP32 GPIO mapping (BrainBoard-32-8L)

• REF_CLK (clock out): GPIO17 (quinled.info)
• MDIO: GPIO18 (quinled.info)
• MDC: GPIO23 (quinled.info)
• TXD0: GPIO19 (quinled.info)
• TXD1: GPIO22 (quinled.info)
• TX_EN: GPIO21 (quinled.info)
• RXD0: GPIO25 (quinled.info)
• RXD1: GPIO26 (quinled.info)
• CRS_DV: GPIO27 (quinled.info)

Note: On this board GPIO5 is not used for Ethernet power (it’s LED6 data); Ethernet power control is via a physical jumper. (quinled.info)

Citations:

• 1: https://quinled.info/quinled-dig-octa-brainboard-32-8l-specifications/
• 2: https://quinled.info/quinled-dig-octa-brainboard-32-8l-pinout-guide/
• 3: https://quinled.info/quinled-dig-octa-brainboard-32-8l-pinout-guide/
• 4: https://quinled.info/quinled-dig-octa-brainboard-32-8l-pinout-guide/
• 5: https://quinled.info/quinled-dig-octa-brainboard-32-8l-pinout-guide/
• 6: https://quinled.info/quinled-dig-octa-brainboard-32-8l-pinout-guide/
• 7: https://quinled.info/quinled-dig-octa-brainboard-32-8l-pinout-guide/
• 8: https://quinled.info/quinled-dig-octa-brainboard-32-8l-pinout-guide/
• 9: https://quinled.info/quinled-dig-octa-brainboard-32-8l-pinout-guide/
• 10: https://quinled.info/quinled-dig-octa-brainboard-32-8l-pinout-guide/
• 11: https://quinled.info/quinled-dig-octa-brainboard-32-8l-pinout-guide/

---

🏁 Script executed:

#!/bin/bash
echo "=== Full board_QuinLEDDigOctaV2 section in ModuleIO.h ==="
fd "ModuleIO.h" | xargs grep -n "" | grep -A60 "board_QuinLEDDigOctaV2"

echo ""
echo "=== firmware/esp32-d0.ini (full) ==="
cat firmware/esp32-d0.ini

echo ""
echo "=== EthernetSettingsService.h (check ETH.begin params / PHY defaults) ==="
cat lib/framework/EthernetSettingsService.h

echo ""
echo "=== Other board ETH pin assignment pattern (lines around 580-600) ==="
fd "ModuleIO.h" | xargs sed -n '570,620p'

echo ""
echo "=== Search ethernetPins usage in ModuleIO.h ==="
fd "ModuleIO.h" | xargs grep -n "ethernetPins\|pin_Ethernet\|ETH_CLK\|ETH_PHY\|LAN8720\|RMII" 

Length of output: 20130

---

@ewowi — you're absolutely right on both counts. Here's the corrected analysis:

---

1. "ESP32-S3 + W5500" — That was incorrect

Apologies for the confusion in the earlier plan. The code confirms this clearly:

• In EthernetSettingsService.h, all the v_ETH_SPI_SCK, v_ETH_PHY_TYPE = ETH_PHY_W5500, etc. variables only exist under #ifdef CONFIG_IDF_TARGET_ESP32S3. There is no W5500 path for the original ESP32.
• The web search and the quinled.info specs page confirm: the QuinLED DIG-OCTA BrainBoard 32-8L uses an original ESP32 with an onboard LAN8720A (RMII 10/100 PHY). There is no S3 + W5500 variant. The previous plan's Phase 1 was based on a hallucination — I apologize for that error.

---

2. Do Ethernet pins need to be assigned for the DIG-OCTA?

Yes — in two ways:

A) RMII pins should be marked as pin_Ethernet in the board preset

The current board_QuinLEDDigOctaV2 case (line 435–441) only assigns LED, relay, and button pins. The nine LAN8720A RMII GPIOs are never registered with the pin manager, so MoonLight doesn't know they're occupied by Ethernet. Comparing with board_TroyP4Nano (line 591–593) which correctly does:

uint8_t ethernetPins[] = {28, 29, 30, 31, 34, 35};
for (uint8_t gpio : ethernetPins) pinAssigner.assignPin(gpio, pin_Ethernet);

The DIG-OCTA needs the same treatment for its RMII pins. Based on the quinled.info pinout guide, the LAN8720A uses: REF_CLK=GPIO17, MDIO=GPIO18, TXD0=GPIO19, TX_EN=GPIO21, TXD1=GPIO22, MDC=GPIO23, RXD0=GPIO25, RXD1=GPIO26, CRS_DV=GPIO27.

} else if (boardID == board_QuinLEDDigOctaV2) {
  // Dig-Octa-32-8L
  newState["maxPower"] = 400;
  uint8_t ledPins[] = {0, 1, 2, 3, 4, 5, 12, 13};
  for (uint8_t gpio : ledPins) pinAssigner.assignPin(gpio, pin_LED);
  pinAssigner.assignPin(33, pin_Relay);
  pinAssigner.assignPin(34, pin_ButtonPush);
  // ✅ ADD: mark RMII Ethernet pins as occupied
  uint8_t ethernetPins[] = {17, 18, 19, 21, 22, 23, 25, 26, 27};
  for (uint8_t gpio : ethernetPins) pinAssigner.assignPin(gpio, pin_Ethernet);

B) ETH.begin() needs the correct clock mode — currently broken for DIG-OCTA

This is the more critical issue. For ESP32, ETH.begin() uses compile-time build flags for PHY type, clock mode, and PHY address. The firmware/esp32-d0.ini sets none of these currently.

The DIG-OCTA BrainBoard 32-8L has a LAN8720A, and its REF_CLK is on GPIO17 — meaning the ESP32 outputs the clock to the PHY. This requires ETH_CLOCK_GPIO17_OUT. The Arduino-ESP32 default is ETH_CLOCK_GPIO0_IN (external clock into GPIO0), which is wrong for this board. Without the correct clock mode, ETH.begin() will fail silently.

The needed build flags for a DIG-OCTA-specific env in platformio.ini would be:

-D ETH_CLK_MODE=ETH_CLOCK_GPIO17_OUT
-D ETH_PHY_TYPE=ETH_PHY_LAN8720
-D ETH_PHY_ADDR=0
; ETH_PHY_POWER=-1 (no GPIO power control, physical jumper on DIG-OCTA)

⚠️ Problem: These are compile-time flags, so they'd affect all esp32-d0 boards globally, not just the DIG-OCTA. Different ESP32 boards may use different PHYs (e.g. IP101, RTL8201) or different clock modes. The proper fix would be to extend EthernetSettingsService to support runtime-configurable PHY params for ESP32 (similar to how S3 already handles SPI pins via v_ETH_SPI_SCK etc.), and have board_QuinLEDDigOctaV2 set those values.

---

Summary of fixes needed

Fix	File	Notes
Mark RMII pins as pin_Ethernet	src/MoonBase/Modules/ModuleIO.h (line ~441)	GPIOs 17,18,19,21,22,23,25,26,27
Correct ETH clock mode + PHY config	firmware/esp32-d0.ini or EthernetSettingsService	ETH_CLOCK_GPIO17_OUT, ETH_PHY_LAN8720, PHY_ADDR=0 — ideally made runtime-configurable per board
Add DHCP server for direct Ethernet	lib/framework/EthernetSettingsService.cpp	Separate issue as discussed before

Would you like me to plan code changes for any of these?

---

✏️ Learnings added

Learnt from: ewowi
URL: https://github.com/MoonModules/MoonLight/issues/143

Timestamp: 2026-03-12T18:00:40.667Z
Learning: In MoonModules/MoonLight, the QuinLED DIG-OCTA BrainBoard 32-8L (board_QuinLEDDigOctaV2) uses an original ESP32 (not S3) with an onboard LAN8720A RMII PHY. It does NOT use W5500 or SPI Ethernet. The RMII Ethernet pins are hardware-fixed: REF_CLK=GPIO17, MDIO=GPIO18, TXD0=GPIO19, TX_EN=GPIO21, TXD1=GPIO22, MDC=GPIO23, RXD0=GPIO25, RXD1=GPIO26, CRS_DV=GPIO27. GPIO17 is a clock OUTPUT from ESP32 to LAN8720A, requiring ETH_CLOCK_GPIO17_OUT build flag (the default ETH_CLOCK_GPIO0_IN is wrong for this board). ETH power is controlled by a physical jumper, not a GPIO. The board preset currently does not mark these RMII pins as pin_Ethernet, and no ETH_CLK_MODE/ETH_PHY build flags are set in firmware/esp32-d0.ini.

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.

---

🧠 Learnings used

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-08T10:36:33.812Z
Learning: In MoonModules/MoonLight D_FastLEDDriver vs D_ParallelLEDDriver: The PARLIO driver (parlio.cpp) uses `queue_nonblocking = 1` in `parlio_transmit_config_t`, making LED transmission fully fire-and-forget via hardware DMA — zero ISR callbacks during TX, CPU is free for WiFi. FastLED RMT5 (default on IDF5+) uses ISR-driven segment streaming with ISR priority capped at 1-3, which causes constant WiFi interrupt contention and WebSocket throughput degradation at high frame rates. I2S has the same ISR-driven problem. Fix: add `-D FASTLED_RMT5=0` to platformio.ini to force FastLED RMT4, which has an explicit dual-buffer WiFi-resistant design. WARNING: RMT4 and RMT5 cannot coexist in the same binary (startup abort). The affinity="PARLIO" option in FastLED Driver uses FastLED's own PARLIO wrapper, not MoonLight's custom parlio.cpp.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2025-12-25T13:31:32.367Z
Learning: For ESP32 LED drivers using DMA, I2S, LCD, or PARLIO: always pin driver tasks to Core 1 (APP_CPU), not Core 0. WiFi/BT runs at priority ~23 on Core 0 and would constantly preempt lower-priority driver tasks, breaking LED timing requirements. ESP-IDF explicitly recommends display/DMA processing on Core 1 to avoid WiFi interference.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-08T10:36:33.812Z
Learning: In MoonModules/MoonLight D_FastLEDDriver: FastLED RMT5 (default on IDF >= 5) lacks the dual-buffer WiFi-resistance design of FastLED RMT4, causing WebSocket/WiFi throughput degradation at high LED frame rates. FastLED I2S is also incompatible with WiFi on ESP32-S3. MoonLight's D_ParallelLEDDriver (parlio.cpp) avoids this entirely by using its own DMA-streaming PARLIO implementation with zero per-frame ISR callbacks. Fix: add `-D FASTLED_RMT5=0` to platformio.ini for IDF5-based boards to force RMT4's dual-buffer design. This flag may need to be re-enabled even when a specific FastLED commit appeared stable, as RMT5 behavior varies across FastLED master commits.