The shunt voltage register is a 16-bit two's complement value. The
old conversion tested `shuntvolt && 0x8000` (always true for a
non-zero reading) and then negated the complement of the zero-extended
value, which gives back the raw register value. Positive readings came
out right by accident, but a reverse current was published as a large
positive current (0xFFF0 -> 1.638 A instead of -0.4 mA with the
default 0.1 ohm shunt).
Cast the register to int16_t instead.
Fixes#2395
Signed-off-by: Zhaoqi Xu <lzy00419@outlook.com>
createDiscoveryFromList() used column [2] as the unique id suffix of
gateway entities whenever it was non null. The gateway sensors (RF, RF2,
IR, Pilight, SRFB, RFM69, LORA, 2G, hcsr501...) pass "" there, so they
all got the unique_id "<MAC>-": entities of a multi module gateway
collide in Home Assistant, and the ids changed from the
"<MAC>-gatewayLORA" form used by v1.8.1, duplicating entities on
upgrade. Treat an empty suffix like a null one and fall back to the
name, as already done for column [11].
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
TheengsUtils::_rawToHex() formats each byte with "%02X\r", so the last
sprintf writes two bytes past the 2 * size hex digits (the '\r' and the
terminating null). LORAtoX() sized its buffer 2 * packetSize + 1, one
byte short, overflowing the stack for every binary LoRa packet.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Every page heading printed the modules JSON array as is
(["LilyGo_SSD1306","WebUI","LORA"]). Show it as a comma separated list.
The heading buffer was also filled with serializeJson(modules, jsonChar,
measureJson(modules) + 1), i.e. the size of the text rather than of the
100 bytes buffer, which overflows when many modules are enabled; the new
helper (and the boot log) use the buffer size.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
server.arg() returns a String by value, so the pointer from c_str()
pointed into a temporary that was destroyed before strlen()/strcpy().
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The ISNO Super is an open-hardware ESP32-S3 board carrying two CC1101
sub-GHz radios (433 MHz and 868/915 MHz) combined on a single antenna
through a passive LC diplexer. This environment builds on the
esp32dev-multi_receiver RF stack; it drives the 868/915 MHz radio (868
in the EU, 915 in the US) and parks the 433 MHz one using the existing
RF_MODULE_SECONDARY_CS hook in commonRF.cpp.
Signed-off-by: Olivier Delafosse <olshad@gmail.com>
On HTTP_UPDATE_OK the pre-reboot RLStoMQTT reported
`installed_version = latestVersion` unconditionally. That is only correct for
a "latest" request: "dev" installs from RELEASE_LINK_DEV, "vX.Y.Z" installs
that tag, and a caller-supplied URL installs an arbitrary image whose
`version` field is just a label (the WebUI sends "test"). On ESP8266
latestVersion is never populated, so every successful OTA there published an
empty installed_version.
Report the version that was actually requested when the URL was derived from
it, and omit the field for a caller-supplied URL rather than publish a label
as a version. The decision is keyed on systemUrl (non-empty only on the
derived branches) rather than on `version`, because `{"url": ...,
"version": "latest"}` takes the url branch and must not be reported as the
latest release. The value is stored as a String so ArduinoJson 6.18.5 copies
it into the document instead of referencing the caller's buffer.
Scope and evidence, stated plainly: this corrects the message when it lands,
and on current development it usually does not. ESPRestart(6) clears
jsonQueue before the drain task publishes, so the pre-reboot "Update success
!" message was dropped on 3 of 3 successful OTAs on a Theengs Bridge,
including one where this code was certified to be the firmware performing the
update. The change is therefore verified by inspection and by clean builds
(theengs-bridge-v11 on ESP32, nodemcuv2-rf on ESP8266, no new warnings), not
by observing the corrected field on hardware. The authoritative
installed_version is republished from OMG_VERSION after the reboot, which was
correct in every run. Making the pre-reboot message survive the restart, or
dropping it in favour of that republish, is a separate change.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
eraseConfig() passed SPIFFS.format() as an argument to THEENGS_LOG_TRACE,
which expands to ((void)0) below LOG_LEVEL_TRACE and discards its arguments
along with the call. On every build using the default LOG_LEVEL_NOTICE the
format therefore never ran, so {"cmd":"erase"} only performed
nvs_flash_erase(): the WiFi credentials were cleared but /config.json
survived and restored the MQTT server, port, user, password, broker and
client certificates, connection index, topic, gateway name, OTA password
and BLE AES keys on the next boot.
Call SPIFFS.format() on its own statement and report a failed format at
ERROR level, so the failure is visible at the default log level.
This was introduced in #2232, which converted the original runtime-checked
Log.trace() call to the compile-time macro. It affects the SYS erase
command, the WebUI erase button and the GPIO factory-reset hold alike,
since all three go through eraseConfig().
Reproduced on a Theengs Plug built at the default log level: after
{"cmd":"erase"} the NVS namespaces are gone ("SYS config not found",
"ONOFF config not found") and the saved APs are empty, yet the same boot
still logs "Config loaded from flash" and restores the OTA server cert.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Power ETH_PHY_POWER down for 200 ms and back up 200 ms before ETH.begin()
so the PHY always gets a true cold start. A warm PHY left in a stale state
(reproduced on Theengs Bridge v1.1 with PSRAM enabled after an NVS erase)
can flap the link until a manual power cycle: it reports up for one poll,
then down for several seconds, forever, so DHCP never completes. The short
reset the Ethernet driver performs on its own does not clear that state; a
power cycle with a settle window before begin() does. On a hardware-in-the-
loop bench the same provocation went from flapping every trial to flapping
in none of them (4/4).
Enabled via -DETH_PHY_COLD_CYCLE, only active when ETH_PHY_POWER is a valid
pin, at the cost of ~400 ms added boot time. Set by default on both Theengs
Bridge environments.
Co-authored-by: Florian <1technophile@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Boards that carry two radios on one SPI bus need the unused radio's CS held
high, or it answers on MISO and corrupts every transfer to the radio that is
actually in use. Add an optional RF_MODULE_SECONDARY_CS: when defined, drive
that pin high before probing the CC1101.
Bench-proven on a dual-CC1101 ESP32 board where one radio is faulty and the
other is the working one: without the deselect the shared bus is unreliable;
with it, the working module probes cleanly on the first attempt and decodes
live 433 MHz sensors.
No effect on single-radio boards: the whole block compiles out unless
RF_MODULE_SECONDARY_CS is set.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
esp-nimble-cpp 2.1.1 no longer exists: the PlatformIO registry pruned it
(2.3.2 is now the oldest available) and the upstream 2.1.1 git tag was
deleted as well. Dependency resolution therefore fails before any
compilation, breaking every build of esp32dev-ble-idf:
UnknownPackageError: Could not find the package with
'h2zero/esp-nimble-cpp @ 2.1.1' requirements
Pin 2.5.0, matching the NimBLE-Arduino 2.5.0 already used by the Arduino
ESP32 environments, and reference the GitHub archive rather than the
registry so future registry pruning cannot break the build again.
No source changes are needed: esp32dev-ble-idf builds clean with the
newer API, blufi.cpp included.
Co-authored-by: Florian <1technophile@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Eight environments were still pinned to espressif32@6.1.0 (arduino-esp32
2.0.7 / IDF 4.4) while the rest of the tree had moved to the shared
${com.esp32_platform} definition. Align them so they build against the
platform that actually ships, rather than silently keeping an old
toolchain alive:
esp32doitv1-aithinker-r01-sx1278
esp32dev-rtl_433, esp32dev-rtl_433-fsk
heltec-rtl_433, heltec-rtl_433-fsk
lilygo-rtl_433, lilygo-rtl_433-fsk
esp32dev-multi_receiver
The stray "* copy.c" duplicate in rtl_433_ESP that previously blocked
these envs on a modern toolchain is gone as of rtl_433_ESP v0.6.0, which
development already pulls in, so no build workaround is needed.
The move alone is not sufficient: the newer core leaves ~35 KB less heap
on BT-less ESP32 builds, which pushes the memory-constrained RTL_433
boards into a boot loop at the first TLS handshake. That is fixed here
too, in main.cpp.
On ESP32-classic builds without ZgatewayBT, arduino-esp32 3.x leaves most
of the Bluetooth controller's reserved DRAM (CONFIG_BTDM_RESERVE_DRAM =
0xdb5c, 56156 B) stranded. arduino-esp32 2.x released the whole BTDM
region unconditionally in initArduino():
if (!btInUse()) esp_bt_controller_mem_release(ESP_BT_MODE_BTDM);
3.x releases CLASSIC and BLE separately, and the CLASSIC pass silently
short-circuits. cores/esp32/esp32-hal-bt.c has:
#if defined(CONFIG_BT_CLASSIC_ENABLED)
static bool _classicMemReleased = false;
#else
static bool _classicMemReleased = true; // "No Classic BT on this chip"
#endif
With a BLE-only controller build CONFIG_BT_CLASSIC_ENABLED is unset, so
_classicMemReleased starts true and btMemRelease(BT_MODE_CLASSIC_BT)
returns "already released" without reaching IDF. Only the ~5 KB BLE slice
is freed. The guard is wrong for this part: ESP32 does have Classic BT
hardware (CONFIG_SOC_BT_CLASSIC_SUPPORTED) and the DRAM is reserved
regardless of the controller's configured mode; the correct guard would be
CONFIG_SOC_BT_CLASSIC_SUPPORTED. Reported upstream separately.
Release the whole BTDM region explicitly. esp_bt_mem_release() is used
rather than esp_bt_controller_mem_release() because it is a superset that
also frees the linker _bt_data / _bt_controller_* sections. The guard is
compile-time and authoritative: OMG knows via ZgatewayBT whether it uses
BT, whereas the core infers it from link-time flags that NimBLE-Arduino
does not set. Safe no-op if the memory was already released or once the
core is fixed. Note this makes btStart() permanently unavailable in these
builds, which is already the case for a !ZgatewayBT build.
Measured on a Heltec WiFi LoRa32 V2 running heltec-rtl_433 (WiFi + MQTT +
TLS + rtl_433 + SSD1306, no BT), pioarduino 55.03.39 / esp32-arduino-libs
0.1.8:
BT DRAM reclaimed: 209928 -> 245048 (+35120 B)
Update check, free heap: 49868 -> 89484
Without it, the boot-time HTTPS update check fails its TLS handshake
("Dynamic Impl: alloc(4437 bytes) failed", then X509 -9984) because the
largest free block is too small, and the MinimumMemory watchdog then
reboots the board in a loop. With it: no allocation failure, handshake
succeeds, freemem ~85 KB / minmem 53432 against the 40000 threshold,
0 reboots over a 3 min soak with live RTL_433 decodes.
The memory fix affects every ESP32-classic env without ZgatewayBT, not
just the ones moved here. The RTL_433 envs fail loudly because they carry
the MinimumMemory watchdog; others (esp32dev-ir, esp32dev-pilight,
ttgo-lora32-v21, heltec-wifi-lora-32, ...) simply run ~35 KB short.
Builds with ZgatewayBT are unaffected.
Hardware validation, two boards:
heltec-rtl_433 (OOK 433.92 MHz, Heltec WiFi LoRa32 V2)
boots, joins WiFi/MQTT, RadioLib/SX127x RSSI calibration completes,
HA discovery publishes, decodes live ambient sensors
(Ambientweather-F007TH, Prologue-TH, WEC-2103).
heltec-rtl_433-fsk (FSK 915 MHz, second Heltec)
same boot path, decodes a live Fineoffset-WH51 soil sensor.
The other six envs have no matching board on hand and are compile-only.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This refreshes the bundled rtl_433 decoder set to the latest development snapshot available on August 14, 2026: 25.12-346-g91b2ebdb, commit 91b2ebdb.
Refresh rtl_433 device decoders, supporting utilities, headers, and generated registration files.
Expand the supported set to 223 OOK and 153 FSK protocol decoders.
Regenerate the README protocol lists directly from the registered decoder set.
Update the decoder-generation tooling for the refreshed upstream layout.
Add Vivint DW11/DW21R, PIR2, and GB2 decoding with automatic 16-bit seed discovery.
Support compile-time Vivint seed lists through VIVINT_SEEDS.
Add optional Vivint seed-discovery diagnostics and OUTPUT_VIVINT_DECODE=0 to omit them.
Make the Vivint sensor count, sample cache size, and required sample count configurable.
Refresh the README and PlatformIO examples.
Update the RadioLib dependency and library metadata for Beta 0.6.0.
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>
Static IP over Ethernet on ESP32 was unusable, and a fresh board with a
working Ethernet link still brought up the WiFi radio.
setup_ethernet_esp32() did not compile with NetworkAdvancedSetup defined: it
declared ip_adress/gateway_adress/subnet_adress/dns_adress but then called
fromString() on ip/gateway/subnet/Dns, which are declared nowhere. The WiFi
path a few hundred lines above does the same thing correctly, so this looks
like an incomplete copy of it.
Once that compiles, the static IP was still ignored. ETH.config() was called
before ETH.begin(), but NetworkInterface::config() returns false immediately
while _esp_netif is NULL, and the netif is only created inside begin(). The
call was a silent no-op and the board kept asking for DHCP. Swapping the order
is safe: the client branch of config() stops the running DHCP client itself
and sets the static-IP status bit. The return value is now checked and logged
instead of being discarded.
Separately, the "no config in flash" branch of setup() called
setupWiFiManager() guarded only by !failSafeMode, while the "config loaded"
branch a few lines above correctly also checks !ethConnected. So a
factory-fresh board with Ethernet already up would still start the WiFi
manager. Beyond being unnecessary, it powers up the 2.4GHz radio and competes
with BLE on gateways that run both.
Verified on an Olimex ESP32-POE-ISO: the board now takes its static address
immediately with no DHCP wait, does not fall back to the WiFi manager, and
reaches the broker. Formatting checked with clang-format against .clang-format.
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>
checkForUpdates() reads an optional "envs" map from the update manifest and,
when it holds an entry for this build's ENV_NAME, offers that version instead
of the global latest_version. Boards with no entry are unaffected.
This lets the OTA server hold a specific product at an older release while the
rest of the fleet advances, with no per-board build flags. The resolved value
is republished as latest_version so the Home Assistant update entity compares
against it, and the map itself is dropped from the retained state topic to
keep it small.
Backward compatible both ways: old firmware ignores "envs", and a manifest
without "envs" behaves exactly as before.
OTA_JSON_URL is also guarded with #ifndef so a build environment can point the
update check at another OTA server. It was defined unconditionally, so a -D
build flag could not retarget it (the header definition always won). This is
needed to exercise the check against a test manifest, and is useful for
self-hosted OTA servers. No behaviour change without an override.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
The home hero image overlapped the hero title on phones: the default theme
pulls the stacked image up with negative margins (-76px -24px -48px), which
only works because it normally sits absolutely positioned inside a fixed
320px box. custom.css lets the image flow to enlarge it, so those margins
made it bleed off-screen and collide with the title. Reset them below 960px,
and hide the image entirely under 640px -- at phone size it is a wall of
unreadable logos that pushes the title, tagline and call-to-action buttons
below the fold.
Also fixes, found while sweeping every page at 360/400/900px:
- Nav bar: the shared Theengs nav has seven top-level entries and the theme
swaps to the desktop nav bar at 768px, where it does not fit. From 768px to
~1180px, Shop, Sponsor, the appearance switch and the GitHub link were
clipped or off-screen and the page scrolled sideways. Keep the hamburger +
full-screen menu until the full menu genuinely fits.
- upload/binaries: indented (non-fenced) code blocks render as a bare <pre>,
which the theme only makes scrollable inside a language-* wrapper, so the
long esptool.py commands pushed the page sideways.
- use/lora: the YouTube embed is raw HTML with width="560", wider than a
phone. Make video embeds fluid at a 16/9 ratio.
- OmgPipeline: stack below a 680px container instead of 480px -- in between,
the "OpenMQTTGateway" label spilled out of its node and over the arrows.
Drop the media query in index.md that meant to do this: it was scoped to
index.md and could never match an element inside the child component.
No horizontal overflow remains on any of the 50 pages at 360px, 400px or
900px; desktop is unchanged.
Claude-Session: https://claude.ai/code/session_01Nj6xa5Mk5wi8XWtgJG7w5D
Co-authored-by: Florian <1technophile@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Getting started:
- New 15-minute Getting Started guide featuring the two most popular
tracks (BLE on esp32dev-ble, RF on lilygo-rtl_433), with broker setup
and a verification step
- Sidebar restructured around the new-user journey; upload options
numbered by ease; Gitpod upload method removed
Home page:
- VitePress hero with clear actions, larger hero image
- How-it-works pipeline diagram shared as a component (responsive via
container queries), use-case grid, bigger video tiles without the
image lightbox, refreshed press coverage list, functions pills
- Support section pointing to Theengs Bridge and
github.com/sponsors/1technophile
Upload flow:
- Decision-oriented upload landing page (journey strip, method cards,
comparison table)
- Pre-flight checklist and driver troubleshooting on the web installer
- Guided environment picker (bridge + hardware wizard) replacing the
filter chips, with manifest-verified recommendations
- Post-flash next-steps card linking to the portal and verification
Board images:
- custom_img key in environments.ini and board photos for all
web-flashable environments (licenses recorded); private prod_env.ini
environments excluded from boards-info.json
Corrections:
- RF frequency coverage stated as 433/315/868/915MHz
- Removed references to the retired compatible.openmqttgateway.com
site (BLE list is decoder.theengs.io), the discontinued Theengs
Plug, and the private sponsor forum
Claude-Session: https://claude.ai/code/session_01TYysQW8tpmt1dWWuzKhTLi
Co-authored-by: Florian <1technophile@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
handleWI() dispatches internally on the "scan" query arg, so the same
handler serves both the scan link and the save form. #2037 narrowed the
route to POST-only, which orphaned the scan hyperlink (a GET) in
config_WebContent.h. Re-register /wi for HTTP_GET alongside HTTP_POST;
the credential Save form stays method=post, so no secrets move to GET.
Co-authored-by: Florian <1technophile@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Serial.begin() was hardcoded to SERIAL_8N1 across all four UART init paths
(UART0/1/2/3), with no way to override it via a build flag -- unlike SERIALBaud,
which already is. Devices using non-8N1 framing (e.g. even-parity RS232 sources)
currently can't be read correctly at all, not just unreliably: a parity mismatch
misaligns the frame, not just adds occasional noise.
Adds SERIAL_CONFIG following the existing #ifndef/#define override pattern used
throughout this codebase, defaulting to SERIAL_8N1 so existing environments are
unaffected byte-for-byte. Verified: default (SERIAL_8N1) and an override
(SERIAL_CONFIG=SERIAL_8E1) both build successfully on ESP32.
Co-authored-by: simowilso <simowilso@users.noreply.github.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
setupWiFiManager() disables the config portal whenever /config.json exists
(a security measure to avoid exposing the config data + OTA page). But if the
saved WiFi credentials are lost while config.json remains -- e.g. the NVS
partition is erased ({"cmd":"erase"}, or corruption) -- the gateway can no
longer connect AND the portal is suppressed: autoConnect() fails immediately
and the failure path calls ESPRestart(3). The device then reboot-loops
forever, un-onboardable, its SoftAP flickering up ~1s per cycle.
Only suppress the portal when config.json exists AND saved STA credentials
are still present (WiFi.SSID() non-empty). With no credentials the portal
stays enabled, so the gateway raises a stable onboarding AP and can be
re-provisioned instead of reboot-looping. The original security intent is
preserved for provisioned gateways (which always have saved credentials).
Reproduced + verified on a Theengs Plug (esp32dev, min_spiffs): with NVS
erased and config.json present, the SoftAP is now stable and accepts
provisioning via the captive portal, rejoining the broker normally.
Claude-Session: https://claude.ai/code/session_01MbmZRv67fnNvzpyvqPi6vx
Co-authored-by: Claude Opus 4.8 <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>
Several envs pass '-ACTUATOR_TRIGGER=true' instead of
'-DACTUATOR_TRIGGER=true', so the ACTUATOR_TRIGGER macro is never defined
and the physical-button -> relay toggle in sensorGPIOInput.cpp
(#if defined(ZactuatorONOFF) && defined(ACTUATOR_TRIGGER)) is compiled out.
Verified on a Theengs Plug: with the -D added, a button press now toggles the
relay and emits ONOFFtoMQTT. Same one-character fix applied to the other envs
carrying the identical typo.
Affected envs: theengs-plug, esp32dev-all-test, sonoff-basic, sonoff-basic-rfr3.
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>
chriz