This branch is a clearly scoped, optional extension of OpenMQTTGateway 1.8.1. It was created for an ESP32 garage gateway that receives 433 MHz devices through a CC1101, monitors wired sensors, detects selected BLE devices and can wake the MQTT host. It does not replace or redefine the many other boards and gateway presets in the upstream project.
The ready-to-build presets are esp32dev-multi_receiver-wol-gpio-ble and
esp32dev-multi_receiver-wol-gpio-no-ble. They keep the official
esp32dev-multi_receiver preset unchanged and add features useful when the
gateway is installed away from the MQTT/Home Assistant server.
| Area | Upstream 1.8.1 behaviour | This optional edition |
|---|---|---|
| Wake-on-LAN | No MQTT-outage recovery policy | Configurable target MAC, outage delay, failure threshold, repeat interval and error categories; a successful MQTT connection resets every WOL timer |
| Wired sensors | One build-time GPIO input | Two independently enabled and named inputs configured in the Web UI |
| Input electronics | Pin mode fixed at compile time | Per-input INPUT, PULLUP or PULLDOWN, active HIGH/LOW, debounce, retained MQTT state and Home Assistant device class |
| GPIO outputs | A separate actuator build is needed | Two independently enabled Home Assistant switches for relays, LEDs, active buzzers or 3.3 V logic inputs; each supports push-pull/open-drain, active HIGH/LOW, safe OFF/ON/restore startup and retained state |
| GPIO safety | Generic board-level validation | The supplied CC1101 preset exposes only pins that do not collide with flash, SPI, CC1101 or ESP32 boot-strapping duties |
| BLE presence | BLE presets normally publish/ decode the devices they hear | Up to four fixed-MAC BLE devices selected in the Web UI; each gets a retained Home Assistant presence entity plus RSSI, its own away timeout and minimum-signal threshold |
| MQTT resilience | Standard reconnect behaviour | Unique client ID suffix, uninterrupted WiFi association window, protected recovery portal, predictable DHCP/mDNS hostname, bounded MQTT reconnect timing, clean warm-reboot radio shutdown, runtime recovery watchdog, longer keepalive, preserved operation while the broker is offline and safer password updates |
| Diagnostics | General OpenMQTTGateway logs | Stable [BOOT], [WIFI], [MQTT], [WOL], [GPIO], [BLE][ADV], [MEM], [QUEUE], [RF][CC1101], [WebUI][OTA] and [DIAG] events with failure causes and memory/queue context; a bounded startup guard automatically recovers from a stalled module initialization |
| Web interface | Original compact Web UI | Responsive card layout, live GPIO/BLE state, nearby-BLE suggestions, contextual wiring hints and local .bin OTA upload after this custom edition has been installed once by USB |
The WOL logic deliberately does not send a magic packet after every ordinary disconnect. It distinguishes transport failures, broker refusals and authentication errors, waits for the configured outage conditions and clears stale state after reconnection. This addresses repeated or apparently random WOL packets and timers that did not reset correctly.
Typical uses include a garage, gate, shed or equipment cabinet where one ESP32 must receive RF devices, expose door/contact and selected BLE presence sensors, and control two small external loads or logic inputs from Home Assistant while also waking the machine hosting MQTT when it is genuinely unavailable. BLE scanning is passive and duty-limited to reduce contention with the ESP32 WiFi radio. A controller-only VHCI observer avoids the NimBLE/Bluedroid host, connections, GATT and decoder tasks. This preset intentionally tracks selected devices rather than embedding the full Theengs decoder, because CC1101 + RTL_433 + the full BLE pipeline leaves too little memory for reliable operation on this 4 MB ESP32.
Configure BLE from Device configuration → BLE presence devices. Wait for a scan, choose one of the recently seen MAC suggestions (or type a fixed MAC), give it a name, set the away timeout and RSSI threshold, then enable the slot. No reboot is required. Phones and privacy-oriented devices often rotate their BLE address; use a beacon/tag with a fixed MAC when reliable presence is needed.
Start here:
- Detailed use case, configuration and design notes
- GPIO input and output wiring
- Firmware with BLE — stable R6
- Firmware without BLE — reliability update R6
Reliability revision 6 is the current public release. It fixes the decoded network-timer allocation panic, removes unused RF startup memory, adds checked RF allocation paths and hardens multipart parsing and OTA transfers. It retains the checked MQTT queue, recovery guards, persistent incident diagnostics and downloadable crash report from earlier revisions, with WOL parser/rollover fixes.
The BLE edition is marked stable as of 10 October 2026, following the owner's report of stable normal use since release. The NO BLE edition shares the common fixes, but this field-use confirmation concerns the deployed BLE edition only. Firmware files are unchanged by this status update.
Both variants were built and installed on the same ESP32 through local-file WebUI OTA, with complete pages, MQTT/RF operation and unchanged GPIO/BLE settings. Native tests cover allocation failure, parser bounds, timers, GPIO/discovery, WOL and BLE presence behavior. Multi-week stability is not established, and no release promises zero bugs. See the R6 diagnostics and validation notes.
| Variant | Intended use |
|---|---|
WOL + 2 IN + 2 OUT + NO BLE |
RF/CC1101, WOL, two configurable inputs and two Home Assistant-controlled outputs. It contains all fixes and features of the BLE edition except the BLE observer, leaving more free memory. |
WOL + 2 IN + 2 OUT + BLE |
The same RF, WOL and GPIO feature set plus selected fixed-MAC BLE presence, balanced scanning, automatic scan recovery and cleanup of disabled BLE entities. |
The two outputs are disabled by default. Their logical command, retained state, active-level inversion and restore-after-restart paths were exercised through MQTT/Home Assistant without an attached load; electrically validate any relay, LED or buzzer circuit before enabling it.
Build the dedicated preset with:
platformio run -e esp32dev-multi_receiver-wol-gpio-ble
platformio run -e esp32dev-multi_receiver-wol-gpio-no-ble
Every release provides a complete Windows USB ZIP for the first installation.
It contains the portable flashing tool, bootloader, partition table, OTA data,
application image and a double-click guided script; PlatformIO and Python are
not required. The separately named WebUI .bin is only for later updates from
a version of this custom edition that already shows Local firmware file.
The original OpenMQTTGateway 1.8.1 WebUI does not provide that local-file form.
The custom preset is intentionally opt-in. All upstream environments remain available, and changes that are not relevant to them stay behind build flags. The supplied binary was validated on the hardware described below. Verify your own wiring, GPIO choices, broker and RF configuration before relying on it in an unattended installation.
OpenMQTTGateway aims to unify various technologies and protocols into a single firmware. This reduces the need for multiple physical bridges and streamlines diverse technologies under the widely-used MQTT protocol.
The documentation is here
The reference sheet, with the list of all functions, pinouts is here
Upload OpenMQTTGateway directly from the upload page (no additional software required) or build your own configuration with PlatformIO.
Support open-source development through sponsorship and gain exclusive access to our private forum. Your questions, issues, and feature requests will receive priority attention, plus you'll gain insider access to our roadmap.
Theengs bridge is a powerfull BLE to MQTT gateway for over 100 sensors. Equipped with an Ethernet port, and external antenna, ensuring an enhanced range for your BLE sensors. It supports also WiFi connectivity.
Theengs plug brings the following features:
- BLE to MQTT gateway, tens of Bluetooth devices supported thanks to Theengs Decoder library. The plug uses an ESP32 acting as a BLE to Wifi gateway to scan, decode and forward the data of the nearby sensors,
- Smart plug that can be controlled remotely,
- Energy consumption monitoring,
- Device tracker,
- Presence detection (beta),
- Local connectivity first.
Support the project by purchasing the Theengs bridge or the Theengs plug
-
List of supported devices, door/window sensors, PIR sensors, smoke detectors, weather stations...
-
List of compatible boards (Off the shelf or DIY) is available, RF Bridge, IR, BLE gateways...
Running on a computer If you want to use the BLE decoding capabilities of OpenMQTTGateway with a Raspberry Pi, Windows or Unix PC you can now leverage Theengs Gateway.
- List of compatible components to build your gateway, DHT, RF, IR emitters and receivers...
Thanks goes to these wonderful people who helped OpenMQTTGateway on Github and to the users contributions into the community.
For Questions or Support please don't open an issue, first go to the docs and if you don't find your answer there, you can post your question in the community forum
If you like the project and/or used it please consider supporting it! It can be done in different ways:
- Helping other users in the community
- Contribute to the code or the documentation
- Buy devices, boards or parts from the compatible web site, the devices and parts linked use affiliated links.
- Donate or sponsor the project developers
- Make a video or a blog article about what you have done with OpenMQTTGateway and share it to the community
- Hackaday - ARDUINO LIBRARY BRINGS RTL_433 TO THE ESP32
- CNX Software - 433 MHz is not dead! Using an ESP32 board with LoRa module to talk to 433 MHz sensors
- RTL_433 PORTED TO ESP32 MICROCONTROLLERS WITH CC1101 OR SX127X TRANSCEIVER CHIPS
- Using low-cost wireless sensors in the unlicensed bands
- SMART PLUG ESP32 OPENMQTTGATEWAY SERVING AS AN BLE MQTT GATEWAY AND A POWER METER
