* nrf52: drop BSEC2/BME68x from the three targets nearest the flash cap
nrf52_promicro_diy_tcxo has been failing the nrf52_warm_region guard on
develop since 2026-08-05 (image ends at 0xEA918, 2328 B past the 0xEA000
warm-store cap). rak4631 and rak_wismesh_repeater_mini are ~14 KiB clear
while the nrf52 fleet drifts ~2 KiB/day, so both are close behind.
lib_ignore bsec2 + BME68x Sensor library defeats BME680Sensor's
__has_include(<bsec2.h>) gate, recovering ~46 KiB on each:
nrf52_promicro_diy_tcxo 0xEA918 (FAILED) -> 0xDF1A8, 43.6 KiB clear
rak4631 0xE6550 -> 0xDADE8, 60.0 KiB clear
rak_wismesh_repeater_mini 0xE65AC -> 0xDAE64, 59.9 KiB clear
This costs BME680/BME688 support, i.e. RAK1906 on WisBlock. It is a
temporary measure until the environmental sensor roster is opt-in per
board rather than linked into every target.
rak_wismesh_pocket inherits from env:rak4631 but has ~37 KiB clear, so it
is explicitly held at the nrf52 default and keeps BME680. Both lib_ignore
lists extend ${nrf52_base.lib_ignore} so BluetoothOTA and lvgl stay
ignored.
* nrf52: give the RAK boards BME680 back, drop their Ethernet instead
Excluding BSEC2 on rak4631 cost BME680/BME688 support, i.e. the RAK1906
WisBlock module - a common peripheral on the most popular nrf52 board. The
Ethernet stack is the better thing to lose: RAK13800 W5100S users are served
by the dedicated env:rak4631_eth_gw build, which has its own variant.h and
~163 KB clear, so the general-purpose image was carrying a networking stack
for hardware almost none of its users have.
rak_wismesh_pocket already set HAS_ETHERNET 0 for the same reason, so this
follows an existing in-tree precedent rather than inventing one.
rak4631 0xE6578 -> 0xE0D08, 35.7 KB clear (-21.6 KB)
rak_wismesh_repeater_mini -> 0xE0D58, 35.7 KB clear
rak4631_eth_gw -> 0xC1050, 163 KB clear (unchanged)
rak4631_eth_gw_dbg -> 0xC1210, 163 KB clear
That also brings rak4631 back under its declared flash budget in
bin/ram_budgets.json (766,216 vs 786,000 bytes), which develop is currently
failing - size-budget-gate is what has been ejecting PRs from the merge queue.
mqtt/ is deliberately kept: src/mqtt/MQTT.cpp carries both the networked
client (gated on HAS_NETWORKING, now 0) and the phone client-proxy path, so
dropping the directory would have removed MQTT-over-phone as well.
nrf52_promicro_diy_tcxo keeps the BSEC2 exclusion from the previous commit.
It has no Ethernet to reclaim - nrf52_base already filters mesh/eth, mesh/api
and mesh/wifi, and HAS_ETHERNET defaults to 0 - so the sensor library is the
only lever there. It goes 0xEA918 (FAILED) -> 0xDF1C0, 43.6 KB clear.
env:rak4631_eth_gw_dbg now extends env:rak4631_eth_gw rather than env:rak4631:
it already used the gateway env's build_flags and lib_deps, and only that env
still compiles mesh/eth + mesh/api.
* Address CodeRabbit review comments on PR #11363
- Condense the HAS_ETHERNET comment in rak4631/variant.h to one line
- Clarify rak4631/platformio.ini src-filter comment: Ethernet-free,
not networking-free, since MQTT is retained
- Restore custom_meshtastic_* metadata on env:rak4631_eth_gw so
env:rak4631_eth_gw_dbg (which now extends it) doesn't lose the
hw_model/display metadata it previously inherited via env:rak4631
---------
Co-authored-by: Jason P <applewiz@mac.com>
Co-authored-by: Claude <noreply@anthropic.com>
* Remove noop CANNED_MESSAGE_MODULE_ENABLE define
* Remove over-eager warning removal
* Remove unused LED_CONN
* Dead defines removal
* Rename oddball LED pin name
* Rename second oddball LED pin name
* Remove another dead define
* Just set LED_BUILTIN universally to -1, as we don't use it.
* LUD_BUILTIN workarounds
* Squash the LED_BUILTINs that sneaked in
* Don't kill valid pin derfine
I thought git would be smart enough to understand all the whitespace changes but even with all the flags I know to make it ignore theses it still blows up if there are identical changes on both sides.
I have a solution but it require creating a new commit at the merge base for each conflicting PR and merging it into develop.
I don't think blowing up all PRs is worth for now, maybe if we can coordinate this for V3 let's say.
This reverts commit 0d11331d18.
