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

[1sthandy]

What

Adds support for running a RAK4631 over PoE using the RAK13800 (W5100S) Ethernet module on a RAK19018 base, in two roles:

• PoE repeater (RAK_4631_repeater_poe, +_debug): boots reliably on the RAK19018 (Silvertel) converter. The cold-start path is shortened and CPU sleep is disabled, because dropping below the converter's hold current makes it fold back and reset. Boot-voltage protection is bypassed when battery-less on PoE.
• Ethernet companion (RAK_4631_companion_radio_eth): exposes the MeshCore companion protocol as a TCP server (default port 5000) over the W5100S, so Home Assistant connects directly to the device's IP. Uses a static IP to avoid blocking DHCP at cold start. W5100S PHY bring-up is deferred out of setup() into loop() to avoid collapsing the marginal PoE supply during the cold-start window.

New files

• src/helpers/SerialEthernetInterface.{cpp,h} — TCP transport for the companion serial-frame protocol.
• variants/rak4631/W5100SPoE.{cpp,h} — W5100S power/reset + init helper.

New PlatformIO envs

• RAK_4631_repeater_poe (+ RAK_4631_repeater_poe_debug)
• RAK_4631_companion_radio_eth

Safety / impact

All additions are guarded by WITH_W5100S_POE / WITH_ETHERNET_COMPANION, so existing RAK4631 builds are unaffected.

Testing

Tested on real hardware (RAK4631 + RAK13800 + RAK19018):

• Repeater build powers up and stays up on PoE.
• Ethernet companion build comes up at a static IP and serves the companion protocol on TCP:5000; Home Assistant (MeshCore integration) connects and receives messages/telemetry, including position from a T1000-E tracker.

[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.