Luos-engine: turning a board of microcontrollers into a set of reusable services

The idea: hardware as a set of services

Luos-engine is described as an open-source lightweight library that manages your hardware products as a collection of independent software features. You can create and share those features with your team, with external developers, or with the wider community.

The emphasis is on independent. The usual way to write embedded firmware is as one program: a main loop, a set of tasks, a shared set of globals, and a build that only works for that board with that sensor set. Everything you write is welded to the product.

Luos-engine's model breaks that. Each piece of functionality becomes a service, a self-contained unit that exposes an interface and hides its implementation, and the services run on separate boards or on the same board without knowing about each other. They discover each other and exchange messages over a network.

The library is usable on any microcontroller or computer with any network, and it is written in C, so the same service can be compiled for an STM32, for a Raspberry Pi, or for a Linux host running a simulation. The project describes the result as enabling free and fast development of multi-electronic-board connected products, and says the point of choosing it is that you can develop, debug, validate, monitor and manage the product from anywhere.

That last phrase is doing more than marketing work. Because the services communicate over a network rather than through shared memory, the same architecture works when the tool doing the monitoring is on a laptop and the code under test is on a board three rooms away, or the other way round.

The primary language is C, the licence is MIT, the default branch is main, and the homepage is luos.io. The last push was on 2026-09-28 with the project not archived. The recent releases are 3.1.0 from 2026-02-19, 3.0.0 from 2023-12-13 and 2.9.2 from 2023-06-19.

The version numbers tell you about the pace of the project

The repository is a small project and the release history says so plainly, so it is worth reading the dates rather than assuming a cadence.

There are three releases listed. Luos Engine 3.1.0 is from 2026-02-19. Luos Engine 3.0.0 is from 2023-12-13, a little over two years earlier. And Luos Engine 2.9.2 is from 2023-06-19, about six months before that.

So the 2.9 to 3.0 step took a long time and 3.1.0 came about two years after it, while the last push to the repository was on 2026-09-28. The project is not archived, and work is still landing, but the published versions are sparse and the recent one is a 3.1.0 rather than a 3.1.1 or a 3.2.

There is also a small inconsistency worth flagging for anyone reading the repository. The line Version: 3.0.0 appears near the top of the repository's own text, while the release list includes 3.1.0 from February 2026. So the in-repository version marker and the newest published release do not agree, which is the kind of thing you notice when a project maintains its version in more than one place.

The topic list gives a better sense of the project's reach than the release history does. It includes arduino, platformio, raspberry-pi, freertos, micro-ros, ros, iot, edge, embedded-systems, cyber-physical-systems, digital-twins, real-time, cicd and communication-protocol. So the same library is expected to run on a microcontroller, on a single-board computer, inside a ROS or micro-ROS system, and on a developer workstation, and the digital-twins topic points at the simulation and test direction the project takes.

The PlatformIO registry badge and the library.json file at the repository root both indicate that the library is packaged for PlatformIO, which is the build system most of the embedded hobby uses, and that is a substantial practical detail: it means the library can be pulled into a firmware project the same way any other PlatformIO dependency is.

How the repository is split

The top-level listing shows four directories that carry most of the weight, and each name describes a layer of the system rather than a set of examples.

engine/ is the core: the library itself, the service model, the message handling and the APIs a service implements. network/ is the transport layer, the part that knows how messages move between nodes, since the claim is that it works with any network, and separating that from the engine is what makes that claim practical rather than aspirational. tool_services/ holds the services that do the supporting work, the ones that sit alongside your application services and provide the shared facilities an application needs. And test/ is the test suite.

Then there is examples/, and the way it is organised is the clearest statement of the project's intent. It has an apps/ directory, a hardware/ directory and a projects/ directory, plus its own README.

Three levels, and they are the three levels a hardware project actually has. apps/ is the application code, the services that do the thing your product does. hardware/ is the board-specific code, the part that talks to the actual sensors and actuators. And projects/ is the whole thing assembled, the configuration that says which service runs where and how they are wired together.

That separation is the practical payoff of the service model. A project directory can be copied to another board, the hardware directory swapped, and the application services stay the same, which is exactly the reusability the project claims when it says many embedded developments start from scratch and you can build on the work already done by you, your company or the Luos community.

The rest of the top-level files are the ordinary ones. There is a platformio.ini for the PlatformIO build, a library.json for the PlatformIO library manifest, a .clang-format and a .clang-format-ignore, which tells you the code is formatted with clang-format and that some files are excluded from it, a source_filter_script.py, and the usual governance files: LICENSE, CODE_OF_CONDUCT.md, CONTRIBUTING.md and CLA.md, the last being a contributor licence agreement, which is a more formal arrangement than the usual code of conduct alone.

What the project is for, in its own terms

The project frames its value for the community in a specific way, and it is a claim about reuse rather than about features.

Many embedded developments start from scratch. By using Luos-engine, you can build on the work already done by you, your company, or the Luos community. The reusability of features encapsulated in Luos-engine services accelerates the time it takes for your products to reach the market while keeping your applications consistent and portable.

So the target is not a single device. It is a fleet. The best practices section puts the same idea differently: Luos-engine promotes organized and effective development practices, ensuring the scalability, flexibility and adaptability of your product from the initial idea to maintaining an industrialized fleet.

The phrase about maintaining an industrialized fleet is the one that explains the digital-twins topic. If you have devices in the field, you need to be able to reproduce their behaviour on a desk, which means the same services need to run against a simulated hardware layer rather than a real one. The hardware/ and projects/ split in the examples is what makes that possible, because the hardware layer is the seam.

The cicd and testing topics point the same way. If a service is a self-contained unit with a defined interface, you can test it on a workstation without hardware attached, and the repository's test/ directory at the top level is where that infrastructure lives.

The getting-started guide lives on the site rather than in the repository, with a tutorial for trying it on your own and a full documentation section, and there is a Discord server for the community.

What you get in exchange is a way of structuring embedded software so that pieces are reusable across boards and across projects, which is a real and often painful problem in the field. The library itself is small, the C codebase is portable by construction, and the PlatformIO packaging means it drops into an existing firmware project without ceremony.

How to evaluate it, and what to check first

There are four things to consider before you adopt this.

First, whether the service model fits your product. It pays off when you have several boards, or several features, or a team where people own different pieces of the firmware. If you are writing one program for one board that will never be reused, the indirection of services and messages will cost you more than it saves, and the same is true for a product with no plan to change hardware.

Second, the release cadence, which is genuinely sparse. Three releases are listed, the last on 2026-02-19, with the one before it from December 2023, and the repository was last pushed to on 2026-09-28. The project is not archived and it is not dead, but there is no train of releases to plan around, so if you adopt it you are adopting a specific version and should be prepared to carry patches yourself for some of the platform work.

Third, what documentation you actually get. The repository itself is short, with the getting started guide, the full documentation and the tutorials all hosted on the site, so you will be reading the site rather than the repository, and the site is versioned separately from the code. The version marker inside the repository still says 3.0.0 while 3.1.0 is the newest release, so check which version the documentation you are reading describes.

Fourth, the ecosystem. The topic list spans Arduino, PlatformIO, Raspberry Pi, FreeRTOS, ROS, micro-ROS and edge deployments, and there is a PlatformIO registry entry with a library.json manifest, so the packaging question is settled. Whether the ROS and micro-ROS integration is what you need is worth checking against the documentation rather than assuming.

The honest summary is that this is a well-designed small library for a specific architectural style, with an MIT licence, a portable C core, a separated network layer, and a good example organisation that makes the model concrete. It is most valuable to a team building multi-board products or maintaining a fleet, and least valuable to someone who just wants one board working, and the thin release history is the main practical risk in depending on it.

Editorial conclusion

Adopt Luos-engine if you build multi-board embedded products or maintain a fleet in the field, since splitting firmware into independent, reusable services is the problem it is designed around and the examples directory shows exactly how to organise that. Do not adopt it for a single board that will never be reused, where the service indirection and message passing will cost more than they save, and plan for the sparse release history, because the published versions number three with the newest from 2026-02-19 while the last push was on 2026-09-28. Before you commit, check which version the online documentation describes, since the version marker inside the repository still reads 3.0.0, and confirm that the PlatformIO package and the ROS or micro-ROS integration match the toolchain and the rest of your stack.

Frequently asked questions

Official sources

1. License: MIT
2. Luos-io/luos_engine on GitHub
3. Project website
4. README
5. Releases