Scripting in IoT: Flexibility, sustainability, and protection

One of the common challenges in deploying IoT devices in real-world projects is the need to modify firmware every time the customer requires a specific behaviour. Whether it’s a different reading interval, support for a proprietary protocol, or a change in how the data is filtered, such modifications typically require a new firmware version, new testing, and often even physical re-flashing of the device. This approach is unsustainable in the long run, especially if you’re deploying hundreds or thousands of devices and want to keep using a stable, tested version.

One proven method to avoid this scenario is to adopt a scriptable device architecture. In other words, keep the core logic within the firmware, but allow the customer to define specific behaviours through a script – a separate layer that doesn’t interfere with the system’s core, but can influence it.

You can think of it as an API connector layered on top of a software solution: you can work with it in ways other than the standard GUI (e.g., via scripting), but without the risk of introducing a critical bug into the system software.

Three-layer architecture: how we design devices at ACRIOS

At ACRIOS, our devices follow a structured architecture with three software layers:

• Boot loader: Responsible for safely starting the device and updating the next layer (firmware) when needed.
• Firmware: The core software that manages all device functions and executes actions requested by the user layer.
• Script: The top layer that executes user-defined actions. It acts as a “program inside a program” – the firmware exposes an API, and the script calls specific functions through it.

The script is written in a lightweight yet powerful language, in our case, Lua. It gives customers control without needing access to the system layers. For instance, you can flash a different script into each device already during production, tailored to the specific customer or use case. The physical device remains identical, but the behaviour varies with zero additional work required at deployment.

Faster change, shorter cycle, easier maintenance

This scripting architecture gives users the ability to react quickly to changes in requirements, environments, or even legislation. Reading intervals need to change? Data formatting requirements evolve? A new export method is needed? All of this can be done by updating the script. Remotely or directly in the field. The firmware remains untouched, testing becomes easier, and the development cycle is much shorter.

Protecting customer know-how

Scriptability also brings an important benefit in terms of protecting your intellectual property. Imagine a situation where a customer commissions specific device behaviour that requires significant development. If that logic is baked directly into the firmware, the manufacturer may later reuse it elsewhere, repurpose it for another customer, or start offering it as a standard product feature. In the end, the know-how the original customer paid for is no longer exclusive, and their competitive advantage is gone.

With a scriptable device, however, the customer can commission a custom script and protect it with a password or access control. The functionality remains theirs – inaccessible to others unless they choose to share it. That’s one reason why many of our partners now request scripting as a standard capability.

You don’t need to code

Scripting doesn’t mean you’ll have to become a programmer. On the contrary. The ideal setup is when the manufacturer provides a custom script, and the customer can make adjustments via a user-friendly interface. That’s exactly what we’re working on at ACRIOS. To let our customers configure scripts without needing to understand every line of code.

But if you do have a technical team that prefers to write and maintain scripts themselves, we offer full support and open access. We believe that if you own the device, you should also have full control over what it does. Our scripting API is publicly available here.