feat: Add Ethernet runtime configuration CLI + fix PIN_USER_BTN_ANA compilation

[ndrpri]

Overview

Adds runtime Ethernet configuration commands via CLI, allowing dynamic IP/gateway/subnet/DNS settings with SPIFFS persistence. Also includes TCP console for remote management and fixes for analog button compilation on ESP32-S3.

What's Included

1. Ethernet Runtime Configuration

• New CLI commands: get/set ip, get/set gw, get/set subnet, get/set dns
• Settings persist to SPIFFS — survive reboot without recompiling
• Dynamic reconfiguration via reconfigureEthernet() method
• Fallback to DHCP if no static IP configured in memory
• Updated cli_commands.md with full documentation

2. TCP Console Enhancements

• Fixed TCP_CONSOLE_PORT conditional compilation (removed unnecessary ESP32 guard)
• Now uses runtime NodePrefs password instead of compile-time ADMIN_PASSWORD
• Allows password changes via set password command without reflashing

3. PIN_USER_BTN_ANA Fixes

• Added #ifdef PIN_USER_BTN_ANA guards in target.cpp (both SX1262/SX1276)
• Added PIN_USER_BTN_ANA=7 to platformio.ini build flags
• Removed abs() from millis() comparison (fixes unsigned overflow on ESP32-S3)
• Added auto declaration to ev variable in analog button block
• Ensures portability across boards with/without analog button support

4. Documentation

• Added complete Ethernet section to cli_commands.md
• Documented get bridge.type command (was missing)
• Updated Navigation menu

Files Changed

• src/helpers/CommonCLI.cpp/h — Ethernet CLI commands + helper functions
• src/MeshCore.h — reconfigureEthernet() virtual method
• src/helpers/esp32/TEthEliteBoard.cpp — implementation
• examples/simple_repeater/main.cpp — call reconfigureEthernet() after boot
• examples/simple_room_server/main.cpp — same
• examples/companion_radio/ui-new/UITask.cpp — fix analog button
• variants/lilygo_t_eth_elite_sx1262/platformio.ini — add build flags
• variants/lilygo_t_eth_elite_sx1276/platformio.ini — add build flags
• docs/cli_commands.md — documentation

Dependencies

• Depends on PR Feature/lilygo t eth elite #2196 (LilyGo T-ETH-Elite hardware support)
  • This PR includes all commits from Feature/lilygo t eth elite #2196 since it wasn't merged yet
  • Once Feature/lilygo t eth elite #2196 is merged, this can be rebased for cleaner history
• Supersedes PR Add TCP console for remote management via telnet/netcat (ESP32) #2197 (TCPConsole is now included with runtime config)

Reviewed by

• @Inxsamox86 (thanks for feedback on PIN_USER_BTN_ANA and UITask.cpp compilation)

Testing

• ✅ Ethernet config persistence on SPIFFS
• ✅ Runtime IP reconfiguration with reboot
• ✅ OTA update uses correct IP after reconfiguration
• ✅ SX1262 and SX1276 variants compile without errors
• ✅ Analog button compilation on ESP32-S3

Usage Example

# Via telnet (TCP console)
telnet 192.168.254.21 4242

# Configure Ethernet at runtime
set ip 192.168.254.30
set gw 192.168.1.1
set subnet 255.255.255.0
set dns 8.8.8.8

# Verify settings
get ip
get gw

# Reboot to apply
reboot

# After reboot, device uses new static IP

Ethernet Configuration Hierarchy

The device follows this priority order when initializing Ethernet:

1. If SPIFFS has valid static IP (!=0.0.0.0)

-D USE_ETHERNET
-D TCP_CONSOLE_PORT=4242

→ Device boots with IP from SPIFFS (previously saved via set ip command)

2. If SPIFFS has 0.0.0.0 BUT compile-time flags are set

-D USE_ETHERNET
-D ETH_STATIC_IP=192,168,254,20
-D ETH_GATEWAY=192,168,254,254
-D ETH_SUBNET=255,255,255,0
-D ETH_DNS=8,8,8,8
-D TCP_CONSOLE_PORT=4242

→ Device boots with static IP from platformio.ini

3. If SPIFFS has 0.0.0.0 AND no compile-time flags

-D USE_ETHERNET
-D TCP_CONSOLE_PORT=4242

→ Device boots with DHCP (IP assigned by router)

Once booted, you can reconfigure at runtime via TCP console:

set ip 192.168.254.30
set gw 192.168.1.1
set subnet 255.255.255.0
set dns 8.8.8.8
reboot

Settings persist to SPIFFS and survive across reboots!

Notes

• Merge conflicts expected due to Feature/lilygo t eth elite #2196 not yet merged — can be resolved during review
• All changes are backward compatible
• Ethernet config is opt-in via USE_ETHERNET build flag
• Works seamlessly with existing TCP console and OTA features

[petrkr]

This seems to be clauded by that known structures of code.

Also it badly use some ETHClass2 library instead of standard Espressif's ESP-IDF SDK ETH.begin()

That also caused claude (or other AI) to implement while TCP stuff around it again, but if native ESP SDK will be used instead, ir will work out-of-box with existing 'wifiserial' or 'wifi client' and no changes would be needed.

Only maybe rename Wifi to Network as it would not be only wifi but also Ethernet or even LTE.

Also this implementation support only one SPI W5500 and no else, like DM902x SPI ethernet or LAN7820 RMII

If you want some inspiration, take look to my fork, where I trying make it more abstract, but for now I have it just for my one board, so it does not abuse other code yet.

https://github.com/petrkr/MeshCore/commits/octopusboard/

[ndrpri]

@petrkr Thank you for the detailed feedback!

Just to clarify a few points:

1. W5500 is not arbitrary — It's the chip that comes integrated on the official LilyGo T-ETH-Elite board (hardware from LilyGo, not custom). Our PR supports the board as shipped.

2. Code quality vs. origin — Whether code is written by a human, AI, or hybrid doesn't determine correctness. What matters is: Does it work? Is it tested? Is it secure? We've done thorough testing and security review (PR includes vulnerability fixes).

3. Architecture is a future conversation — Your point about a more generic "Network" abstraction supporting multiple Ethernet chips (DM902x, LAN7820, native ESP-IDF) is valid and interesting for future enhancements. But this PR solves a concrete problem (remote Ethernet management for T-ETH-Elite nodes) with the current architecture.

4. We welcome reference material — Your fork exploring a more abstract approach sounds valuable. We'd be interested to see it as a reference for future work.

This PR stands on its own merits: it works, solves a real problem, and follows the existing codebase patterns.

Looking forward to maintainer's decision!

[petrkr]

Do not use AI to generate response to me

1. is not true
   that chip is ONLY on this board and your claude put it to basic implementations (see for amount of changed files outside of board variant)...

2. also it is not true. AI can generate good code only if human is senior programmer and understand results... From this codebase I do not think about it... Do you know it is secure? maybe yes,, does it works ? I guess so,, but is it expandable ? Not.

3. yes, thank you for this reponse, but first you need to generic class and implement first device, not opposite, because for example now it will do more mess than useless code by using workarounds.. and we are back at AI with unexperienced developer vs experienced human with AI who will 10 times tell to AI "do not do it like that way"

4. ok... just if you will use something from this branch, please use credits if you will use something from it... it is not rule, it is polite.

[ndrpri]

@petrkr

To clarify: I use AI for translation to ensure clarity in English,
not to generate responses. The concepts and decisions are mine.

Your architectural feedback is valid and noted. I'd prefer we focus
on the technical merits of the PR rather than how responses are formulated.

If you'd like to discuss design improvements or share your fork as reference,
I'm open to that conversation.

[ndrpri]

@petrkr

One more thing: If you or anyone else can do it better, I'll be the first
to be happy about it. My goal is to support these boards and enable remote
management. If someone else achieves that better, they're absolutely welcome.

My contribution is meant to help the project. If it's not needed, just say so
and I'll use it privately and wait for someone to do better.

What matters is that the problem gets solved — not who solves it.

[petrkr]

@petrkr

One more thing: If you or anyone else can do it better, I'll be the first to be happy about it. My goal is to support these boards and enable remote management. If someone else achieves that better, they're absolutely welcome.

My contribution is meant to help the project. If it's not needed, just say so and I'll use it privately and wait for someone to do better.

What matters is that the problem gets solved — not who solves it.

my also,

that is why there exist my fork repository
but I also want to make it somehow consistent with project standards and workflow... do not want just hard-coded it into like this and make it then hard to maintain.. That is that difference between human with AI assisted programmer vs fully claude/codex/gemini/nameit vibed code which only want to solve actual problem without any future problems.

So yes, it solved that problem,.. But now @liamcottle will have lot of headache about maintain that bundle of "ifdef's" there.

My repo is also hard-coded to one board.. but with few difference

1. it is only in variant mode (in target.h and OctopusLAN.h/cpp) - you put it to src/helpers instead to variant
2. it does not changed any outside code

[ndrpri]

@petrkr

Since you clearly have the expertise and a better approach,
I'd be happy if you'd contribute those improvements directly to MeshCore.
The community would immediately benefit from your architecture.

If you don't have the time or inclination, we'll wait for someone else
to implement it better. Either way, the project will improve.

Thanks for the feedback — looking forward to your contribution!

[petrkr]

I am trying to do that..

Today I spent 12 hours with debugging how to use SDK 3.x on old hardware, because i take 21kB more memory so there is compromise about keep it old or have less message queue (256-->100)

check pre requests #2265 and #2264

after those prerequests (if any) will be merged, then will be possible to use SDK 3.x..

for Companion radio (where is problem with RAM) you do not really need 3.x SDK too much as it does not need Ethernet (or if even it will have it, you can use less offline message queue as it will be mostly online).

for router those static RAM are not there, so for that is not problem at all.

After those will be merged, new doors will open...

No workarounds with some bullshit old Arudino libraries. but usage of todays and updated libraries directly from chip maintainer/manufacturer

[ndrpri]

@petrkr

Understood! I see you're working on SDK 3.x integration as foundation.
That's a much cleaner approach than workarounds with older libraries.

My PR solves the immediate problem for current users with the existing codebase.
The TCP Console and Ethernet commands are global MeshCore features
(not T-ETH-Elite specific) — they belong in src/helpers so any board
with Ethernet can use them, not just one variant.

When your PRs are merged and SDK 3.x foundation is ready, those improvements
can definitely be integrated on top of this.

Looking forward to those updates. Let me know if there's anything I can
help with in the meantime.

[ndrpri]

@petrkr

One clarification: The T-ETH-Elite board uses W5500 (SPI), which requires
ETHClass2. Espressif SDK natively supports only built-in RMII Ethernet
on the ESP32 chip itself.

This isn't a design choice — it's a hardware requirement of the board.
Meshtastic uses the same approach for the same hardware.

When you implement SDK 3.x support for boards with native RMII Ethernet,
that will be an improvement. But for T-ETH-Elite, ETHClass2 is necessary.

[petrkr]

@petrkr

One clarification: The T-ETH-Elite board uses W5500 (SPI), which requires ETHClass2. Espressif SDK natively supports only built-in RMII Ethernet on the ESP32 chip itself.

This isn't a design choice — it's a hardware requirement of the board. Meshtastic uses the same approach for the same hardware.

When you implement SDK 3.x support for boards with native RMII Ethernet, that will be an improvement. But for T-ETH-Elite, ETHClass2 is necessary.

Again claude is wrong.

Espressif SDK natively supports SPI Ethernets for 4 years already...

Again proof you are not programmer and only vibe coder,... check documentation

https://docs.espressif.com/projects/esp-idf/en/v5.0/esp32/api-reference/network/esp_eth.html#spi-ethernet-module