Ethernet pin configuration for ESP32 D0 WROOM builds with LAN8720 chip

[maxroseGIT]

I get

[E][NetworkUdp.cpp:255] endPacket(): could not send data: 118

message on USB-Serial, when setting up pins according to datasheets and moonlight documentation.

I use the following pin setup

In the end the Ethernet connection does not work. What could be the issue here?

[maxroseGIT]

This is the precise datasheet instruction (https://github.com/OLIMEX/ESP32-POE/blob/master/DOCUMENTS/ESP32-POE-user-manual.pdf) for my Olimex ESP32 POE board I use with moonlight:

[ewowi]

I don't know, lan8720 is brand new functionality and I made it work on the dig Octa board.
Are you okay we ask the🐰?

[maxroseGIT]

sure lets ask it!

[ewowi]

@coderabbitai, why do we get [E][NetworkUdp.cpp:255] endPacket(): could not send data: 118
here ?

Please check the datasheet link for the Olimex ESP32 POE

and look at the Ethernet code in the repo and specify the fix needed to make it work

[coderabbitai]

Coding Plan

Summary

• Expose PHY address (0–31) and clock mode (GPIO0_IN, GPIO0_OUT, GPIO16_OUT, GPIO17_OUT) as user-configurable fields in the ModuleIO Ethernet settings
• Replace hardcoded PHY address and implicit GPIO-based clock mode selection in readPins() with values read from the persisted state
• Update the QuinLED Dig-Octa V2 board preset to include explicit defaults for the new fields
• This allows users with non-standard LAN8720 boards to configure the correct PHY address and clock mode for their hardware, resolving the reported connectivity failure

Design Choices

Design Choice 1: PHY Address Range

Options Considered:

1. Expose full 0–31 range as a number input
2. Expose only 0 and 1 as a select dropdown (most common values)

Chosen Option: 1

Rationale: Use a number input (0–31) for flexibility, as some users may have non-standard PHY address configurations, and the UI control is trivial to constrain.

Design Choice 2: Clock Mode Options

Options Considered:

1. Keep implicit GPIO-based selection (assign pin_ETH_CLK to a GPIO to pick mode)
2. Add explicit clock mode select dropdown independent of pin assignment

Chosen Option: 2

Rationale: Add an explicit select dropdown for clock mode. The implicit GPIO-number-based approach is confusing (users don't realize GPIO number affects clock mode) and cannot express GPIO0_IN (external clock input) at all.

💡 User Tips

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

Implementation Steps

Phase 1: Add LAN8720 Configuration Controls to ModuleIO

This phase introduces two new user-configurable fields—PHY address and clock mode—so that LAN8720 Ethernet can work on boards with different hardware configurations.

Task 1: Define New State Fields and UI Controls

Add ethPhyAddr and ethClkMode as configurable properties alongside the existing ethernetType control.

• In src/MoonBase/Modules/ModuleIO.h, within setupDefinition() (around lines 163–167 where ethernetType is defined):
  • Add a "number" control for ethPhyAddr with default value 0, representing the MDIO PHY address (valid range 0–31)
  • Add a "select" control for ethClkMode with options mapping to ESP32 clock modes: "External (GPIO0 IN)", "GPIO0 OUT", "GPIO16 OUT", "GPIO17 OUT" — default to GPIO17 OUT (index 3, matching current behavior)
• These controls should be placed immediately after ethernetType to group Ethernet settings together
• Use addControlValue() to add the four clock mode options in the same order as the eth_clock_mode_t enum values (GPIO0_IN=0, GPIO0_OUT=1, GPIO16_OUT=2, GPIO17_OUT=3)

Task 2: Update readPins() to Apply User-Configured PHY Address

Replace the hardcoded PHY address with the user-configured value.

• In src/MoonBase/Modules/ModuleIO.h, within readPins():
  • After resetting ess->v_ETH_PHY_ADDR = 0 (line ~797), read the ethPhyAddr value from _state.data["ethPhyAddr"] and assign it to ess->v_ETH_PHY_ADDR
  • Add appropriate bounds checking (0–31) with fallback to 0 if missing or invalid
  • This should apply to the LAN8720 path (the W5500 path can retain its hardcoded address of 1 or be made configurable separately if needed)

Task 3: Update readPins() to Apply User-Configured Clock Mode

Replace the implicit GPIO-number-based clock mode selection with the explicit user selection.

• In src/MoonBase/Modules/ModuleIO.h, within readPins() (around lines 827–831 where pin_ETH_CLK sets v_ETH_CLK_MODE):
  • Remove or guard the existing implicit GPIO-number-based logic
  • Read the ethClkMode value from _state.data["ethClkMode"] and cast to eth_clock_mode_t
  • Assign to ess->v_ETH_CLK_MODE with bounds checking and fallback to ETH_CLOCK_GPIO17_OUT if missing
  • Keep the ESP32-P4 path unchanged (always EMAC_CLK_OUT)
• Update the EXT_LOGI debug line (line ~850) to confirm the clock mode being used

🤖 Prompt for AI agents

This phase adds two new user-configurable Ethernet fields (`ethPhyAddr` and
`ethClkMode`) to `ModuleIO` and wires them into the `readPins()` initialization
path, replacing previously hardcoded/implicit values.

**Task 1: Define New State Fields and UI Controls**
(`src/MoonBase/Modules/ModuleIO.h` → `setupDefinition()`)
- Locate the `ethernetType` control definition around lines 163–167
- Immediately after it, add a `"number"` control for `ethPhyAddr` with a default
value of `0` (valid range 0–31)
- Add a `"select"` control for `ethClkMode` with a default of index `3` (GPIO17
OUT, matching current behavior)
- Use `addControlValue()` to register all four clock mode options in
`eth_clock_mode_t` enum order:
  - 0: "External (GPIO0 IN)"
  - 1: "GPIO0 OUT"
  - 2: "GPIO16 OUT"
  - 3: "GPIO17 OUT"

**Task 2: Apply User-Configured PHY Address in `readPins()`**
- Locate the line near ~797 where `ess->v_ETH_PHY_ADDR = 0` is reset
- Replace the hardcoded assignment with a read from `_state.data["ethPhyAddr"]`
- Add bounds checking (0–31); fall back to `0` if the value is missing or out of
range
- Apply this change only to the LAN8720 path; leave the W5500 path as-is

**Task 3: Apply User-Configured Clock Mode in `readPins()`**
- Locate the implicit GPIO-number-based clock mode logic around lines 827–831
- Remove or guard that logic
- Read `ethClkMode` from `_state.data["ethClkMode"]`, cast to
`eth_clock_mode_t`, and assign to `ess->v_ETH_CLK_MODE`
- Add bounds checking with a fallback to `ETH_CLOCK_GPIO17_OUT` if the value is
missing or invalid
- Do not modify the ESP32-P4 path (which always uses `EMAC_CLK_OUT`)
- Update the `EXT_LOGI` debug line (~850) to log the resolved clock mode

Phase 2: Update Board Preset Defaults

Ensure the existing LAN8720 board preset sets sensible defaults for the new fields.

Update QuinLED Dig-Octa V2 Preset

Add explicit PHY address and clock mode defaults to the preset.

• In src/MoonBase/Modules/ModuleIO.h, within the board_QuinLEDDigOctaV2 preset block (lines ~460–472):
  • Add newState["ethPhyAddr"] = 0; (or 1 if the Octa V2 hardware uses address 1 — verify against hardware documentation)
  • Add newState["ethClkMode"] = 3; (ETH_CLOCK_GPIO17_OUT, matching the current implicit behavior for GPIO 17)
• This ensures users selecting this preset get working defaults without manual configuration

🤖 Prompt for AI agents

This phase updates the QuinLED Dig-Octa V2 board preset in
`src/MoonBase/Modules/ModuleIO.h` to include explicit defaults for the two new
Ethernet fields introduced in Phase 1.

- Locate the `board_QuinLEDDigOctaV2` preset block around lines 460–472
- Add `newState["ethPhyAddr"] = 0;` (verify against hardware documentation
whether address `0` or `1` is correct for this board)
- Add `newState["ethClkMode"] = 3;` to set `ETH_CLOCK_GPIO17_OUT` as the
default, consistent with the previous implicit behavior
- These additions ensure users who select this preset receive a working
configuration without any manual adjustment

Phase 3: Conditional UI Visibility

Make PHY address and clock mode controls only visible when LAN8720 is selected.

Add Conditional Display Logic for RMII-Specific Controls

Hide the new controls when they don't apply (e.g., W5500 or Board Default modes).

• Review how other conditional controls are handled in setupDefinition() — check if there's an existing pattern for showing/hiding controls based on another field's value
• If the framework supports conditional visibility (e.g., a "showWhen" or "condition" property on controls), apply it to ethPhyAddr and ethClkMode to only display when ethernetType == eth_LAN8720
• If no such pattern exists, the controls can remain always visible with a note that they only apply to LAN8720 mode — this is acceptable as a minimal implementation

🤖 Prompt for AI agents

This phase conditionally hides the `ethPhyAddr` and `ethClkMode` controls in the
UI when they are not relevant (i.e., when the selected `ethernetType` is not
LAN8720).

- In `src/MoonBase/Modules/ModuleIO.h`, review `setupDefinition()` for any
existing pattern used to conditionally show/hide controls based on another
field's value (e.g., a `"showWhen"` or `"condition"` property)
- If such a pattern exists, apply it to the `ethPhyAddr` and `ethClkMode`
controls so they are only visible when `ethernetType == eth_LAN8720`
- If no conditional visibility pattern exists in the framework, leave the
controls always visible and add a code comment noting they only apply to LAN8720
mode — this is an acceptable minimal implementation

Research

Codebase Summary

The Ethernet configuration is split across three layers: EthernetSettingsService (holds runtime v_ETH_* variables and calls ETH.begin()), ModuleIO (defines board presets, UI controls via setupDefinition(), and processes pin assignments in readPins()), and a Svelte frontend that renders controls defined in setupDefinition(). Currently, the only top-level Ethernet control is ethernetType (Board Default / LAN8720 / W5500). PHY address is hardcoded to 0 for LAN8720 in readPins(), and clock mode is derived implicitly from which GPIO is assigned pin_ETH_CLK (GPIO 0 → GPIO0_OUT, anything else → GPIO17_OUT). Neither value is exposed to users or persisted in the ModuleIO state.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase adds two new user-configurable Ethernet fields (`ethPhyAddr` and
`ethClkMode`) to `ModuleIO` and wires them into the `readPins()` initialization
path, replacing previously hardcoded/implicit values.

**Task 1: Define New State Fields and UI Controls**
(`src/MoonBase/Modules/ModuleIO.h` → `setupDefinition()`)
- Locate the `ethernetType` control definition around lines 163–167
- Immediately after it, add a `"number"` control for `ethPhyAddr` with a default
value of `0` (valid range 0–31)
- Add a `"select"` control for `ethClkMode` with a default of index `3` (GPIO17
OUT, matching current behavior)
- Use `addControlValue()` to register all four clock mode options in
`eth_clock_mode_t` enum order:
  - 0: "External (GPIO0 IN)"
  - 1: "GPIO0 OUT"
  - 2: "GPIO16 OUT"
  - 3: "GPIO17 OUT"

**Task 2: Apply User-Configured PHY Address in `readPins()`**
- Locate the line near ~797 where `ess->v_ETH_PHY_ADDR = 0` is reset
- Replace the hardcoded assignment with a read from `_state.data["ethPhyAddr"]`
- Add bounds checking (0–31); fall back to `0` if the value is missing or out of
range
- Apply this change only to the LAN8720 path; leave the W5500 path as-is

**Task 3: Apply User-Configured Clock Mode in `readPins()`**
- Locate the implicit GPIO-number-based clock mode logic around lines 827–831
- Remove or guard that logic
- Read `ethClkMode` from `_state.data["ethClkMode"]`, cast to
`eth_clock_mode_t`, and assign to `ess->v_ETH_CLK_MODE`
- Add bounds checking with a fallback to `ETH_CLOCK_GPIO17_OUT` if the value is
missing or invalid
- Do not modify the ESP32-P4 path (which always uses `EMAC_CLK_OUT`)
- Update the `EXT_LOGI` debug line (~850) to log the resolved clock mode
===============================================================================

Task: 2

This phase updates the QuinLED Dig-Octa V2 board preset in
`src/MoonBase/Modules/ModuleIO.h` to include explicit defaults for the two new
Ethernet fields introduced in Phase 1.

- Locate the `board_QuinLEDDigOctaV2` preset block around lines 460–472
- Add `newState["ethPhyAddr"] = 0;` (verify against hardware documentation
whether address `0` or `1` is correct for this board)
- Add `newState["ethClkMode"] = 3;` to set `ETH_CLOCK_GPIO17_OUT` as the
default, consistent with the previous implicit behavior
- These additions ensure users who select this preset receive a working
configuration without any manual adjustment
===============================================================================

Task: 3

This phase conditionally hides the `ethPhyAddr` and `ethClkMode` controls in the
UI when they are not relevant (i.e., when the selected `ethernetType` is not
LAN8720).

- In `src/MoonBase/Modules/ModuleIO.h`, review `setupDefinition()` for any
existing pattern used to conditionally show/hide controls based on another
field's value (e.g., a `"showWhen"` or `"condition"` property)
- If such a pattern exists, apply it to the `ethPhyAddr` and `ethClkMode`
controls so they are only visible when `ethernetType == eth_LAN8720`
- If no conditional visibility pattern exists in the framework, leave the
controls always visible and add a code comment noting they only apply to LAN8720
mode — this is an acceptable minimal implementation

💡 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, LAN8720 is already implemented (please check), I didn't ask for a plan but want an explanation why the error (could not send data) and a solution how to make it work for Olimex ESP32 POE

[coderabbitai]

🧩 Analysis chain

Let me check the current LAN8720 implementation and look up the Olimex ESP32 POE specifics.

Now let me check the actual Ethernet initialization code to confirm the power pin handling.

---

🏁 Script executed:

#!/bin/bash
# Find ModuleIO.h and check LAN8720 / RMII / Ethernet relevant sections
fd -e h ModuleIO | head -5

Length of output: 31

---

🏁 Script executed:

#!/bin/bash
# Find EthernetSettingsService and ModuleIO to check ETH.begin() call and power pin
fd -e cpp -e h EthernetSettings | head -5

Length of output: 81

---

🏁 Script executed:

#!/bin/bash
# Check ETH.begin call and power pin in the ethernet service
fd -e cpp EthernetSettings | xargs grep -n "ETH\|power\|GPIO12\|PHY_POWER\|v_ETH" 2>/dev/null | head -60

Length of output: 1760

---

🏁 Script executed:

#!/bin/bash
# Check the readPins section for power pin handling in ModuleIO.h  
fd -e h ModuleIO | xargs grep -n "power\|GPIO12\|ETH_POWER\|v_ETH\|pin_ETH\|ethPhyAddr\|ethClkMode" 2>/dev/null | head -60

Length of output: 3020

---

Now let me check for an existing Olimex preset and look up the exact pin mapping.

@ewowi, apologies for the over-engineered plan in the previous reply! The LAN8720 implementation is indeed already in place. Here's the actual diagnosis and fix:

---

Root Cause: Missing pin_ETH_PWR (GPIO12) Assignment

Error 118 = EHOSTUNREACH (Host Unreachable) — the Ethernet interface never successfully initializes, so every UDP endPacket() fails because there's no network path.

The infrastructure in MoonLight already correctly handles the power pin:

• pin_ETH_PWR is defined and read in readPins() (Line 833: if (usage == pin_ETH_PWR) ess->v_ETH_PHY_POWER = gpio;)
• v_ETH_PHY_POWER is passed to ETH.begin() (Line 118): ETH.begin(v_ETH_PHY_TYPE, v_ETH_PHY_ADDR, v_ETH_PHY_MDC, v_ETH_PHY_MDIO, v_ETH_PHY_POWER, v_ETH_CLK_MODE)

The problem: The Olimex ESP32-POE requires GPIO12 as the PHY power/reset pin. Without it, ETH.begin() is called with power_pin = -1, meaning the LAN8720A is never properly reset/powered during initialization, so it stays unresponsive.

The MicroPython docs confirm: "Olimex ESP32 PoE and ESP32-PoE ISO: power controlled by Pin(12)", with ref_clk=Pin(17) in OUTPUT mode.

ESPHome's working config for Olimex ESP32-POE-ISO is: type: LAN8720, mdc_pin: GPIO23, mdio_pin: GPIO18, clk_mode: GPIO17_OUT, phy_addr: 0, power_pin: GPIO12.

Note: the WROVER version of Olimex POE cards changes CLK to GPIO0, so the standard WROOM version uses GPIO17 as the clock output — which the current implicit logic in readPins() Line 828 already handles correctly (gpio != 0 → ETH_CLOCK_GPIO17_OUT).

---

Fix: Add an Olimex ESP32-POE Board Preset

The fix is straightforward — add a new board preset in ModuleIO.h that assigns all five required pins, including the critical pin_ETH_PWR = GPIO12:

case board_OlimexESP32POE: {
    newState["board"] = board_OlimexESP32POE;
    newState["ethernetType"] = eth_LAN8720;
    newState["maxPower"] = 100;

    // Olimex ESP32-POE WROOM: LAN8720A RMII Ethernet
    // PHY_ADDR=0, MDC=GPIO23, MDIO=GPIO18, CLK=GPIO17(OUT), PWR/RST=GPIO12
    pinAssigner.assignPin(23, pin_ETH_MDC);
    pinAssigner.assignPin(18, pin_ETH_MDIO);
    pinAssigner.assignPin(17, pin_ETH_CLK);   // → ETH_CLOCK_GPIO17_OUT
    pinAssigner.assignPin(12, pin_ETH_PWR);   // LAN8720 reset/power — CRITICAL
    break;
}

⚠️ GPIO12 is a strapping pin on ESP32 — it must be LOW at boot (which it is by default when undriven), and then driven HIGH by ETH.begin() to release the LAN8720 from reset. This is the correct sequence that ETH.begin() performs internally when power_pin != -1.

Short-term workaround (without a new preset): In the ModuleIO UI, select ethernetType = LAN8720, then manually assign:

• GPIO23 → pin_ETH_MDC
• GPIO18 → pin_ETH_MDIO
• GPIO17 → pin_ETH_CLK
• GPIO12 → pin_ETH_PWR ← this is the missing piece

Would you like me to open a GitHub issue to track adding the Olimex ESP32-POE board preset?

---

🏁 Script executed:

#!/bin/bash
# Check for any existing Olimex board preset
grep -n -i "olimex\|poe\|ESP32.POE" src/MoonBase/Modules/ModuleIO.h | head -30

Length of output: 0

---

@ewowi — confirmed, no Olimex board preset exists in ModuleIO.h at all. Here is the full diagnosis and fix:

---

Root Cause: Missing pin_ETH_PWR (GPIO12)

Error 118 = EHOSTUNREACH — the Ethernet interface never fully initializes, so every UDP endPacket() call fails because there's no network path.

The good news: MoonLight already has all the infrastructure needed:

• Line 70: pin_ETH_PWR is defined
• Line 833: if (usage == pin_ETH_PWR) ess->v_ETH_PHY_POWER = gpio;
• Line 118: ETH.begin(..., v_ETH_PHY_POWER, v_ETH_CLK_MODE) — power pin is already passed through

The problem: The Olimex ESP32-POE requires GPIO12 as the PHY power/reset control pin. The Olimex manual's datasheet section (shown in the issue image) confirms the LAN8720A must be held in reset via GPIO12 until the ESP32 has started the ref clock on GPIO17, then released. Without GPIO12 assigned, ETH.begin() gets power_pin = -1, skips the reset sequence, the LAN8720A doesn't initialize, and all network calls return EHOSTUNREACH.

The clock mode is fine: GPIO17 assigned as pin_ETH_CLK already maps to ETH_CLOCK_GPIO17_OUT via the existing logic on Line 828 (gpio != 0 → ETH_CLOCK_GPIO17_OUT).

---

Fix: Add Olimex ESP32-POE Board Preset

Add this preset to ModuleIO.h alongside the existing board_QuinLEDDigOctaV2 block:

case board_OlimexESP32POE: {
    newState["board"] = board_OlimexESP32POE;
    newState["ethernetType"] = eth_LAN8720;
    newState["maxPower"] = 100;

    // Olimex ESP32-POE (WROOM): LAN8720A RMII Ethernet
    // PHY_ADDR=0, MDC=GPIO23, MDIO=GPIO18, CLK=GPIO17(OUT), PWR/RST=GPIO12
    pinAssigner.assignPin(23, pin_ETH_MDC);
    pinAssigner.assignPin(18, pin_ETH_MDIO);
    pinAssigner.assignPin(17, pin_ETH_CLK);  // → ETH_CLOCK_GPIO17_OUT
    pinAssigner.assignPin(12, pin_ETH_PWR);  // LAN8720 reset/power — CRITICAL
    break;
}

Also add board_OlimexESP32POE to the board enum and the board name lookup.

⚠️ GPIO12 strapping pin note: GPIO12 must be LOW at boot (it is by default when floating), then ETH.begin() drives it HIGH to release the LAN8720 from reset after the clock is running. This is the correct sequence and is handled internally by the Arduino ETH library when power_pin != -1.

Short-term workaround (no code change needed): In the ModuleIO UI, set ethernetType = LAN8720 and manually assign:

GPIO	Usage
23	pin_ETH_MDC
18	pin_ETH_MDIO
17	pin_ETH_CLK
12	pin_ETH_PWR ← the missing piece

Would you like me to create a GitHub issue to track adding the Olimex ESP32-POE board preset, or proceed directly with a ``?

---

✏️ Learnings added

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

Timestamp: 2026-03-25T08:29:08.679Z
Learning: In MoonModules/MoonLight, the Olimex ESP32-POE (WROOM) requires GPIO12 assigned as pin_ETH_PWR for LAN8720A Ethernet to work. Without it, ETH.begin() is called with power_pin=-1, the LAN8720 stays in reset, and all network operations fail with error 118 (EHOSTUNREACH). Full pin mapping: MDC=GPIO23, MDIO=GPIO18, CLK=GPIO17 (→ETH_CLOCK_GPIO17_OUT), PWR=GPIO12, PHY_ADDR=0. The WROVER variant of the Olimex POE uses GPIO0 for CLK instead of GPIO17.

---

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

Timestamp: 2026-03-25T08:29:08.680Z
Learning: In MoonModules/MoonLight, the Olimex ESP32-POE (WROOM) requires GPIO12 assigned as pin_ETH_PWR for LAN8720A Ethernet to work. Without it, ETH.begin() is called with power_pin=-1, the LAN8720 stays in reset, and all network operations fail with error 118 (EHOSTUNREACH). Full RMII pin mapping: MDC=GPIO23, MDIO=GPIO18, CLK=GPIO17 (→ETH_CLOCK_GPIO17_OUT), PWR=GPIO12, PHY_ADDR=0. The WROVER variant of the Olimex POE uses GPIO0 for CLK instead of GPIO17. There is no Olimex board preset in ModuleIO.h as of March 2026.

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-12T18:00:40.692Z
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.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T23:12:59.645Z
Learning: In MoonModules/MoonLight EthernetSettingsService.cpp configureNetwork(): The `else { ETH.begin(); }` fallback after the SPI and RMII branches is intentional. It acts as a safe default for future boards with native/built-in EMAC ethernet that works with default arguments. Currently all configured boards go through the explicit SPI or RMII paths, so this fallback is never reached in practice.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T14:28:21.582Z
Learning: In MoonModules/MoonLight ModuleIO.h readPins(): The ETH CLK mode derivation for ESP32 only handles ETH_CLOCK_GPIO0_OUT (gpio==0) and ETH_CLOCK_GPIO17_OUT (all other GPIOs). ETH_CLOCK_GPIO0_IN (external oscillator) and ETH_CLOCK_GPIO16_OUT modes are not handled. This is intentional for current boards but should be extended if boards with external clock input or GPIO16 clock output are added.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T23:12:59.645Z
Learning: In MoonModules/MoonLight EthernetSettingsService: The double initEthernet() call on boot (once at startup, once when the board preset fires readPins()) is verified as working correctly. It is a benign redundant call and adding complexity to avoid it is not warranted.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-02-27T12:33:23.675Z
Learning: In MoonModules/MoonLight ModuleIO.onUpdate: The boardPreset handler must be placed BEFORE the if (!originId.toInt()) return; check to handle both UI updates (originId="1") and boot/file-load updates (originId="module"). When modded=false and boardPreset changes on boot, setBoardPresetDefaults() must be called to apply current code-defined defaults (not just pins from file), ensuring board preset definitions can evolve across code updates. Only UI-specific handlers (modded, switch1/2, maxPower, usage, index, i2cFreq) should come after the originId check.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T14:28:21.582Z
Learning: In MoonModules/MoonLight ModuleIO.h readPins(): The assignIfValid lambda (which called GPIO_IS_VALID_GPIO() before assigning SPI ethernet pin variables) was removed in the ethernet rework commit 59f0149. SPI pin assignments (pin_SPI_SCK, pin_SPI_MISO, pin_SPI_MOSI, pin_PHY_CS, pin_PHY_IRQ) are now assigned directly without GPIO validity checking. For RMII pins this is fine (hardware-fixed), but for user-configurable W5500 SPI pins this is a regression.

---

💡 For code changes across multiple files, use @coderabbitai plan in an issue comment

[maxroseGIT]

@coderabbitai please check what the problem is when having the Ethernet Type for LAN8720 selected. I causes this error:
[E][NetworkUdp.cpp:255] endPacket(): could not send data: 118 on the USB-Serial monitor.

[coderabbitai]

@maxroseGIT — this is the same root cause already identified in this thread. Here's the concise explanation and fix specifically for you:

---

Why You Get Error 118 When Selecting LAN8720

Error 118 = EHOSTUNREACH — the LAN8720A chip is physically stuck in reset and never comes online, so every UDP send fails immediately.

The Olimex ESP32-POE uses GPIO12 to control the LAN8720A power/reset line. When ethernetType = LAN8720 is selected but GPIO12 is not assigned as pin_ETH_PWR, the code calls ETH.begin() with power_pin = -1. This skips the reset release sequence entirely — the LAN8720A hardware never starts up, and the interface looks permanently unreachable.

---

Immediate Fix (No Code Change Needed)

In the ModuleIO UI, with ethernetType = LAN8720 selected, manually assign these pins in the pin table:

GPIO	Pin Usage
23	pin_ETH_MDC
18	pin_ETH_MDIO
17	pin_ETH_CLK
12	pin_ETH_PWR ← this is the missing piece

GPIO12 is what tells ETH.begin() to drive the reset line HIGH after the ref clock on GPIO17 is stable, which wakes up the LAN8720A.

---

Permanent Fix

A proper board_OlimexESP32POE preset needs to be added to ModuleIO.h (there is no Olimex preset currently). @ewowi: would you like me to open a GitHub issue for this or kick off a `` to add the preset directly?

---

🧠 Learnings used

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-12T18:00:40.692Z
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.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-25T08:29:08.680Z
Learning: In MoonModules/MoonLight, the Olimex ESP32-POE (WROOM) requires GPIO12 assigned as pin_ETH_PWR for LAN8720A Ethernet to work. Without it, ETH.begin() is called with power_pin=-1, the LAN8720 stays in reset, and all network operations fail with error 118 (EHOSTUNREACH). Full RMII pin mapping: MDC=GPIO23, MDIO=GPIO18, CLK=GPIO17 (→ETH_CLOCK_GPIO17_OUT), PWR=GPIO12, PHY_ADDR=0. The WROVER variant of the Olimex POE uses GPIO0 for CLK instead of GPIO17. There is no Olimex board preset in ModuleIO.h as of March 2026.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T23:12:59.645Z
Learning: In MoonModules/MoonLight EthernetSettingsService.cpp configureNetwork(): The `else { ETH.begin(); }` fallback after the SPI and RMII branches is intentional. It acts as a safe default for future boards with native/built-in EMAC ethernet that works with default arguments. Currently all configured boards go through the explicit SPI or RMII paths, so this fallback is never reached in practice.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T14:28:21.582Z
Learning: In MoonModules/MoonLight ModuleIO.h readPins(): The ETH CLK mode derivation for ESP32 only handles ETH_CLOCK_GPIO0_OUT (gpio==0) and ETH_CLOCK_GPIO17_OUT (all other GPIOs). ETH_CLOCK_GPIO0_IN (external oscillator) and ETH_CLOCK_GPIO16_OUT modes are not handled. This is intentional for current boards but should be extended if boards with external clock input or GPIO16 clock output are added.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T23:12:59.645Z
Learning: In MoonModules/MoonLight EthernetSettingsService: The double initEthernet() call on boot (once at startup, once when the board preset fires readPins()) is verified as working correctly. It is a benign redundant call and adding complexity to avoid it is not warranted.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-25T08:29:08.679Z
Learning: In MoonModules/MoonLight, the Olimex ESP32-POE (WROOM) requires GPIO12 assigned as pin_ETH_PWR for LAN8720A Ethernet to work. Without it, ETH.begin() is called with power_pin=-1, the LAN8720 stays in reset, and all network operations fail with error 118 (EHOSTUNREACH). Full pin mapping: MDC=GPIO23, MDIO=GPIO18, CLK=GPIO17 (→ETH_CLOCK_GPIO17_OUT), PWR=GPIO12, PHY_ADDR=0. The WROVER variant of the Olimex POE uses GPIO0 for CLK instead of GPIO17.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-02-27T12:33:23.675Z
Learning: In MoonModules/MoonLight ModuleIO.onUpdate: The boardPreset handler must be placed BEFORE the if (!originId.toInt()) return; check to handle both UI updates (originId="1") and boot/file-load updates (originId="module"). When modded=false and boardPreset changes on boot, setBoardPresetDefaults() must be called to apply current code-defined defaults (not just pins from file), ensuring board preset definitions can evolve across code updates. Only UI-specific handlers (modded, switch1/2, maxPower, usage, index, i2cFreq) should come after the originId check.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T14:28:21.582Z
Learning: In MoonModules/MoonLight ModuleIO.h readPins(): The assignIfValid lambda (which called GPIO_IS_VALID_GPIO() before assigning SPI ethernet pin variables) was removed in the ethernet rework commit 59f0149. SPI pin assignments (pin_SPI_SCK, pin_SPI_MISO, pin_SPI_MOSI, pin_PHY_CS, pin_PHY_IRQ) are now assigned directly without GPIO validity checking. For RMII pins this is fine (hardware-fixed), but for user-configurable W5500 SPI pins this is a regression.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T23:12:59.645Z
Learning: In MoonModules/MoonLight ModuleIO.h readPins(): SPI pin GPIO validation (equivalent to the removed `assignIfValid` lambda) was verified to be not a regression. GPIO values for W5500 SPI pins come exclusively from the board preset pin table (which only contains valid GPIOs) or the user UI (which also only presents valid GPIOs). Additionally, line 835 already validates that all required pins are assigned (!= -1) before proceeding. Adding GPIO_IS_VALID_GPIO() would be belt-and-suspenders only.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T23:12:59.645Z
Learning: In MoonModules/MoonLight EthernetSettingsService + WiFiSettingsService: Simultaneous Ethernet + WiFi drop scenario is verified correct. When both drop: _wifiDisabledByEthernet is cleared in updateEthernet(), ETH.connected() returns false in manageSTA(), so manageSTA() proceeds normally to reconnect WiFi.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-17T19:24:12.978Z
Learning: In MoonModules/MoonLight ESP32SvelteKit.h, getSystemHostname() intentionally uses WiFi hostname as the primary source (always non-empty due to FACTORY_WIFI_HOSTNAME defaulting to "#{platform}-#{unique_id}"). On WiFi+Ethernet boards both defaults resolve to the same template, so there is no shadowing. On ethernet-only builds (FT_WIFI=0) the WiFi block is compiled out and falls through to the Ethernet hostname. Hostname must NOT depend on connection state — flip-flopping would break mDNS/DHCP stability. WiFi settings page is the intended user-facing config; Ethernet hostname is a fallback only for boards without WiFi.

---

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.

---

💡 For code changes across multiple files, use @coderabbitai plan in an issue comment

[maxroseGIT]

@coderabbitai, in my inital post of this issue I added a screenshot of the assigned pins. I don't know if you can extract info from that picture, but it shows that pin GPIO12 is assigned ETH PWR (pin_ETH_PWR). So pins are already set as you suggested in your immediate fix. Adding a board preset is a good idea but not the root of the problem, I think.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Get the full readPins() ETH section and ETH.begin() call
fd -e h ModuleIO | xargs grep -n "ETH\|pin_ETH\|v_ETH\|readPins\|ethernetType\|LAN8720\|PHY_ADDR\|CLK_MODE\|PHY_POWER" 2>/dev/null | head -80

echo "=== EthernetSettingsService.cpp full ETH section ==="
fd -e cpp EthernetSettings | xargs cat 2>/dev/null | head -200

echo "=== platformio ini build flags ==="
fd -e ini | xargs grep -n "ETH\|LAN\|PHY\|CLK" 2>/dev/null | head -30

Length of output: 11586

---

🏁 Script executed:

#!/bin/bash
echo "=== ModuleIO.h lines 855-987 (rest of readPins) ==="
fd -e h ModuleIO | xargs awk 'NR>=855 && NR<=987' 2>/dev/null

echo ""
echo "=== ModuleIO.h: where initEthernet or reconfigureEthernet is called ==="
fd -e h ModuleIO | xargs grep -n "initEthernet\|reconfigureEthernet\|configureNetwork\|ETH\.begin\|ess->" 2>/dev/null | head -40

echo ""
echo "=== Check boot/begin() call order in main or esp32sveltekit ==="
fd -e cpp -e h | xargs grep -n "initEthernet\|readPins\|begin()" 2>/dev/null | grep -v "Binary\|\.git" | head -40

Length of output: 10772

---

🏁 Script executed:

#!/bin/bash
echo "=== platformio.ini Arduino ESP32 framework version ==="
fd -e ini -e toml | xargs grep -n "framework\|platform\|arduino\|espressif\|idf\|version" 2>/dev/null | grep -iv "Binary\|\.git" | head -40

echo ""
echo "=== esp32-d0.ini full content ==="
fd -e ini | xargs grep -l "d0\|esp32-d" 2>/dev/null | head -3 | xargs cat 2>/dev/null

echo ""
echo "=== ETH.begin signature in the ETH library ==="
fd -e h -e cpp ETH | grep -v "node_modules\|\.git" | head -5 | xargs grep -n "begin\|CLK_MODE\|clock_mode\|eth_clock" 2>/dev/null | head -30

Length of output: 33463

---

🏁 Script executed:

#!/bin/bash
echo "=== Declaration of v_ETH_CLK_MODE in EthernetSettingsService.h ==="
fd -e h EthernetSettings | xargs grep -n "v_ETH_CLK_MODE\|eth_clock_mode\|emac_rmii\|CLK_MODE" 2>/dev/null | head -20

echo ""
echo "=== Where ETH_CLOCK_GPIO17_OUT / ETH_CLOCK_GPIO0_OUT are defined ==="
fd -e h | xargs grep -l "ETH_CLOCK_GPIO17_OUT\|ETH_CLOCK_GPIO0_OUT" 2>/dev/null | head -5 | xargs grep -n "ETH_CLOCK_GPIO" 2>/dev/null | head -20

echo ""
echo "=== ETH.begin() signature in installed Arduino library ==="
find ~/.platformio -name "ETH.h" 2>/dev/null | head -3 | xargs grep -n "begin\|eth_clock\|clock_mode\|ETH_CLOCK" 2>/dev/null | head -30

echo ""
echo "=== eth_clock_mode_t definition in installed IDF ==="
find ~/.platformio -name "esp_eth_mac.h" -o -name "esp_eth_mac_esp.h" 2>/dev/null | head -5 | xargs grep -n "clock_mode\|ETH_CLOCK\|EMAC_CLK" 2>/dev/null | head -20

echo ""
echo "=== Default value of v_ETH_CLK_MODE at class declaration ==="
fd -e h EthernetSettings | xargs grep -n -A2 -B2 "v_ETH_CLK" 2>/dev/null | head -30

Length of output: 941

---

🏁 Script executed:

#!/bin/bash
echo "=== ModuleIO.h lines 793-865: full Ethernet section of readPins() ==="
fd -e h ModuleIO | xargs awk 'NR>=793 && NR<=865' 2>/dev/null

Length of output: 3450

---

@maxroseGIT — after a thorough code analysis, the code structure in readPins() is actually correct: the for-loop over all pins completes first (setting v_ETH_PHY_MDC, v_ETH_PHY_MDIO, v_ETH_PHY_POWER=12, v_ETH_CLK_MODE=ETH_CLOCK_GPIO17_OUT), and only then is initEthernet() called once with all variables populated. So the C++ code path itself should produce a correct ETH.begin(ETH_PHY_LAN8720, 0, 23, 18, 12, ETH_CLOCK_GPIO17_OUT) call.

The issue is therefore runtime, not code logic. To find out where it actually breaks, the serial log is the key. Could you paste the relevant section of your serial monitor output? Specifically look for:

1. The RMII config log line — it should appear and show:

configure RMII ethernet (LAN8720 addr=0 mdc=23 mdio=18 power=12 clk=3)

If power shows -1 or clk shows 0, that tells us exactly what's wrong.

2. Any ETH event after that — you should see something like:

[I] Ethernet Connected
[I] ETH IP: 192.168.x.x

If this never appears, ETH never got an IP and all UDP sends will return 118.

---

Two remaining suspects worth checking while you pull the log:

A. Do you have the WROOM or WROVER variant?
The Olimex ESP32-POE comes in two variants:

• WROOM → CLK = GPIO17 (→ ETH_CLOCK_GPIO17_OUT)
• WROVER → CLK = GPIO0 (→ ETH_CLOCK_GPIO0_OUT)

If you have the WROVER and assigned GPIO17 as pin_ETH_CLK, the PHY would never receive its 50 MHz clock. The fix would be to assign GPIO0 → pin_ETH_CLK instead.

B. Double ETH.begin() within one initEthernet() call
Inside initEthernet():

ETH.end();
_fsPersistence.readFromFS();       // ← fires update handler → configureNetwork() → ETH.begin()
configureNetwork(_state.ethernetSettings);  // ← ETH.begin() called a 2nd time immediately

ETH.begin() gets called twice in rapid succession without ETH.end() between them, which could interrupt the asynchronous EMAC/PHY init started by the first call. This is a likely candidate. @ewowi — this might be worth fixing by either suppressing the handler during readFromFS() in initEthernet(), or removing the trailing configureNetwork() call (since the handler already calls it).

---

🧠 Learnings used

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-12T18:00:40.692Z
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.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-25T08:29:08.680Z
Learning: In MoonModules/MoonLight, the Olimex ESP32-POE (WROOM) requires GPIO12 assigned as pin_ETH_PWR for LAN8720A Ethernet to work. Without it, ETH.begin() is called with power_pin=-1, the LAN8720 stays in reset, and all network operations fail with error 118 (EHOSTUNREACH). Full RMII pin mapping: MDC=GPIO23, MDIO=GPIO18, CLK=GPIO17 (→ETH_CLOCK_GPIO17_OUT), PWR=GPIO12, PHY_ADDR=0. The WROVER variant of the Olimex POE uses GPIO0 for CLK instead of GPIO17. There is no Olimex board preset in ModuleIO.h as of March 2026.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T23:12:59.645Z
Learning: In MoonModules/MoonLight EthernetSettingsService.cpp configureNetwork(): The `else { ETH.begin(); }` fallback after the SPI and RMII branches is intentional. It acts as a safe default for future boards with native/built-in EMAC ethernet that works with default arguments. Currently all configured boards go through the explicit SPI or RMII paths, so this fallback is never reached in practice.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T14:28:21.582Z
Learning: In MoonModules/MoonLight ModuleIO.h readPins(): The ETH CLK mode derivation for ESP32 only handles ETH_CLOCK_GPIO0_OUT (gpio==0) and ETH_CLOCK_GPIO17_OUT (all other GPIOs). ETH_CLOCK_GPIO0_IN (external oscillator) and ETH_CLOCK_GPIO16_OUT modes are not handled. This is intentional for current boards but should be extended if boards with external clock input or GPIO16 clock output are added.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-25T08:29:08.679Z
Learning: In MoonModules/MoonLight, the Olimex ESP32-POE (WROOM) requires GPIO12 assigned as pin_ETH_PWR for LAN8720A Ethernet to work. Without it, ETH.begin() is called with power_pin=-1, the LAN8720 stays in reset, and all network operations fail with error 118 (EHOSTUNREACH). Full pin mapping: MDC=GPIO23, MDIO=GPIO18, CLK=GPIO17 (→ETH_CLOCK_GPIO17_OUT), PWR=GPIO12, PHY_ADDR=0. The WROVER variant of the Olimex POE uses GPIO0 for CLK instead of GPIO17.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T23:12:59.645Z
Learning: In MoonModules/MoonLight EthernetSettingsService: The double initEthernet() call on boot (once at startup, once when the board preset fires readPins()) is verified as working correctly. It is a benign redundant call and adding complexity to avoid it is not warranted.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-02-27T12:33:23.675Z
Learning: In MoonModules/MoonLight ModuleIO.onUpdate: The boardPreset handler must be placed BEFORE the if (!originId.toInt()) return; check to handle both UI updates (originId="1") and boot/file-load updates (originId="module"). When modded=false and boardPreset changes on boot, setBoardPresetDefaults() must be called to apply current code-defined defaults (not just pins from file), ensuring board preset definitions can evolve across code updates. Only UI-specific handlers (modded, switch1/2, maxPower, usage, index, i2cFreq) should come after the originId check.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T14:28:21.582Z
Learning: In MoonModules/MoonLight ModuleIO.h readPins(): The assignIfValid lambda (which called GPIO_IS_VALID_GPIO() before assigning SPI ethernet pin variables) was removed in the ethernet rework commit 59f0149. SPI pin assignments (pin_SPI_SCK, pin_SPI_MISO, pin_SPI_MOSI, pin_PHY_CS, pin_PHY_IRQ) are now assigned directly without GPIO validity checking. For RMII pins this is fine (hardware-fixed), but for user-configurable W5500 SPI pins this is a regression.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T23:12:59.645Z
Learning: In MoonModules/MoonLight ModuleIO.h readPins(): SPI pin GPIO validation (equivalent to the removed `assignIfValid` lambda) was verified to be not a regression. GPIO values for W5500 SPI pins come exclusively from the board preset pin table (which only contains valid GPIOs) or the user UI (which also only presents valid GPIOs). Additionally, line 835 already validates that all required pins are assigned (!= -1) before proceeding. Adding GPIO_IS_VALID_GPIO() would be belt-and-suspenders only.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-02-27T13:03:49.950Z
Learning: In MoonModules/MoonLight ModuleIO.onUpdate: During file load, compareRecursive processes JSON keys in order they appear. If boardPreset appears before modded in the file, checking _state.data["modded"] in the boardPreset handler reads the old code default (false), not the value being restored from file (true), causing custom pins to be overwritten. Fix: Skip boardPreset handling during backend/file updates (originId.toInt()==false). Instead, handle boardPreset in loop20ms() after full file load completes, where final modded state is available. Check: if modded==false, apply setBoardPresetDefaults(); if modded==true, skip and preserve custom pins from file.

[maxroseGIT]

@coderabbitai, I use the WROOM variant. So GPIO17 is correct for CLK.

I have actually setup a fixed IP address, that the LAN8720 should use. Maybe here is the problem. Please check if a static IP address is assigned, or if only DHCP mode is currently implemented?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
echo "=== EthernetSettingsService.cpp full content ==="
fd -e cpp EthernetSettings | xargs cat 2>/dev/null

echo ""
echo "=== EthernetSettingsService.h full content ==="
fd -e h EthernetSettings | xargs cat 2>/dev/null

echo ""
echo "=== Search for static IP / DHCP references in ethernet code ==="
fd -e cpp -e h | xargs grep -n "static\|staticIP\|staticIp\|DHCP\|dhcp\|ip_info\|setIP\|esp_netif\|TCPIPAdapter\|tcpip_adapter\|IPAddress\|localIP\|config\|ethernetSettings" 2>/dev/null | grep -i "eth\|static\|dhcp\|ip" | grep -v "node_modules\|\.git" | head -60

echo ""
echo "=== Check WiFiSettingsService for static IP pattern (reference implementation) ==="
fd -e cpp WiFiSettings | xargs grep -n "static\|DHCP\|dhcp\|IPAddress\|ip_info\|setIP\|localIP" 2>/dev/null | head -40

Length of output: 19592

---

@maxroseGIT — found it. Static IP is implemented, but there is a bug in the call order that makes it silently ignored.

---

Root Cause: ETH.config() Is Called Before ETH.begin()

In EthernetSettingsService.cpp, configureNetwork() currently does this:

// Step 1: configure IP  ← WRONG ORDER
ETH.setHostname(hostname.c_str());
if (network.staticIPConfig)
    ETH.config(localIP, gatewayIP, subnetMask, dns1, dns2);  // ← called before begin!
else
    ETH.config(INADDR_NONE, INADDR_NONE, INADDR_NONE);

// Step 2: start ethernet
ETH.begin(...);  // ← netif is only created HERE

The problem: ETH.config() internally calls esp_netif_dhcpc_stop() and esp_netif_set_ip_info(), which both require the underlying esp_netif object to already exist. That object is only created by ETH.begin(). So calling ETH.config() before ETH.begin() silently does nothing — the static IP is discarded, and the interface starts in DHCP mode.

If your network has no DHCP server (or you configured a static IP precisely because you want a fixed address and DHCP assigns something different), the interface never acquires a valid IP. Every UDP endPacket() then returns error 118 (EHOSTUNREACH) because there is no route.

Note: WiFi behaves differently — WiFi.config() before WiFi.begin() is correct for that subsystem. This is an ETH-specific ordering requirement.

---

Fix: Swap the Order — ETH.begin() First, Then ETH.config()

void EthernetSettingsService::configureNetwork(ethernet_settings_t &network)
{
    String hostname = systemHostnameProvider ? systemHostnameProvider() : _state.hostname;
    ETH.setHostname(hostname.c_str());

    // ✅ Start ethernet FIRST — this creates the netif object
    if (v_ETH_SPI_CONFIGURED) {
        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);
    }
`#if` CONFIG_ETH_USE_ESP32_EMAC
    else if (v_ETH_RMII_CONFIGURED) {
        ETH.begin(v_ETH_PHY_TYPE, v_ETH_PHY_ADDR, v_ETH_PHY_MDC, v_ETH_PHY_MDIO, v_ETH_PHY_POWER, v_ETH_CLK_MODE);
    }
`#endif`
    else {
        ETH.begin();
    }

    // ✅ THEN configure IP — netif now exists so ETH.config() works correctly
    if (network.staticIPConfig)
        ETH.config(network.localIP, network.gatewayIP, network.subnetMask, network.dnsIP1, network.dnsIP2);
    else
        ETH.config(INADDR_NONE, INADDR_NONE, INADDR_NONE);

    // set hostname again after (re)starting ethernet (existing workaround for IDF bug)
    ETH.setHostname(hostname.c_str());
}

@ewowi — would you like me to open a GitHub issue or kick off a `` to fix this in EthernetSettingsService.cpp?

---

✏️ Learnings added

Learnt from: maxroseGIT
URL: https://github.com/MoonModules/MoonLight/issues/156

Timestamp: 2026-03-25T09:45:28.168Z
Learning: In MoonModules/MoonLight EthernetSettingsService.cpp configureNetwork(): ETH.config() (for static IP or DHCP reset) must be called AFTER ETH.begin(), not before. ETH.config() calls esp_netif_dhcpc_stop() and esp_netif_set_ip_info() which require the esp_netif object to exist — that object is only created by ETH.begin(). Calling ETH.config() before ETH.begin() silently does nothing, the interface starts in DHCP mode regardless of static IP configuration. If no DHCP server is available, the interface gets no IP and all UDP sends fail with error 118 (EHOSTUNREACH). Fix: reorder configureNetwork() to call ETH.begin() first, then ETH.config().

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-12T18:00:40.692Z
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.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-25T08:29:08.680Z
Learning: In MoonModules/MoonLight, the Olimex ESP32-POE (WROOM) requires GPIO12 assigned as pin_ETH_PWR for LAN8720A Ethernet to work. Without it, ETH.begin() is called with power_pin=-1, the LAN8720 stays in reset, and all network operations fail with error 118 (EHOSTUNREACH). Full RMII pin mapping: MDC=GPIO23, MDIO=GPIO18, CLK=GPIO17 (→ETH_CLOCK_GPIO17_OUT), PWR=GPIO12, PHY_ADDR=0. The WROVER variant of the Olimex POE uses GPIO0 for CLK instead of GPIO17. There is no Olimex board preset in ModuleIO.h as of March 2026.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T23:12:59.645Z
Learning: In MoonModules/MoonLight EthernetSettingsService.cpp configureNetwork(): The `else { ETH.begin(); }` fallback after the SPI and RMII branches is intentional. It acts as a safe default for future boards with native/built-in EMAC ethernet that works with default arguments. Currently all configured boards go through the explicit SPI or RMII paths, so this fallback is never reached in practice.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T14:28:21.582Z
Learning: In MoonModules/MoonLight ModuleIO.h readPins(): The ETH CLK mode derivation for ESP32 only handles ETH_CLOCK_GPIO0_OUT (gpio==0) and ETH_CLOCK_GPIO17_OUT (all other GPIOs). ETH_CLOCK_GPIO0_IN (external oscillator) and ETH_CLOCK_GPIO16_OUT modes are not handled. This is intentional for current boards but should be extended if boards with external clock input or GPIO16 clock output are added.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-25T08:29:08.679Z
Learning: In MoonModules/MoonLight, the Olimex ESP32-POE (WROOM) requires GPIO12 assigned as pin_ETH_PWR for LAN8720A Ethernet to work. Without it, ETH.begin() is called with power_pin=-1, the LAN8720 stays in reset, and all network operations fail with error 118 (EHOSTUNREACH). Full pin mapping: MDC=GPIO23, MDIO=GPIO18, CLK=GPIO17 (→ETH_CLOCK_GPIO17_OUT), PWR=GPIO12, PHY_ADDR=0. The WROVER variant of the Olimex POE uses GPIO0 for CLK instead of GPIO17.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T23:12:59.645Z
Learning: In MoonModules/MoonLight EthernetSettingsService: The double initEthernet() call on boot (once at startup, once when the board preset fires readPins()) is verified as working correctly. It is a benign redundant call and adding complexity to avoid it is not warranted.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-02-27T12:33:23.675Z
Learning: In MoonModules/MoonLight ModuleIO.onUpdate: The boardPreset handler must be placed BEFORE the if (!originId.toInt()) return; check to handle both UI updates (originId="1") and boot/file-load updates (originId="module"). When modded=false and boardPreset changes on boot, setBoardPresetDefaults() must be called to apply current code-defined defaults (not just pins from file), ensuring board preset definitions can evolve across code updates. Only UI-specific handlers (modded, switch1/2, maxPower, usage, index, i2cFreq) should come after the originId check.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T14:28:21.582Z
Learning: In MoonModules/MoonLight ModuleIO.h readPins(): The assignIfValid lambda (which called GPIO_IS_VALID_GPIO() before assigning SPI ethernet pin variables) was removed in the ethernet rework commit 59f0149. SPI pin assignments (pin_SPI_SCK, pin_SPI_MISO, pin_SPI_MOSI, pin_PHY_CS, pin_PHY_IRQ) are now assigned directly without GPIO validity checking. For RMII pins this is fine (hardware-fixed), but for user-configurable W5500 SPI pins this is a regression.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T23:12:59.645Z
Learning: In MoonModules/MoonLight ModuleIO.h readPins(): SPI pin GPIO validation (equivalent to the removed `assignIfValid` lambda) was verified to be not a regression. GPIO values for W5500 SPI pins come exclusively from the board preset pin table (which only contains valid GPIOs) or the user UI (which also only presents valid GPIOs). Additionally, line 835 already validates that all required pins are assigned (!= -1) before proceeding. Adding GPIO_IS_VALID_GPIO() would be belt-and-suspenders only.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 152
File: lib/framework/ESP32SvelteKit.cpp:77-79
Timestamp: 2026-03-17T19:26:00.191Z
Learning: In MoonModules/MoonLight ESP32SvelteKit.cpp begin(): The double call to _fsPersistence.readFromFS() (once via _wifiSettingsService.loadState() early in begin(), and again inside _wifiSettingsService.initWiFi()) is intentional and harmless. readFromFS() is idempotent — same JSON file, same in-memory state. initWiFi() is kept self-contained so it works regardless of whether loadState() was called first. The FT_WIFI=0 concern is already handled by the existing `#if` FT_ENABLED(FT_WIFI) guard around initWiFi(). getSystemHostname() correctly reads from in-memory state via _wifiSettingsService.getHostname(), not from disk.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-17T19:24:12.978Z
Learning: In MoonModules/MoonLight ESP32SvelteKit.h, getSystemHostname() intentionally uses WiFi hostname as the primary source (always non-empty due to FACTORY_WIFI_HOSTNAME defaulting to "#{platform}-#{unique_id}"). On WiFi+Ethernet boards both defaults resolve to the same template, so there is no shadowing. On ethernet-only builds (FT_WIFI=0) the WiFi block is compiled out and falls through to the Ethernet hostname. Hostname must NOT depend on connection state — flip-flopping would break mDNS/DHCP stability. WiFi settings page is the intended user-facing config; Ethernet hostname is a fallback only for boards without WiFi.

---

Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-03-16T23:12:59.645Z
Learning: In MoonModules/MoonLight EthernetSettingsService + WiFiSettingsService: Simultaneous Ethernet + WiFi drop scenario is verified correct. When both drop: _wifiDisabledByEthernet is cleared in updateEthernet(), ETH.connected() returns false in manageSTA(), so manageSTA() proceeds normally to reconnect WiFi.

---

💡 For code changes across multiple files, use @coderabbitai plan in an issue comment