Add support for the GLEDOPTO GL-C-618WL Ethernet Config

[libschmudie-so]

The GLEDOPTO GL-C-618WL seems to have another unique Ethernet Pinout/Config.

This commit adds the support for this ethernet config and therefore makes the board work fully.

The device in question: https://gledopto.com/h-pd-64.html

Summary by CodeRabbit

• New Features
  • Added support for GLEDOPTO GL-C-618WL Ethernet device with updated network configuration options.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The PR adds support for a new Ethernet device type (GLEDOPTO GL-C-618WL) by introducing a new constant in const.h, updating the Ethernet type count, adding UI support in settings_wifi.htm, and defining board-specific configuration parameters in network.cpp.

Changes

Cohort / File(s)	Summary
Ethernet type constant definition wled00/const.h	Added new Ethernet type macro WLED_ETH_GLEDOPTO_GLC618WL with value 13; incremented WLED_NUM_ETH_TYPES from 13 to 14
UI settings wled00/data/settings_wifi.htm	Added new dropdown option (value 13) labeled "GLEDOPTO GL-C-618WL" to the Ethernet Type select menu
Board configuration wled00/network.cpp	Added ethernet board configuration for GLEDOPTO GL-C-618WL with eth_address=1, eth_power=5, eth_mdc=23, eth_mdio=33, eth_type=ETH_PHY_LAN8720, eth_clk_mode=ETH_CLOCK_GPIO0_IN

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Verify that the constant value (13) matches across all three files
• Confirm the ethernet pin configuration (address, power, mdc, mdio, clk_mode) is correct for the GLEDOPTO GL-C-618WL device
• Check for consistency between UI dropdown value and the constant definition

Possibly related PRs

• support iotorero ethernet controller #4860: Modifies the Ethernet Type dropdown in settings_wifi.htm to add/update device options, sharing the same UI selection mechanism

Suggested reviewers

• netmindz

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title accurately describes the main change: adding support for a new Ethernet device configuration (GLEDOPTO GL-C-618WL). It is specific, concise, and directly reflects the changeset modifications.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bdea3d4 and 8e38a4b.

📒 Files selected for processing (3)

• wled00/const.h (1 hunks)
• wled00/data/settings_wifi.htm (1 hunks)
• wled00/network.cpp (1 hunks)

🧰 Additional context used

📓 Path-based instructions (5)

wled00/data/**/*.{htm,html,css,js}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Use tabs for indentation in web files (.htm/.html/.css/.js) under wled00/data

Files:

• wled00/data/settings_wifi.htm

wled00/data/**

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

wled00/data/**: When modifying web UI files, run npm run build to regenerate embedded headers before any firmware build
For web UI changes, edit files only under wled00/data (not firmware or generated files)

Files:

• wled00/data/settings_wifi.htm

wled00/data/settings*.htm

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Name settings pages as settings*.htm within the web UI

Files:

• wled00/data/settings_wifi.htm

wled00/**/*.cpp

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Use 2-space indentation for C++ source files (.cpp)

Files:

• wled00/network.cpp

wled00/**/!(html_*)*.h

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Use 2-space indentation for non-generated C++ header files (.h)

Files:

• wled00/const.h

🧠 Learnings (10)

📓 Common learnings

Learnt from: mval-sg
Repo: wled/WLED PR: 4876
File: wled00/wled_eeprom.cpp:0-0
Timestamp: 2025-09-01T10:26:17.959Z
Learning: In WLED PR #4876, the DMXStartLED EEPROM backward compatibility issue was partially addressed by keeping it at address 2550 and reading it as a 16-bit value, with DMXChannelsValue array moved to addresses 2552-2566. This maintains compatibility with pre-0.11 EEPROM layouts for DMXStartLED, though legacy "Set to 255" (code 6) configurations may still need migration logic.

📚 Learning: 2025-10-05T15:24:05.545Z

Learnt from: CR
Repo: wled/WLED PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-10-05T15:24:05.545Z
Learning: Applies to wled00/data/** : For web UI changes, edit files only under wled00/data (not firmware or generated files)

Applied to files:

• wled00/data/settings_wifi.htm

📚 Learning: 2025-11-20T00:04:04.829Z

Learnt from: netmindz
Repo: wled/WLED PR: 5093
File: wled00/util.cpp:1159-1182
Timestamp: 2025-11-20T00:04:04.829Z
Learning: In WLED PR #5093, the deviceId feature is designed for opt-in usage reporting that tracks only version/upgrade information (non-behavioral data), not user activity patterns. The deterministic salt approach (MAC + "WLED" + chip model/revision) is acceptable for this limited use case, as correlating MAC addresses to version history represents minimal privacy risk compared to behavioral tracking.

Applied to files:

• wled00/data/settings_wifi.htm

📚 Learning: 2025-11-14T13:37:30.955Z

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:30.955Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with defined constants when meaningful constants exist in the codebase. For example, suggest replacing hardcoded "32" with WLED_MAX_SEGNAME_LEN if the context relates to segment name length limits.

Applied to files:

• wled00/const.h

📚 Learning: 2025-11-14T13:37:11.994Z

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:11.994Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with appropriate defined constants when those constants are meaningful in the context of the PR. For example, the hardcoded value 32 should be replaced with WLED_MAX_SEGNAME_LEN when it represents a segment name length limit. This improves code maintainability and reduces the risk of inconsistencies.

Applied to files:

• wled00/const.h

📚 Learning: 2025-08-28T08:09:20.630Z

Learnt from: mval-sg
Repo: wled/WLED PR: 4876
File: wled00/xml.cpp:0-0
Timestamp: 2025-08-28T08:09:20.630Z
Learning: The WLED codebase has opportunities for refactoring hardcoded array bounds (like the "15" used for DMX channels) to use sizeof(array)/sizeof(array[0]) for more maintainable code, but such changes should be done consistently across the entire codebase in a dedicated refactoring effort.

Applied to files:

• wled00/const.h

📚 Learning: 2025-10-05T15:24:05.545Z

Learnt from: CR
Repo: wled/WLED PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-10-05T15:24:05.545Z
Learning: Applies to wled00/html_*.h : DO NOT edit generated embedded web header files (wled00/html_*.h)

Applied to files:

• wled00/const.h

📚 Learning: 2025-04-26T19:19:07.600Z

Learnt from: blazoncek
Repo: wled/WLED PR: 4658
File: wled00/const.h:140-141
Timestamp: 2025-04-26T19:19:07.600Z
Learning: In WLED, the WLED_MAX_PANELS macro is intentionally defined as a fixed constant value (18) with no redefinition mechanism, making it "unoverridable" - there's no need for a static assertion to check its maximum value.

Applied to files:

• wled00/const.h

📚 Learning: 2025-06-15T09:59:52.720Z

Learnt from: netmindz
Repo: wled/WLED PR: 4728
File: wled00/FX.h:378-378
Timestamp: 2025-06-15T09:59:52.720Z
Learning: In WLED's FX.h, MODE_COUNT represents the highest FX_MODE_ ID + 1, not the total count of FX_MODE_ definitions. This is because some effects may have been removed but their IDs are not reused, creating gaps in the numbering sequence. MODE_COUNT is used for array bounds and range checking.

Applied to files:

• wled00/const.h

📚 Learning: 2025-11-30T15:29:00.711Z

Learnt from: DedeHai
Repo: wled/WLED PR: 4456
File: usermods/deep_sleep/deep_sleep.cpp:224-230
Timestamp: 2025-11-30T15:29:00.711Z
Learning: In WLED, `touchThreshold` is a global variable defined in wled00/wled.h and is accessible to all usermods. It stores the touch sensitivity threshold for touch-capable GPIO pins on ESP32 variants and should not be flagged as undefined when used in usermods.

Applied to files:

• wled00/const.h

🔇 Additional comments (3)

wled00/data/settings_wifi.htm (1)

257-274: Ethernet type option wiring looks consistent; remember UI rebuild step

The new ETH select option for value="13" and label "GLEDOPTO GL-C-618WL" is consistent with the new Ethernet type ID and keeps the list complete for 0–13. Indentation also matches the existing options.

Per project guidelines for wled00/data/**, please ensure npm run build has been run so the embedded HTML headers are regenerated before firmware build.

wled00/const.h (1)

368-384: Ethernet type enumeration and count remain consistent

WLED_NUM_ETH_TYPES updated to 14 and the new WLED_ETH_GLEDOPTO_GLC618WL 13 keeps the Ethernet type IDs contiguous (0–13), matching the array bounds check in initEthernet().

No changes needed here.

wled00/network.cpp (1)

138-157: New GLEDOPTO ethernet board entry aligns with enum and pin handling

The appended ethernetBoards entry for "GLEDOPTO GL-C-618WL" at index 13 matches WLED_ETH_GLEDOPTO_GLC618WL and the UI ETH value 13. The chosen ETH_CLOCK_GPIO0_IN mode is already supported by the existing clock-pin switch logic, so no extra handling is required.

Assuming the pinout (power=5, MDC=23, MDIO=33, LAN8720 + GPIO0 clock-in) matches the board’s schematic, this looks good.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Aogu181]

Hello, regarding the GLEDOPTO Ethernet series, in fact they not only have GL-C-618WL but also 616WL, so you should not choose GLEDOPTO GL-C-618WL as the model. For specific reference: #5150

[libschmudie-so]

@Aogu181 are you sure the 616WL is compatible? I tried to flash their firmware for the 616WL to my 618WL and ethernet did not work.

[softhack007]

@libschmudie-so @Aogu181 it looks like both of you want to submit the same ethernet pin configs

Please get into direct contact with each other, and create one PR for the new ethernet PIN configuration.

Due to flash size considerations, we do not accept "aliases" for boards where the name is different, but the pin configuration is already available, maybe just with a different brand name.

[Aogu181]

@Aogu181 are you sure the 616WL is compatible? I tried to flash their firmware for the 616WL to my 618WL and ethernet did not work.你确定616WL兼容吗？我试着将他们的616WL固件flash到我的618WL，但以太网不起作用。

@Aogu181 are you sure the 616WL is compatible? I tried to flash their firmware for the 616WL to my 618WL and ethernet did not work.

I'm pretty sure the 616WL is compatible. The only difference between the 618WL and 616WL is that the 616WL has two outputs, while the 618WL has four. I've confirmed this with the engineers at GLEDOPTO. Have you tried it a few more times?

[Aogu181]

@libschmudie-so @Aogu181 it looks like both of you want to submit the same ethernet pin configs

Please get into direct contact with each other, and create one PR for the new ethernet PIN configuration.

Due to flash size considerations, we do not accept "aliases" for boards where the name is different, but the pin configuration is already available, maybe just with a different brand name.

I understand your concerns, but the GLEDOPTO GL-C-618WL is actually part of the Gledopto Ethernet series. I will submit a new PR later.