OMOTE-Firmware: Build an ESP32 Universal Remote

What OMOTE-Firmware Controls

OMOTE-Firmware addresses a specific problem: turning an ESP32-based handheld device into a programmable remote for entertainment equipment and connected home devices. The repository describes it as firmware for the OMOTE Open Universal Remote, aimed at users who are willing to compile and upload their own build rather than install a finished consumer image. It can run either on dedicated OMOTE ESP32 hardware or inside an LVGL GUI simulator on Linux, macOS, or Windows.

The included example models several control paths. A television and amplifier use infrared, while a Fire TV media player is controlled through BLE using a Bluetooth keyboard connection. MQTT is listed for smart-home devices, and an infrared receiver can decode commands from another remote. This combination makes the firmware useful as a base for a remote with local appliance control, Bluetooth input, and network-connected home automation.

The scope is broad enough to interest makers, but the README does not claim universal, out-of-the-box device support. Users can add their own amplifier, television, and media player by modifying the software. The README also describes graphical configuration and persistent configuration storage as unscheduled long-term goals. A graphical editor and an editable JSON configuration stored in flash are therefore not current features.

This distinction matters for adoption. OMOTE-Firmware is an extensible firmware project rather than a packaged remote-control service. Its value depends on how closely the example devices and existing source structure match the equipment that a user wants to control. A buyer seeking a finished consumer product may find the lack of a prebuilt image and graphical setup interface obstructive. A developer comfortable working with embedded C++ can approach the supported examples as starting points.

ESP32, LVGL, BLE, and MQTT Architecture

The repository is presented as ESP32 Arduino firmware rather than as a standalone desktop application. Its top-level structure includes `platformio.ini`, the `src/` directory, and a `hardware/` directory. This identifies PlatformIO as the firmware project system and places application code under `src/`. The LVGL simulator uses the project on Linux, macOS, and Windows, allowing interface work without attaching the remote to physical hardware.

The example divides device control by communication method rather than presenting every target through one protocol. Infrared handles the television and amplifier, BLE handles the Fire TV media player through its Bluetooth keyboard behavior, and MQTT handles selected smart-home devices. Adding an appliance is therefore not simply a matter of adding a button label. The firmware must match the device, communication transport, command format, and expected user interaction.

Wi-Fi appears in the repository topics, but the README does not provide a connection sequence, broker address setting, topic schema, credential mechanism, or reconnect policy. The same documentation gap applies to BLE pairing and device discovery. The repository confirms the intended protocols, but the README does not provide enough configuration detail to treat integration as turnkey. The linked project wiki is the stated source for understanding and modifying the implementation.

The simulator should also be interpreted narrowly. Its documented purpose is fast creation and testing of LVGL graphical interfaces. The README does not say that it reproduces infrared emission, BLE keyboard traffic, MQTT messaging, charging, or physical ESP32 interactions. A successful simulator build can therefore confirm that the interface project compiles and runs in a supported desktop environment, but it does not by itself establish end-to-end appliance control.

PlatformIO Setup and the First Simulator Run

The documented setup begins with the PlatformIO project rather than a firmware download. The README says that PlatformIO must already be running and that the user needs to know how to compile and flash firmware. For OMOTE hardware, connect the remote through its USB-C port, open the PlatformIO project, compile the code, and upload the resulting firmware to the ESP32. No prebuilt firmware is offered, and the README does not give exact shell commands or menu labels for these operations.

The first desktop-oriented use is the LVGL GUI simulator. According to the README, it can be run from Visual Studio Code with PlatformIO on Windows, Linux, or macOS. No separate compiler and no Visual Studio installation are required, despite the simulator running on Windows in some cases. The README links to the project's simulator wiki for details but does not state an exact launch command, so none is invented here.

A practical first session should start with the simulator, confirm that the LVGL interface can be built on the current operating system, and then inspect the example device definitions before changing commands. After that, developers can connect the ESP32 hardware through USB-C and use their established PlatformIO workflow to compile and upload. The simulator is useful for graphical iteration, but it does not replace checking whether infrared output, BLE communication, charging, or USB-C flashing works on physical hardware.

For contributors, the README identifies the normal extension path: fork the repository and create a pull request. General feature requests can also be discussed through the repository discussions page. Since no GitHub releases are listed, there is no documented stable binary that can serve as an installation baseline for new users.

Configuration Limits for New Devices

OMOTE-Firmware's main engineering constraint is that customization is code based. The README explicitly says users can adjust the software and add their own amplifier, television, and media player. It does not document a graphical configuration interface, an editable JSON file, or configuration persistence in flash as present features. Both configuration items appear as long-term, unscheduled tasks.

This makes the project a poor match for someone expecting to pair an arbitrary television, enter an infrared code through a form, save that code, and leave. Such a workflow depends on device discovery, code capture, persistent storage, and configuration editing. Only the infrared receiver example is confirmed. The README does not state whether captured commands can be stored permanently, imported from common remote formats, exported, or recovered after a reboot.

There is a further simulator boundary. An LVGL interface can be developed on a desktop, but the README does not claim that the simulator emulates every external communication path. Treat it as the documented graphical development option, not as proof that infrared, BLE, MQTT, Wi-Fi, or ESP32 hardware behavior has been reproduced. Device-specific validation remains tied to the firmware and compatible physical hardware.

The absence of documented configuration persistence also raises the cost of personalization. Developers should not assume that changes survive a reflash unless the firmware code implements a separate storage method. The README does not identify such a method. Until configuration storage and graphical editing are implemented, device knowledge remains part of the code and the developer's workflow rather than a user-facing setup record.

ESP32 Hardware Constraints and a Separate-Firmware Alternative

A real alternative is a separate Arduino or PlatformIO firmware written for the specific ESP32 and protocols required by a product. That approach can provide direct control over application structure, supported devices, and deployment tooling, especially when a full remote interface and several example integrations are unnecessary. The tradeoff is that the alternative must supply its own button handling, device commands, networking behavior, and persistence rather than inheriting OMOTE's examples.

OMOTE offers a more specific starting point. It combines an LVGL interface, infrared appliance control, BLE media-player control, MQTT support, USB-C programming, and a desktop simulator path in one project. A separate firmware may be preferable when existing infrastructure already manages these functions, when a non-ESP32 target is required, or when OMOTE's unscheduled configuration work would exceed the surrounding product requirements.

The README does not provide a matrix of supported television and amplifier brands. It also does not document target variants, flash-memory constraints, or the exact ESP32 board selection. Those omissions make hardware compatibility something to verify before adopting the code. The presence of an infrared receiver demonstrates one path for learning commands from original remotes, but it does not guarantee support for every infrared protocol or device command set.

For a developer choosing between the two approaches, the practical question is whether the OMOTE examples remove enough repeated work. If the desired television, amplifier, media player, and smart-home integration resemble the documented examples, OMOTE can provide a useful starting structure. If they do not, or if production deployment requires a stable release channel and persistent configuration, a purpose-built firmware program may impose less adaptation work.

Maintenance, Builds, and GPL-3.0 Obligations

The repository is not archived, and its last push was on 2026-10-10. That date is recent, but it is not a release policy. The repository has no GitHub releases, so there is no documented release cadence, stable tag, or packaged firmware for users to install. The README includes Ubuntu, Windows, and macOS PlatformIO build badges, but it does not define release compatibility or a long-term support window.

Maintenance effort will fall largely on adopters who change device definitions, add protocols, integrate hardware, or address known issues. The README directs contributors to the issue tracker and discussions for proposed features and known issues, but it does not promise response times or formal support periods. Upgrading is also not documented as a stable migration path because no versioned releases are listed and flash-stored configuration is not yet available.

The firmware is distributed under GPL-3.0. That matters when deciding whether to modify, combine, or redistribute the software, particularly if a device ships with modified firmware. This is not legal advice, and the README does not discuss exceptions, commercial licensing, or hardware-specific compliance. Review the repository's `LICENSE` file with qualified counsel when distribution goes beyond personal experimentation.

For most users, the first adoption cost is building the source correctly and learning the repository's device definitions. For maintainers, it is reviewing firmware changes across physical remotes and multiple communication protocols. The cross-platform simulator lowers the barrier to graphical work, but it does not remove the need to test device-specific behavior on actual hardware.

Editorial conclusion

Adopt OMOTE-Firmware if you have compatible OMOTE hardware or want to develop and simulate a source-built ESP32 remote in PlatformIO. Do not adopt it if you need downloadable firmware, a web configurator, or support for arbitrary devices without code changes. Check the PlatformIO environment, target hardware, protocol configuration, and GPL-3.0 distribution requirements first, because the project publishes no prebuilt image or GitHub release.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. OMOTE-Community/OMOTE-Firmware on GitHub
4. Project website
5. README