Add RAK4631 / RAK10720 PoE + Ethernet companion support (W5100S/RAK13800) 🤖🤖

[1sthandy]

What

Adds PoE-specific support for running a RAK4631 on a RAK19018 PoE base with the RAK13800 (W5100S) Ethernet module (the RAK10720 "WisMesh Ethernet Gateway") — boots and stays up on PoE alone, with no battery and no separate power supply.

This branch is rebased onto the now-merged #1983 ("Support for RAK ethernet module"), which added the generic RAK4631 Ethernet foundation (envs, SerialEthernetInterface/EthernetCLI, MAC generation). This PR is now an additive PoE delta on top of #1983, not a parallel implementation — the plain _ethernet envs from #1983 are untouched; the PoE behavior only applies to the new opt-in envs below.

• PoE cold boot without a battery: the RAK19018 (Silvertel Ag9905MT) PoE converter needs a continuous ~125 mA+ load or it folds back and resets. On top of Support for RAK ethernet module #1983's WB_IO2 rail-power fix, this adds an early W5100S RST release + bit-bang SPI activation (so the chip is drawing full current before board.begin() returns) and a no-battery boot-voltage bypass.
• PoE-safe deferred Ethernet bring-up: the Ethernet library's own Ethernet.init()/begin() (another PHY soft-reset + blocking DHCP) is deferred ~6s, until after the converter is solidly latched, instead of running immediately in setup()/at task start — doing it immediately reliably collapsed the marginal PoE supply on our hardware.
• Bounded DHCP with a static-IP fallback, so the node always comes up somewhere even without a DHCP server.
• Multi-client support for the companion TCP interface (up to 3 simultaneous clients — e.g. Home Assistant + the phone app at the same time; the single-client model in Support for RAK ethernet module #1983 has them kick each other off the one socket).

New files

• variants/rak4631/W5100SPoE.{cpp,h} — early W5100S RST release + bit-bang SPI activation/VERSIONR check.

Changed files (additive, gated by WITH_W5100S_POE)

• variants/rak4631/RAK4631Board.cpp — no-battery boot-voltage bypass, calls into W5100SPoE.
• src/helpers/nrf52/SerialEthernetInterface.{cpp,h} — multi-client support + PoE-safe deferred bring-up, built on Support for RAK ethernet module #1983's version.
• src/helpers/nrf52/EthernetCLI.h — same deferred bring-up + bounded DHCP/static fallback for the repeater/room-server telnet CLI path.

New PlatformIO envs

Each extends the matching #1983 _ethernet env, adding -D WITH_W5100S_POE=1:

• RAK_4631_repeater_ethernet_poe
• RAK_4631_room_server_ethernet_poe
• RAK_4631_companion_radio_ethernet_poe

Dependencies

• Uses the official RAKWireless/RAK13800-W5100S library, as pulled in by Support for RAK ethernet module #1983.

Safety / impact

All additions are gated by WITH_W5100S_POE, so #1983's plain _ethernet envs and all non-Ethernet RAK4631 builds are unaffected. All RAK4631 envs verified to build cleanly (PoE envs + plain ethernet envs + non-Ethernet variants).

Testing

Tested on real hardware (RAK4631 + RAK13800 + RAK19018 — a RAK10720 gateway, UniFi USW-Lite-16-PoE):

• Cold boot on PoE only, no USB, no battery.
• DHCP bring-up (with a router reservation for a stable IP).
• Home Assistant + phone app connected simultaneously over the companion TCP interface.

RAK_4631_repeater_ethernet_poe / RAK_4631_room_server_ethernet_poe build clean but aren't yet hardware-verified on PoE — testers welcome. Prebuilt firmware for all three envs: https://github.com/1sthandy/MeshCore/releases/tag/rak10720-poe-eth-2026.07.25

[cwichura]

Is this duplicating the work in #1983 ? I believe these are both targeting the same hardware, no?

[1sthandy]

Thanks for flagging it — yes, there's real overlap with #1983 on the base W5100S Ethernet support (we even independently ended up with a similarly named SerialEthernetInterface), so these shouldn't both land as-is.

The part that's genuinely additive in this PR is PoE support for the RAK19018 (Silvertel) module, which #1983 doesn't cover:

• W5100S power/reset sequencing on the PoE base,
• disabling CPU sleep and the boot-voltage lockout (both required to keep the PoE converter above its hold current, otherwise it folds back and reboot-loops),
• deferring the W5100S PHY soft-reset out of setup() into loop() so it doesn't collapse the marginal supply during cold start,
• and using a static IP instead of DHCP, because blocking DHCP reboot-loops the device on PoE cold start.

The whole point of the PoE work is that it makes the node fully self-sufficient over a single cable: the device draws both data and power from the LAN, so it needs no separate power supply at all. That's what makes it practical to deploy as an Ethernet gateway where running a second power lead isn't convenient (ceiling, mast, remote closet, outdoor enclosure, etc.) — which is exactly how my device runs.

If #1983 is the preferred Ethernet foundation, I'm happy to rebase this down to just the PoE-specific delta on top of it (or close this and re-submit the PoE bits as a follow-up to #1983). Which would you prefer?

[cwichura]

For the record, I have the RAK "MQTT Ethernet Gateway" kit. With just normal MeshCore firmware, the PoE hat DOES power the device, even though nothing is explicitly initialized. However, for it to work reliably, I had to add a battery. I am using an enterprise switch, and the board at time draws so little power, the switch thinks the device is gone and powers down the port. This is apparently quite commonly reported on the Internet from some Google searches I did when I first got it, and also happens with Meshtastic, for which there is full Ethernet support implemented. With battery attached, the board never dies, as the battery keeps it alive when the switch turns the port power off, and then when its recharging the battery, it pulls enough watts for the power power to re-activate. (The alternative is to use a passive 48v PoE injector, but I refuse to do that.)

I don't really care which PR moves forward. I was just pointing out we have two implementations for the mostly the same thing. TO BE CLEAR -- I am not part of the dev team. So not part of the decision for which goes forward.

My real desire is whichever moves forward, work is done to support MESH_PACKET_LOGGING (to enable use with mctomqtt) and/or the KISS firmware variant is supported (to enable use with pyMC).

I will add that I think DHCP MUST be supported. Requiring static IP only would not work for people with enterprise setups where security is configured.

[enigmaspb]

I'm planning a repeater with a network, and I think that commit ( http://github.com/meshcore-dev/MeshCore/pull/1983 ) is more interesting.

I would ask you, if it is not difficult for you, to transfer your logic for working with "POE" in addition to that code.

[1sthandy]

Update: DHCP is now implemented and is the default (just pushed).

Since the static-IP-only concern was the main blocker, I worked out a PoE-safe way to do DHCP:

• DHCP runs deferred in loop() after the PoE converter is latched (~6 s), so the blocking exchange can't collapse the supply at cold start — that was the original reason for going static-only.
• Bounded timeout (12 s lease / 4 s response), with a static fallback if no DHCP server answers, so the node is always reachable and never reboot-loops.
• Ethernet.maintain() renews the lease.
• -D ETH_STATIC_ONLY opts out of DHCP for anyone who wants a fixed address without a server.

Tested on RAK4631 + RAK13800 + RAK19018: repeated PoE-only cold starts (no USB) come up reliably with the DHCP-assigned address, and a DHCP reservation on the router gives a stable IP for Home Assistant — which covers the managed/enterprise case.

So this PR now provides DHCP and the PoE-specific handling. I'm still happy to rebase the PoE bits on top of #1983 if that's the preferred Ethernet foundation — just let me know which direction the maintainers want.

[rgregg]

I've been trying to get my change merged in for a while -- got reviewed by a couple of maintainers but then radio silence. Identifying and fixing the POE issues is a great value add, that was my end goal but I was starting small to enable one system at a time.

I'd love to see a solution get merged here -- either mine or yours, it doesn't really matter to me as long as we have working ETH support for all three firmware types.

[megan-starr9]

really eagerly awaiting this, have been watching @rgregg 's PR for a long while now to see if it could finally be merged. POE/tcp connectivity is a pretty fundamental offering of the 4631 and not having it available removes most of the utility in using these nodes.

If I could build the image myself and use it I would! But I haven't been able to get the process working locally since platformio isn't something I'm familiar with. If one of these could be integrated as at least an option on the flasher, even with a "beta" disclaimer, that would be incredible

[enigmaspb]

I also could not build the firmware with these changes.
It seems to me (I'm not a programmer) that there is a problem in the use included library RAK13800-W5100S

Firstly, It is not registered correctly in platformio.ini
Secondly, A fork is used instead of the original https://github.com/RAKWireless/RAK13800-W5100S

I assembled the firmware by registering the library at the end of section [rak4631] in lib_deps = .

lib_deps =
  ${nrf52_base.lib_deps}
  ${sensor_base.lib_deps}
  adafruit/Adafruit SSD1306 @ ^2.5.13
  sparkfun/SparkFun u-blox GNSS Arduino Library@^2.2.27
  densaugeo/base64 @ ~1.4.0
  https://github.com/RAKWireless/RAK13800-W5100S.git

And I’m somehow afraid to test the firmware in this form .

Ps - Also in #1983 - build&work no problem

[mathisono]

FYI I have built firmware based on your PR.
#2855

Ethernet Companion target to the upstream MeshCore PR #2679 style implementation:

WITH_ETHERNET_COMPANION=1
SerialEthernetInterface multi-client TCP transport
server->accept() socket ownership
RAK13800 / W5100S Ethernet over TCP port 4403
DHCP first, with static fallback
static fallback IP: 192.168.3.55
gateway fallback: 192.168.3.3
subnet fallback: 255.255.255.0
designed for Crow's MeshCore TCP API backend

I loaded it last night. Confirmed that it worked. I've left the device on to see if it's stable over time, but you should be able to load my firmware build in order to confirm. I will recompair if there's any difference between your PR and the fw I built.

[mathisono]

I'll have to see if I see the same Poe power off issue you've noted above, but I'm using a ubiquity edge switch, I will continue to monitor for that bug.

Is there any other functionality missing that we need to add for this board type?

[1sthandy]

@enigmaspb thanks for the detailed report — you were right about the library. I've switched the dependency from the Meshtastic fork to the official RAKWireless/RAK13800-W5100S, pinned to a commit for reproducibility.

It exposes the same RAK13800_W5100S.h header and the exact API this PR uses — init(SPIClass&, cs) (needed because the W5100S runs on its own SPI peripheral, separate from the LoRa radio), EthernetServer::accept(), and begin(mac, timeout, responseTimeout) — so no source changes were needed and the resulting firmware is byte-for-byte identical in size.

Verified end-to-end:

• clean build from a freshly wiped .pio (fresh library clone) succeeds,
• flashed to hardware (RAK4631 + RAK13800 + RAK19018), boots PoE-only and comes up over Ethernet with a DHCP address.

Could you pull the latest and try the build again? It should resolve the fork/registration issue you hit. Thanks for pushing on this — using the official library instead of a third-party fork is clearly the right call for upstream.

[1sthandy]

@rgregg appreciate the supportive take — and likewise, I mainly care that working Ethernet lands for all three firmware types, whether that's your PR, this one, or a combination of the two.

Right now I've just switched this PR to the official RAKWireless library (the Meshtastic fork was causing build failures for a couple of people), so I'd like to give @enigmaspb and the others a chance to re-confirm the build works before taking any bigger steps.

Once that's confirmed — and if a maintainer can signal which Ethernet foundation they'd prefer to build on — I'm very happy to align the PoE handling on top of it. The PoE bits (power/reset sequencing, no-sleep, boot-voltage bypass, deferred bring-up) are largely independent of the transport layer, so they should port cleanly onto whichever base moves forward.

A short steer from a maintainer on the preferred direction would really help get this over the line after the long wait.

[enigmaspb]

@1sthandy I tested the build firmware.
Got fresh code from github, switched to this PR and ran
./build.sh build-matching-firmwares RAK_4631
All builds failed, only one success RAK_4631_companion_radio_eth

All build errors:

In the file included from src/helpers/SerialEthernetInterface.cpp:1:0:
src/helpers/SerialEthernetInterface.h:4:10: fatal error: RAK13800_W5100S.h: No such file or directory.

My thoughts (I don't program it)
You load the RAK13800_W5100S.h library only for RAK_4631_companion_radio_eth in Platformio.ini
If you add to the initial section [rak4631]
in end of lib_deps=
https://github.com/RAKWireless/RAK13800-W5100S.git#a48de4b1599392818192ceb76947edb5855e1b2f
Then everything is going ok , all variants build success .

PS - A small question, you don’t know, will the RS232 bridge work with the network? and what will it be Serial1 or Serial2 ?

[1sthandy]

@enigmaspb great catch, and thank you for the exact error output — that pinpointed the real bug (it wasn't the library URL after all).

Root cause: SerialEthernetInterface.{cpp,h} lived in src/helpers/, which the base build_src_filter compiles for every variant via +<helpers/*.cpp>. Its #include <RAK13800_W5100S.h> then broke all the non-Ethernet RAK4631 builds, because that library is only a dependency of the Ethernet env.

Your workaround (adding the lib to the global [rak4631] lib_deps) works, but it pulls the Ethernet library into every RAK4631 build. The cleaner fix — and the one I just pushed — is to move the file into src/helpers/nrf52/, a subdirectory the base filter does not glob, and include it explicitly only in the Ethernet env (+<helpers/nrf52/SerialEthernetInterface.cpp>). This mirrors how SerialBLEInterface is handled (and matches where #1983 puts its version too).

Verified locally: RAK_4631_repeater, RAK_4631_companion_radio_usb, and RAK_4631_companion_radio_eth all build now, and only the Ethernet build pulls in the W5100S library. Could you pull the latest and run build-matching-firmwares RAK_4631 again?

---

On your RS232-bridge question: there's no hardware conflict — the RS232 bridge uses a UART (Serial1/Serial2 = nRF52 UARTE), while the W5100S uses SPI, so they're independent peripherals and can coexist electrically. Either Serial1 or Serial2 is fine from the Ethernet side (neither touches the SPI pins); which one you pick just depends on which WB slot the RS232 hardware is wired to.

The catch is at the firmware level: the RS232 bridge currently lives in the simple_repeater example, while this PR's Ethernet support is in companion_radio. So "RS232 bridge + Ethernet in one build" isn't a drop-in today — it would need the bridge wired into a network-capable firmware (or Ethernet added to the repeater, which is closer to what #1983 does for the repeater/room-server examples). Happy to look into a combined build if there's interest once the ETH direction is settled.

[enigmaspb]

Good news, I'm glad I could help and thanks for the explanation about the bridge.
I have plans for repeaters with an 868-433 bridge with POE power.
While I'm testing 868 on the table, and waiting for the 433 modules to arrive
In dreams, of course, the possibility of a bridge across the network, but RS232 is not a problem either.

PS -

By the way, another question, is it possible to make firmware with control both over the network and via BLE?
For example, if such control is not possible at the same time, then if the firmware has not received the IP, then turn on the BLE

[enigmaspb]

And yes, I confirm that the build-matching-firmwares RAK_4631 build was successful

[1sthandy]

Thanks for confirming the full build-matching-firmwares RAK_4631 build passes now — much appreciated, and glad the report helped pin it down.

On controlling over both network and BLE: good question, and there are two cases:

• Both at the same time — not possible as the companion is structured today: MyMesh binds a single interface (_serial), chosen at compile time. Doing true simultaneous BLE + TCP would need a small core change so the companion can hold several interfaces (fan out writes, poll all of them for reads). That's a maintainer-owned change to companion_radio, so I'd keep it out of this PR.

• BLE as a fallback when there's no IP — this is quite feasible and actually fits the current architecture nicely. The BLE softdevice is already present in the Ethernet build (it uses the same s140 ldscript), and the network bring-up is already deferred into loop(). So it could decide at runtime: if DHCP/link comes up, bind the Ethernet interface; otherwise start BLE and bind that instead. Since only one interface is bound, no core refactor is needed — just build the BLE interface into the Ethernet env and choose at bring-up.

I'd treat the fallback as a nice follow-up rather than expanding this PR, so we can keep this one focused and mergeable — but it's a clean, self-contained addition when the time comes.

Your 868↔433 bridge with PoE sounds like a great use case. Good luck with the 433 modules — happy to help think through the combined build when you're at that stage.

[enigmaspb]

Thanks again for your detailed answers.

Regarding BLE, I am used to preparing reserve options in case of failure of any element of the system, and therefore I consider the situation of network failure and the possibility of control via BLE as a reserve.
In my opinion, detailed functionality can be considered after network support is added to the main branch.

about assembling the bridge - the most difficult thing was to correctly distribute the modules on the base board, as it turned out this is not a trivial task.
RTС, BME, GPS and network have slot dependencies on the base board.

[1sthandy]

Fully agree — let's revisit the BLE-fallback once network support is in main. And thanks for the note on the base-board slot/bus dependencies (RTC, BME, GPS, Ethernet); that's exactly the kind of practical gotcha worth capturing in deployment docs later. Appreciate all the testing and feedback on this PR.

[1sthandy]

For anyone who wants to try this without building locally, I've put pre-built EU868 binaries on my fork's releases:

👉 https://github.com/1sthandy/MeshCore/releases/tag/rak10720-poe-eth-2026.07.04

• RAK10720 / RAK4631 Ethernet companion (Home Assistant over PoE, DHCP)
• RAK4631 PoE repeater
• RAK4631 USB companion

Each comes as a .uf2 for drag-and-drop flashing (double-tap reset → drop the file on the bootloader drive) plus a .zip DFU package. Unofficial/beta, built from this PR (8efd1fc8), flash at your own risk. Note these default to 868 MHz — other regions would need a rebuild with the matching LORA_FREQ.

[metrafonic]

@1sthandy i tried out the ethernet companion firmware. Seems to work for a while and then the device seems to freeze. Not stable

[1sthandy]

@metrafonic
Can you explain a little bit more? A have running this setting more than 2 month.

[metrafonic]

@1sthandy Its a bit hard to tell what is wrong. It suddenly stops responding to requests over the network. No ping etc. I am running https://github.com/jkingsman/Remote-Terminal-for-MeshCore against the node. The rak drop in replaced a HeltecV4.

Running the eth module with poe.

[enigmaspb]

@1sthandy #1983 Merged into dev !
Please add you code for full POE support .

[1sthandy]

@1sthandy #1983 Merged into dev ! Please add you code for full POE support .

You must wait one week, i am Not at home for now.

Greetings

[metrafonic]

@enigmaspb #1983 works out of the box on this eth adapter with or without the poe module. I dont understand why there is meant to be code for a poe version. I have the #1983 version running stable on my eth+poe rak4631

[1sthandy]

Rebased onto the merged #1983 foundation (commit 108bced3) — this branch is now #1983 + a small additive PoE delta, rather than a parallel implementation. Only affects new opt-in envs; the plain _ethernet envs from #1983 are untouched.

What the PoE delta adds on top of #1983:

• Early W5100S RST release + a bit-bang SPI activation, so the chip is drawing its full operating current before board.begin() returns — needed in addition to Support for RAK ethernet module #1983's WB_IO2 rail-power fix (that alone wasn't enough to reliably latch the PoE converter on our hardware, see below).
• No-battery boot-voltage bypass (voltage_bootlock).
• PoE-safe deferred Ethernet bring-up: the library's own Ethernet.init()/begin() (another PHY soft-reset + blocking DHCP) is deferred ~6s, until after the converter is solidly latched, instead of running immediately in setup()/at task start.
• Bounded DHCP with a static-IP fallback, so the node always comes up somewhere even without a DHCP server.
• Multi-client support for the companion TCP interface (up to 3 simultaneous clients — e.g. Home Assistant + the phone app at the same time).

New envs (all extend the matching #1983 _ethernet env, just add -D WITH_W5100S_POE=1):

• RAK_4631_repeater_ethernet_poe
• RAK_4631_room_server_ethernet_poe
• RAK_4631_companion_radio_ethernet_poe

Tested on hardware (RAK10720: RAK4631 + RAK13800/W5100S + RAK19018, UniFi USW-Lite-16-PoE):

• Cold boot on PoE only, no USB, no battery ✅
• DHCP bring-up ✅
• Home Assistant + phone app connected simultaneously via the companion TCP interface ✅

Not yet tested on hardware: RAK_4631_repeater_ethernet_poe / RAK_4631_room_server_ethernet_poe (they build clean, just haven't been flashed to real PoE hardware yet) — testers welcome.

@metrafonic re: the freeze you saw — that was on an earlier iteration of this branch (before this rebase), so if you get a chance to retest RAK_4631_companion_radio_ethernet_poe from the current branch tip, that'd help narrow down whether it's still reproducible. And to your point about #1983 working fine standalone with PoE on your setup: our cold-start finding (RAK19018/Silvertel converter needs ~125mA+ continuous load or it foldback-resets) was specific to our particular PoE switch/injector being fairly marginal — sounds like your PSU/switch has more headroom, so #1983 alone is enough there. The PoE delta here is opt-in (separate envs) specifically for boards on tighter PoE budgets.

[1sthandy]

Prebuilt firmware for testers who don't want to build locally: https://github.com/1sthandy/MeshCore/releases/tag/rak10720-poe-eth-2026.07.25

Built from the current branch tip (108bced3), EU868. .uf2 for drag-drop onto the bootloader drive, .zip for nrfutil/adafruit-nrfutil dfu. Covers all three PoE envs (repeater, room server, companion).

[enigmaspb]

Great news!
Thank you so much for your input and support 4631 ethernet .
Special thanks for the finished firmware for faster testing )