# LibreTiny: an Arduino-compatible build environment for cheap IoT chips > LibreTiny is a PlatformIO development platform that gives the BK7231, RTL8710 and LN882H wireless chips an Arduino-compatible core, inspired by Espressif's ESP32 platform so existing ESP32 code ports more easily. It suits a developer working with Tuya-based modules, and the project states plainly that it is work in progress. **libretiny-eu/libretiny** — PlatformIO development platform for IoT modules - Repository: https://github.com/libretiny-eu/libretiny - Website: http://docs.libretiny.eu/ - Stars: 550 · Forks: 118 - Language: C - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/libretiny-eu-libretiny ## What the project is, and the chip families it targets LibreTiny is a PlatformIO development platform for IoT modules, and the project description is narrow and specific: a PlatformIO development platform for BK7231, RTL8710 and LN882H IoT chips. Those three families are the point of the project. They are the wireless chips that ended up in a huge volume of cheap smart home devices, and the name in the topic list tells you where they came from, with tuya, tuya-iot, ameba iot and the specific part numbers bk7231n, bk7231t and rtl8710bn listed. If you have ever bought a smart plug or a sensor that needed a vendor app to work, there is a reasonable chance the radio in it is one of these. The name has a history worth noting. The project was formerly LibreTuya, and the current name reflects a move away from tying the name to one vendor's brand. The main goal of the project is to provide a usable build environment for IoT developers, and the project also provides vendor SDKs as PlatformIO cores, but the focus is on developing working Arduino-compatible cores for the supported families. The cores are inspired by Espressif's official core for ESP32, which the project says should make it easier to port or run existing ESP apps on less common, unsupported IoT modules. That design decision is the whole thesis of the project. The ESP32 ecosystem is large, and a developer who has written an ESP32 sketch or an ESPHome integration has a large body of code that would otherwise be unusable on a cheaper module. By mirroring the Espressif core's structure and API, LibreTiny lets that code move. There is also an ESPHome port based on LibreTiny, which supports the BK7231 and RTL8710B chips. That is a different philosophy from a firmware framework, and it is covered below. The project is MIT licensed, the primary language is C, the default branch is master, and the recent releases are v1.13.0 from 2026-06-29, v1.12.1 from 2026-02-08 and v1.12.0 from 2026-02-07, with the last push to the repository on 2026-06-29. The documentation is at docs.libretiny.eu. ## What a PlatformIO platform is, and what the repository contains A PlatformIO platform is a package that tells the build system how to compile and flash for a family of boards, and the repository layout is the clearest way to see how many parts that involves. ```text boards/ builder/ cores/ tools/ monitor/ platform.json platform.py families.json external-libs.json ``` The boards/ directory holds the board definitions, which is where a specific module gets its pin map, its flash layout and its upload settings. The cores/ directory holds the Arduino-compatible core itself, and the builder/ directory holds the build scripts that PlatformIO calls to compile and link, which is where the toolchain, the compiler flags and the linker script for each chip family live. The tools/ directory holds the toolchain and flashing utilities, and the monitor/ directory holds the serial monitor configuration, which is what makes pio device monitor work with these boards. The two JSON files at the root are the platform's public description. platform.json is the manifest PlatformIO reads to know what this platform is, and platform.py is the hook that lets a platform do work in Python at build time. families.json describes the chip families the platform supports, and the schema file families.schema.json validates it, and the same pairing exists for external-libs.json and external-libs.schema.json, which describes the external libraries the platform provides. The presence of JSON schema files next to the data files is a small sign of care, because a PlatformIO platform that is misconfigured fails with a confusing error rather than a validation message. The rest of the tree supports the documentation and the project itself. There is a docs/ directory with mkdocs.yml and a SUMMARY.md for the navigation, an examples/ directory with a PinScan example and its own summary, and a descript.ion file, which is an unusual name and appears to be the project's description metadata. The code style is enforced with two tools, which is another small signal: clang-format for the C sources and black for Python, with a .clang-format file at the root and badges for both in the documentation. ## Two ways to build firmware for the same chip The most useful thing the project documentation offers is the choice between two very different approaches, and they are worth comparing rather than treating as a menu. The first is the Arduino-compatible core. You write a sketch or an Arduino-style project, the core provides the API you know from the ESP32 world, and PlatformIO builds and flashes it. The value is that a large body of existing ESP32 code becomes portable, which is the stated goal of the project, and that the build environment is a usable one rather than a vendor script. The second is the ESPHome port, based on LibreTiny, supporting the BK7231 and RTL8710B chips. ESPHome is a different model entirely: you describe the device in YAML and the framework generates the firmware. The documentation for the port is linked directly from the project README, which tells you it is a first-class part of the project rather than an afterthought. The distinction matters in practice. The Arduino path is for a developer who wants to write firmware and control the behaviour precisely, and it inherits the ESP32 API shape, including its concurrency model and its library ecosystem. The ESPHome path is for a developer who wants a device integrated into a home automation system, and it inherits YAML configuration and the Home Assistant ecosystem instead. They also differ in what you own. With the Arduino core you own the firmware and the flash layout. With ESPHome the configuration is the artefact, and a firmware change is an upstream change. Neither of the two is the vendor SDK route, which the project also supports by providing vendor SDKs as PlatformIO cores. That third option is what a developer who needs an undocumented vendor feature or a specific radio behaviour would use, and it is the option with the least help available for it. ## How the project is distributed, and what the community looks like The distribution model is PlatformIO's own, and the documentation badges show where the platform lives. There is a PlatformIO Registry badge pointing at a listing under the publisher kuba2k2, so the platform is installed the way any PlatformIO platform is installed, by naming it in a project configuration. There is a GitHub Actions workflow badge for the documentation build, a last-commit badge, and a Discord invite badge. The registry listing is also what tells you how many users the platform has, and a platform with a registry entry is a platform PlatformIO will keep working with as the format evolves. The GitHub Actions setup is worth noting for a project that produces documentation as well as code, because the docs are the primary interface for anyone using the platform. The workflow is named push-master.yml and builds the documentation, which is the same mkdocs site that the getting started guide points at. The project also carries a hacktoberfest topic, which is how a lot of small hardware projects collect their first contributions, and the repository has a CONTRIBUTING-style structure even though the top-level entries do not include a CONTRIBUTING file. The documentation entry point is a getting started page, and the project links to it with a large Getting started heading in the middle of the README, which is a good sign: for a platform whose audience includes people who bought a module and want it to work, the first thing a reader should find is how to install it and flash something. The overall shape is a small, focused, community-run platform for hardware that has no first-party open source support. That is a real gap, and the project exists to fill it, and the fact that it is an EU-registered community project with a Discord and a registry listing rather than a vendor is the point rather than a weakness. ## Where LibreTiny is the wrong tool The first limit is the chip coverage, and it is absolute. The platform covers BK7231, RTL8710 and LN882H, and a project on any other radio is simply not addressed. That is a small market by the standards of Espressif's chips, and it is the whole scope of the project. The second is the board coverage inside those families. A platform is a family of chips, but a developer has a specific module, and what matters is whether a board definition exists for it, with the right pin map, the right flash size and the right upload method. The boards/ directory is where that is decided, and a module with an unusual pin assignment or an unusual flash configuration can need a board definition written for it. The project does not document how many boards it ships, and that is the number a prospective user most wants. The third is the work-in-progress status, which the project states plainly. For an Arduino-compatible core, that means the API surface is not settled, libraries written against it may need adjusting, and the mapping between ESP32 APIs and the LibreTiny ones is by definition incomplete where the hardware differs. A developer porting an ESP32 project should expect to read the porting notes rather than assume compatibility. The fourth is the licence surface, which is larger than the MIT badge suggests. The project is MIT licensed and states that parts of the code may come from third parties, vendor SDKs or other open-source projects, with most of those files marked with appropriate copyright, author and licence notices. The distinction is honest and the per-file notices are the right practice, but it does mean the effective licence of a given file depends on where it came from, and a commercial product that links a core containing vendor SDK code has to check those files rather than the root licence. And the fifth is the support question, which is inherent to the model. These chips are cheap because nobody supports them commercially, and a community platform is the substitute for that support. The platform exists because the gap is real, and it inherits the risk that the gap can reopen, with the maintainers moving on and the chip vendor issuing a new revision that no board definition covers. ## Conclusion LibreTiny is worth trying if you have bought a cheap wireless module based on one of the supported chips and want to program it with the Arduino toolchain rather than a vendor SDK, because the core is written to be Arduino-compatible, because it is structured as a PlatformIO platform with board definitions and a builder, and because there is an ESPHome port for the same chips if you would rather not write firmware at all. It is the wrong tool if your chip is not on the list, and it is the wrong tool if you need a vendor-supported product. Before you start, check three things: that your module runs one of the three supported families, BK7231, RTL8710 or LN882H, and that a board definition exists for the exact module you have, because the board list in the repository is where that is decided; that you accept the project's own status, since the documentation says this project is work-in-progress and the recent releases are v1.13.0 from 2026-06-29 and v1.12.x from February 2026; and that you read the licence position, because the project is MIT licensed but states that parts of the code may come from third parties, vendor SDKs or other open-source projects, with those files carrying their own copyright, author and licence notices. ## FAQ ### Which chips does the LibreTiny PlatformIO platform support? The platform targets BK7231, RTL8710 and LN882H IoT chips, and the ESPHome port based on LibreTiny supports the BK7231 and RTL8710B chips specifically. The cores are described as inspired by Espressif's official core for ESP32, with the goal of making existing ESP apps easier to port to less common modules. ### What is the difference between the LibreTiny Arduino core and its ESPHome port? The Arduino-compatible core lets you write firmware in the ESP32-style API and build it with PlatformIO, which is aimed at developers who want precise control over device behaviour. The ESPHome port is the opposite approach, where the device is described in YAML and the framework generates the firmware, which suits integration with a home automation system. The project provides both, as well as vendor SDKs packaged as PlatformIO cores. ### How do I get LibreTiny, and where is the documentation? It is distributed as a PlatformIO platform with a listing in the PlatformIO Registry under the publisher kuba2k2, so it is installed the way any PlatformIO platform is. The documentation is at docs.libretiny.eu, with a getting started guide linked from the project README, and the platform itself is MIT licensed. ## Sources - [libretiny-eu/libretiny on GitHub](https://github.com/libretiny-eu/libretiny) - [License: MIT](https://github.com/libretiny-eu/libretiny/blob/master/LICENSE) - [Project website](http://docs.libretiny.eu/) - [README](https://github.com/libretiny-eu/libretiny/blob/master/README.md) - [Releases](https://github.com/libretiny-eu/libretiny/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/libretiny-eu-libretiny