If Bluefruit.begin fails, BLE OTA mode won't actually start and the board might require a reboot to reattempt.
Fixes:
- Bluefruit.begin returns false in NRF52Board.startOTAUpdate if OTA mode fails to start. User is notified of the fault through existing error message in CommonCLI and can reattempt "start ota" command.
mkdocs will only consider the first H1 (if any) and subheaders under it for the table of contents
this increases the header levels of everything below "important concepts" by 1 so that the table of contents correctly resolves them
The commented-out debug flag still referenced #1983's original macro name
(ETHERNET_DEBUG_LOGGING). SerialEthernetInterface.h now checks
ETH_DEBUG_LOGGING after the merge with our multi-client/PoE-deferred
implementation, so the comment was stale and enabling it would have done
nothing.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
#1983 landed a generic RAK4631 Ethernet base (repeater/room_server/companion
envs, single-client SerialEthernetInterface, EthernetCLI telnet CLI) and
independently added the same WB_IO2 rail-power fix we found for PoE boot.
Layer the remaining PoE-specific delta on top of it instead of duplicating:
- W5100SPoE: drop the now-redundant WB_IO2 early-ctor code (covered by
#1983's own constructor), keep only the early W5100S RST release and the
bit-bang activation/VERSIONR check.
- SerialEthernetInterface: add PoE-safe deferred bring-up (Ethernet.init/
begin() moved out of begin() into loop(), gated by an _hwReady flag, so
the disruptive PHY soft-reset + DHCP can't collapse the marginal PoE
supply at cold start) and bounded DHCP with a static-IP fallback.
- EthernetCLI: same deferral (vTaskDelay before hardware bring-up) and
bounded DHCP + static fallback for the repeater/room_server telnet path.
- platformio.ini: add RAK_4631_{repeater,room_server,companion_radio}
_ethernet_poe envs extending #1983's _ethernet envs with WITH_W5100S_POE.
Verified: all three new _poe envs build, plus the plain _ethernet envs and
non-Ethernet variants (no cross-variant breakage).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
SerialEthernetInterface 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 non-Ethernet RAK4631 builds
(repeater, room server, companion usb/ble, ...) with
"RAK13800_W5100S.h: No such file or directory", since that library is only
a dependency of the Ethernet env.
Move it into src/helpers/nrf52/ (a subdirectory the base filter does NOT
glob), matching how SerialBLEInterface is handled, and include it
explicitly only in the Ethernet env via
`+<helpers/nrf52/SerialEthernetInterface.cpp>`. Now every RAK4631 variant
builds, and only the Ethernet build pulls in the W5100S library.
DHCP is now the default for the Ethernet companion, addressing the need
for DHCP in managed/enterprise networks. It is done PoE-safely:
- deferred to loop() after the converter is latched (~6 s), so the
blocking DHCP exchange can't collapse the supply at cold start;
- bounded timeout (12 s lease / 4 s response) instead of the 60 s default;
- falls back to the static IP if no DHCP server answers, so the node is
always reachable and never reboot-loops;
- Ethernet.maintain() renews the lease.
Use a DHCP reservation on the router for a stable address. Add
-D ETH_STATIC_ONLY to opt out of DHCP and use the static IP directly.
Tested on RAK4631 + RAK13800 + RAK19018: repeated PoE-only cold starts
come up reliably with the DHCP-assigned address.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Adds support for running a RAK4631 over PoE using the RAK13800 (W5100S)
Ethernet module on a RAK19018 base, in two roles:
- PoE repeater: powers up 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: exposes the MeshCore companion protocol as a TCP
server (default port 5000) over the W5100S, so Home Assistant connects
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 (+ _debug)
- RAK_4631_companion_radio_eth
All additions are guarded by WITH_W5100S_POE / WITH_ETHERNET_COMPANION,
so existing RAK4631 builds are unaffected.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
The room server never supported RX boosted gain, while the repeater
does. Three consequences on SX1262/SX1268 boards:
- boosted gain was never applied to the radio at boot, so a room server
ran in power-saving RX mode while an identical repeater ran boosted -
a real receive-sensitivity difference with nothing pointing at it
- _prefs.rx_boosted_gain was never initialised (the prefs are memset to
0 before defaults are set), so it defaulted to off
- 'set radio.rxgain on' replied "Error: unsupported" but CommonCLI had
already written the value to prefs and saved them, so a stale setting
survived reboot and was never applied
Mirror the repeater's implementation: initialise the pref default under
the same USE_SX1262/USE_SX1268 and SX126X_RX_BOOSTED_GAIN guards, apply
it during radio init, and override setRxBoostedGain() so the CLI reports
success and takes effect.
Built Heltec_v3_room_server (SX1262) and LilyGo_T3S3_sx1276_room_server
(guards compile out cleanly).
Compile fails due to user_btn not declared in board target.
Fixes:
- Add MomentaryButton declaration for user_btn in variants/xiao_nrf52/target.cpp
- Add momentary button helper include in variants/xiao_nrf52/target.h
- Add extern linkage for MomentaryButton -> user_btn in variants/xiao_nrf52/target.h