The per-board libs (M5Stack/M5StickC/M5StickC-Plus/M5Tough) don't build on
Arduino core 3.x, which kept the five M5 BLE envs pinned to espressif32@6.1.0.
Port board support to M5Unified + M5GFX so they run ${com.esp32_platform} like
the rest of the tree.
- environments.ini: 5 M5 envs -> modern platform + m5unified. m5stick-c uses the
pico32 variant (m5stick_c variant absent upstream) and no_coredump partitions
(M5Unified overflows min_spiffs).
- boardM5.cpp / config_M5.h: single <M5Unified.h>; M5.Lcd aliases M5.Display;
unified brightness/sleep/wake.
- main.cpp / mqttDiscovery.cpp: battery telemetry via M5.Power; AXP192-only
Vin/VBus/temp fields dropped (no portable equivalent).
All five M5 envs build; M5Stack Core hardware-verified.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
On the platform we ship (pioarduino 55.03.39 / arduino-esp32 3.3.9) the pinned
SmartRC-CC1101-Driver-Lib v2.5.7 does not work with the CC1101 at all. Core 3.x's
peripheral manager owns SCK/MISO/MOSI once SPI.begin() has run, so the driver's
digitalWrite() calls on those pins become silent no-ops, and it starts and stops
the SPI bus around every single register access (LSatan/SmartRC-CC1101-Driver-Lib#176).
Bench result on an ESP32 DevKit + CC1101 running esp32dev-pilight-cc1101: setup
hangs in the driver's unbounded `while(digitalRead(MISO_PIN));` before any C1101
log line is emitted, and TG1WDT reboots the board in a loop. The same build on
espressif32@6.8.1 (core 2.0.17) initialises normally, so this is the core, not
the wiring. Every ZradioCC1101 ESP32 environment is affected: Pilight, RF, RF2
and Somfy. The RTL_433 CC1101 path goes through RadioLib and is unaffected.
V3.0.x re-engineered the SPI core for ESP32: gpio_get_level() with a timeout
instead of the unbounded digitalRead() wait, SPI.begin() once instead of per
transaction, and no digitalWrite() on peripheral-owned pins. It also moved
SPI.begin() out of getCC1101() and into Init(), so the connection probe has to
run after Init() rather than before it — reported in #2348.
Both changes are needed together: the reorder alone does not help on core 3.x,
and V3 cannot work without it.
Verified on the bench, core 3.3.9, esp32dev-pilight-cc1101:
N: C1101 SPI connection OK on attempt 1
N: C1101 tuned RX to 433.92 MHz
plus a live round trip — an arctech_switch frame published to MQTTtoPilight was
transmitted and decoded back by the board's own receiver on PilighttoMQTT.
Note for review: this bumps the pin for the ESP8266 CC1101 environments too.
They are not affected by the core 3.x breakage and V3 is untested there, so the
pin may be worth splitting per environment before this lands.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
0.1.7 shipped esp32c3 flags with no -march at all, so every ESP32-C2/C3 build
fell back to the compiler default (rv32imafdc) and emitted atomic and
hardware-FP instructions the core does not implement. The firmware panicked
with "Illegal instruction" during C++ static init — on the first
std::shared_ptr refcount, inside the Arduino core's global SPIFFS constructor —
so the board boot-looped before printing a single line of OMG output. That is
issue #2336: esp32c3-dev-c2-ble dev builds boot-loop while 1.8.1 (built on
arduino-esp32 2.x, which passed -march=rv32imc explicitly) is fine.
The flag was lost in packaging, not in the compiler: ESP-IDF >= 5.5.2 moved the
toolchain base flags into @response files and the lib-builder's flag extraction
silently dropped them. The precompiled libs were always correct RV32IMC code.
0.1.8 restores -march across c_flags/cpp_flags/S_flags/ld_flags and
pioarduino-build.py, and fails the lib build if a target's ISA flag ever goes
missing again (theengs/esp32-arduino-lib-builder#9).
Xtensa targets were never affected — each core has its own GCC driver whose
default multilib already matches — but they are rebuilt from the same bundle,
so esp32/esp32s3 want a smoke test alongside the C3.
Bench-verified on an ESP32-C3 rev v0.4: boot-loops on 0.1.7 (30 panics in 20 s,
MTVAL 0x06f7202f), boots and decodes BLE on 0.1.8 with no project-level flags.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The 0.1.7 bundle enables MBEDTLS_DYNAMIC_BUFFER (dynamic TX/RX TLS record
buffers) by disabling the unused DTLS proto that was gating it. mbedTLS now
sizes the ~32 KB record buffers per-record and frees them between records
instead of holding them for the whole session lifetime.
On no-PSRAM ESP32 (e.g. the Theengs Plug) this is the difference between MQTT
TLS (8883) being viable or not: steady-state free heap goes from ~36 KB to
~71 KB (minmem ~18 KB -> ~30 KB), the boot HTTPS update-check and the HA
discovery burst no longer OOM/crash-loop, and flash drops ~19 KB from removing
the DTLS code. Boards with PSRAM (Theengs Bridge) are unaffected.
Bundle: theengs/esp32-arduino-lib-builder 0.1.6 -> 0.1.7 (libs-only rebuild,
same IDF v5.5.4 / arduino-esp32 pin; no platform-espressif32 bump).
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The esp32_platform 55.03.39 bump (#2329) ships Arduino-ESP32 core >=3.3.7,
whose NimBLE integration enables mesh scan-filtering. NimBLE-Arduino 2.3.2
(pinned since 2025-06-28) handles this incorrectly and stops reporting
advertisements on scan restart, so continuously-scanning gateways (e.g. the
Theengs Bridge) decode nothing.
Upstream fix: h2zero/NimBLE-Arduino 98548470f "[Bugfix] Scan duplicate filter
not resetting on scan restart" (released in 2.3.9). Bumping to the latest 2.5.0
also picks up the Arduino 3.3.7 "controller invalid state" init fix (2.3.8/2.3.9)
and a scan-response timer for long-duration scans.
HIL-validated on a Theengs Bridge v11 with esp32_platform 55.03.39:
- NimBLE 2.3.2: BLE decode 0/3
- NimBLE 2.5.0: BLE decode 3/3, reachability 2/2, builds clean
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* esp32_platform: update to 55.03.39
## Summary
- Add support for Python 3.14
- Improve ESP32 platform and framework compatibility.
- Update board support and toolchain integrations.
- Fix stability and hardware-specific issues across supported ESP32 targets.
- Release notes:
- [55.03.39](https://github.com/pioarduino/platform-espressif32/releases/tag/55.03.39)
- [55.03.38](https://github.com/pioarduino/platform-espressif32/releases/tag/55.03.38)
- [55.03.37](https://github.com/pioarduino/platform-espressif32/releases/tag/55.03.37)
- [55.03.36](https://github.com/pioarduino/platform-espressif32/releases/tag/55.03.36)
- [55.03.35](https://github.com/pioarduino/platform-espressif32/releases/tag/55.03.35)
- [55.03.34](https://github.com/pioarduino/platform-espressif32/releases/tag/55.03.34)
* update build to use python 3.14 with platformio 6.1.19
* Update esp32-arduino-lib-builder to v1.5
* [CI] Fix call8 link overflow on large Xtensa builds (IDF 5.5.4)
The 55.03.39 / IDF 5.5.4 bump enlarges the precompiled libs enough that
large Xtensa images (esp32 / esp32s3) overflow the call8 reach and fail to
link with "dangerous relocation: call8: call target out of range".
-mlongcalls (which makes calls linker-relaxable) is injected by
esp32-arduino-libs into the framework compile but NOT into lib_deps
(NimBLE-Arduino, ArduinoJson) or project sources.
Add a project pre: extra_script (scripts/add_mlongcalls.py) that applies
-mlongcalls to CCFLAGS/ASFLAGS, gated on the Xtensa MCUs (RISC-V c3 has no
call8 and rejects the flag). Wired into [env]; the four esp32dev-*pilight*
envs that set their own extra_scripts list it explicitly too, since
PlatformIO replaces rather than merges extra_scripts.
Also bump esp32-arduino-libs 0.1.5 -> 0.1.6, which restores the
framework-side -mdisable-hardware-atomics / -fno-builtin-* flags that 0.1.5
dropped under IDF 5.5.4 (separate from the lib_deps call8 issue).
Verified clean (0 call8): esp32dev-all-test, esp32dev-ble, theengs-bridge,
theengs-plug, esp32dev-pilight (+cc1101); esp32c3 unaffected.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Florian <florian@theengs.io>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Updates the NorthernMan54/rtl_433_ESP dependency from v0.5.0 to v0.5.1,
which guards vdata_make() against strdup(NULL) for DATA_FORMAT.
Co-authored-by: Claude <noreply@anthropic.com>
Bumps the precompiled framework-arduinoespressif32-libs bundle from 0.1.3
to 0.1.4, which builds the esp32 BT controller in BLE-only mode (classic
BR/EDR + A2DP/SPP/HFP dropped). OMG's BT stack is NimBLE (a BLE-only host)
and never uses classic Bluetooth, so it was unreachable dead weight.
Measured on a no-PSRAM Theengs Plug (esp32, NimBLE, MQTT over TLS):
- flash 89.5% -> 86.7% (-54 KB)
- runtime freemem +~10 KB: the dual-mode controller reserved heap for the
classic BR/EDR baseband + 2 classic ACL connections at
esp_bt_controller_init(); BLE-only skips it
- BLE scan/decode and GATT connect (BM2/BM6 battery reads, SwitchBot
control) validated working
esp32-arduino-lib-builder change: theengs/esp32-arduino-lib-builder
mem/esp32-ble-only-controller (in 0.1.4).
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The PlatformIO library registry can no longer resolve
SmartRC-CC1101-Driver-Lib@2.5.7:
Library Manager: Installing SmartRC-CC1101-Driver-Lib @ 2.5.7
Warning! Could not find the package with 'SmartRC-CC1101-Driver-Lib @ 2.5.7'
requirements for your system 'linux_x86_64'
This breaks every CC1101-based environment in the nightly build:
esp32dev-rtl_433, esp32dev-pilight-cc1101, esp32dev-multi_receiver,
esp32dev-somfy-cc1101, nodemcuv2-rf2-cc1101, and others fail with:
main/commonRF.cpp:30:14: fatal error: ELECHOUSE_CC1101_SRC_DRV.h: No such file
Switch to the upstream GitHub release URL, matching how other
removed-from-registry libs in this file are pinned (m5tough, stl,
shtc3, etc). The v2.5.7 tag still exists in the upstream repo.
Co-authored-by: Florian <1technophile@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Switch Ethernet RMII clock from GPIO16 to GPIO0 output mode,
freeing GPIO16 for PSRAM chip select (SPICS1) on WROVER-IE
- Enable PSRAM with QIO flash mode and cache workaround flags
- Add PHY pre-power support for ETH_CLOCK_GPIO0_IN mode
- Report PSRAM status and free memory in SYS MQTT topic
Requires Theengs lib-builder update: remove LIBTIME from IRAM
cache workaround (CONFIG_SPIRAM_CACHE_LIBTIME_IN_IRAM=n) to
free ~3.5KB IRAM for the -mfix-esp32-psram-cache-issue flag.
Tested on Theengs Bridge v1.1: 4MB PSRAM detected, Ethernet
100Mbps on GPIO0, BLE scanning nominal.
Co-authored-by: Florian <1technophile@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* An FSK version for esp32dev-rtl_433 has been added to handle the Bresser 5-in-1 weather station with a standard 868 MHz c1101
* Change platform and DGateway_Name
Enable the management of different connections at runtime with a set of certs for each.
Add parameters to the WiFi Manager onboarding, client certificates, and certificate validation
* First build with IDF, tested with esp32dev-ble only.
* Fix frameworks for non-esp32 boards
* Add blufi support.
* Adds an environment to use esp-idf and Arduino as a component to facilitate incorporating blufi for onboarding and configuration.
---------
Co-authored-by: h2zero <powellperalata@gmail.com>
• Bump Theengs Decoder to 1.6.7
• Conversion of prmac decoders to RMAC, for RMAC filtering of random MAC devices, until and if OpenMQTTGateway gets Identity MAC/IRK functionality.
•HA discovery lock class added
* [FSK] Add Lilygo Heltec environment with FSK modulation
Enable RTL_433 frequency and active receiver change with WebUI
Add FSK environment for Heltec and Lilygo
* [SYS] Configuration portal for Ethernet board
Enable Wifi Manager as a configuration portal for Ethernet boards, also leverage the Wifi Access point as a fallback connectivity method
Add link to the WebUI from HA and reduce key length
* Remove unnecessary environment
Now that one environment cans support wifi and ethernet, merge the 2
* [LORA] Capability to change LORA frequency and Add OLED
Merge of the 2 environments for TTGO V1
* Merge messages keys with upper level json
* Id as a sub topic
* Add display and state measures
* Add frequency configuration through WebUI
* Add parameters
* Add auto discovery
* Add node example for ttgo lora32 v1
* Add environments and fix scope
* Support for sync word as a byte
* Fix TX Power setting
* Add LoRa gateway description
* Add onlyknown filter
Update to rtl_433_ESP 0.3.0
Resolves issue with sx127x chipset and receiving higher frequencies
Includes support for receiving FSK signals, requires compiler directive OOK_MODULATION=false to switch to FSK mode
Adds unit of measure for rtl_433/battery_ok devices RTL_433_ESP Battery Auto Discovery Missing Unit of Measurement #1644
Updates value template for rtl_433/battery_ok in openHab mode
Resolves out of stack space crash lilygo-rtl_433 crash after chacon remote control button pressed #1655
