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>
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>
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>
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>
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>
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>
* 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>
When the network drops at runtime and the WiFi stack is wedged (e.g. the
ESP32 driver getting stuck after a long uptime, see #2276), the main loop
kept calling wifi_reconnect_bypass() forever with no recovery: the device
stayed stale until a manual reboot. The reboot watchdog only existed in the
ESPWifiManualSetup path, which the default WiFiManager build doesn't compile.
Count consecutive reconnection failures in the runtime loop and ESPRestart(2)
once they exceed maxRetryWatchDog, mirroring the existing manual-setup
watchdog. Gated behind the new WifiReconnectWatchDog flag (default on) so
environments where an unexpected reboot is undesirable can opt out; disabled
for theengs-plug to avoid interrupting the relay state.
Co-authored-by: Claude <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>
* Refactor GitHub Actions workflows for build, documentation, and linting
- Consolidated build logic into reusable workflows (`task-build.yml` and `task-docs.yml`) to reduce duplication across multiple workflows.
- Introduced `environments.json` to centralize the list of PlatformIO build environments, improving maintainability and clarity.
- Updated `build.yml` and `build_and_docs_to_dev.yml` to utilize the new reusable workflows and environment definitions.
- Enhanced `release.yml` to streamline the release process and integrate documentation generation.
- Created reusable linting workflow (`task-lint.yml`) to standardize code formatting checks across the repository.
- Simplified manual documentation workflow by leveraging the new reusable documentation workflow.
- Improved artifact management and retention policies across workflows.
- Updated dependencies and versions in workflows to ensure compatibility and performance.
CI/CD pipeline agnostic of Workflow Engine and integrated on github actions
- Implemented ci.sh for orchestrating the complete build pipeline.
- Created ci_00_config.sh for centralized configuration of build scripts.
- Created ci_build_firmware.sh for building firmware for specified PlatformIO environments.
- Created ci_prepare_artifacts.sh for preparing firmware artifacts for upload or deployment.
- Created ci_set_version.sh for updating version tags in firmware configuration files.
- Created ci_build.sh to orchestrate the complete build pipeline.
- Created ci_qa.sh for code linting and formatting checks using clang-format.
- Created ci_site.sh for building and deploying VuePress documentation with version management.
- Implemented checks for required tools and dependencies in the new scripts.
- Improved internal scripts for better error handling and logging.
UPDATE the web installer manifest generation and update documentation structure
- Enhanced ci_list-env.sh to list environments from a JSON file.
- Replaced common_wu.py and gen_wu.py scripts with new npm scripts for site generation and previewing on docsgen/gen_wu.js
- Replaced generate_board_docs.py with docsgen/generated_board_docs.js
- Added new npm scripts for integration of site generation on build phase.
- Created preview_site.js to serve locally generated site over HTTPS with improved error handling.
- Added new CI environments for CI builds in environments.json.
- Deleted lint.yml as part of workflow cleanup.
- Enhanced task-build.yml to include linting as a job and added support for specifying PlatformIO version.
- Improved task-docs.yml to handle versioning more effectively and added clean option.
Enhance documentation
- ADD CLEAR Mark of development version of site
- Updated README.md to include detailed workflow dependencies and relationships using mermaid diagrams.
- Improved development.md with a quick checklist for contributors and clarified the code style guide.
- Enhanced quick_start.md with tips for contributors and streamlined the workflow explanation.
LINT FIX
- Refined User_config.h for better formatting consistency.
- Adjusted blufi.cpp and gatewayBT.cpp for improved code readability and consistency in formatting.
- Updated gatewaySERIAL.cpp and mqttDiscovery.cpp to enhance logging error messages.
- Improved sensorDS1820.cpp for better logging of device information.
Add security scan workflows for vulnerability detection
Add SBOM generation and upload to release workflow; update security scan summary handling
Add shellcheck suppor + FIX shellcheck warning
Enhance documentation for CI/CD scripts and workflows, adding details for security scanning and SBOM generation processes
Fix formatting and alignment in BLE connection handling
Reviewed the full web board presentation and the ESP32 web upload. The project uses a modern pattern where data is divided from the presentation layer.
- Removed the `generate_board_docs` script.
- Updated the `gen_wu` script in order to generate `boards-info.json`: the fail that containe all information about the configuration
- Created and isolate the file `boards-info.js` to streamline the parsing of PlatformIO dependencies, modules, environments and improve the handling of library information.
- Introduced vuepress component `BoardEnvironmentTable.vue` that render `boards-info.json` as UI card component
- Introduced vuepress component `FlashEnvironmentSelector.vue` that render a selectred environment from `boards-info.json` and provide esp-web-upload feature on it
- Introduced a new board page `board-selector.md` for improved firmware selection.
- Updated `web-install.md` to enhance the firmware upload process, including a new board environment table.
- Enhanced custom descriptions in `environments.ini` to include HTML links for better user guidance and board image link
Add CC1101 initialization improvements and logging enhancements
Add installation step for PlatformIO dependencies in documentation workflow
Remove ci_set_version.sh script and associated versioning functionality
* Fix comment provisined
Fix PlatformIO version input reference in documentation workflow
Remove outdated Squeezelite-ESP32 installer documentation
- Convert nightly workflow to matrix builds to fix FRAMEWORK_DIR issues
caused by platform_packages conflicts when building sequentially
- Each environment now builds on its own runner, matching build.yml
- Add deploy job that collects all artifacts and deploys docs
- Add extra_scripts to esp32dev-pilight environment to fix implicit
function declaration error with newer GCC toolchain
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Florian <1technophile@users.noreply.github.com>
Co-authored-by: Claude Opus 4.5 <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
* add '-DvalueAsATopic=true' to RF based environments
add '-DvalueAsATopic=true' to RF based environments. Required to support changes in zgatewayRF.ino for Home Assistant discoverability
* Modify gatewayRF to improve Home Assistant auto discoverability
Pass "recieved" as the type argument and switchRF[0] as the subtype argument to announceDeviceTrigger() which will cause recieved codes to be picked up by home assistant as triggers, i.e. When setting up automations in Home Assistant, selecting a `device` trigger and an OMG device will allow the user to select a code picked up during the autoDiscover window as the trigger for the automation, for example "1394004" recieved. In order to support this, the `'-DvalueAsATopic=true'` argument must be added to all environments using the RF Library
Also change getUniqueId() call to remove leading '-' which will prevent MQTT topics having '--' in them
---------
Co-authored-by: James Carey <james.carey@uws.ac.uk>
Refactor LED handling into a library
Use a task instead of relying on the loop for precise timing
Co-authored-by: Florian <1technophile@users.noreply.github.com>
Gaterway states to improve LED management
Make the sleep function accessible outside BT
BREAKING remove sleep for ESP8266
BREAKING lowpowermode API changed to powermode and new mode definition
Co-authored-by: Florian <1technophile@users.noreply.github.com>
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>
* [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
chriz