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.

Key takeaways

• Customer-specific changes implemented directly in firmware can require separate software versions, additional testing and repeated updates across deployed devices. Maintaining these variations becomes increasingly demanding as the number of devices and projects grows.
• A scriptable architecture separates core device functions from customer-specific logic. Scripts can modify supported device behaviour without changing the underlying firmware, provided the required functions are available through the scripting interface.
• ACRIOS uses a three-layer software architecture: a bootloader responsible for start-up and firmware updates, firmware that manages core device functions and provides an API, and Lua scripts that use the available functions to implement application-specific behaviour.
• The same hardware and firmware can support different use cases through different scripts. Depending on the device and its scripting API, changes to reading intervals, data processing or supported output formats may be possible without modifying the firmware. Scripts can be updated in the field or remotely where supported.
• Password protection and access controls can help protect customer-specific scripts from unauthorised access. However, technical safeguards and contractual arrangements both matter when protecting proprietary functionality and customer know-how.
• Customers do not necessarily need programming skills to benefit from scripting. The manufacturer can develop and maintain scripts for them, while technical teams can use the documented scripting API to implement and manage their own custom logic.

‍

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.

Glossary of terms used

• API (Application Programming Interface): a defined set of rules that allows software systems to request or exchange data and functions
• Bootloader: software that runs when a device starts, initialises the system and loads the main firmware; depending on its design, it may also support firmware updates
• Firmware: software that controls a device’s hardware and basic functions, often operating at a low level
• Flashing: writing firmware or other software into a device’s memory, which in some cases requires physical access to the device
• GUI (Graphical User Interface): a visual interface that lets users operate software through windows, buttons and menus rather than code
• Intellectual property (IP): legal rights relating to creations such as software, designs and documentation, including rights that govern their use, modification and distribution
• Lua scripting: executing scripts written in the Lua programming language to customise supported device behaviour without modifying the underlying firmware
• NB-IoT (Narrowband IoT): a cellular low-power technology running in mobile operators’ licensed networks, suited to devices that send small amounts of data
• Proprietary protocol: a communication protocol owned and controlled by a single company, whose specification may not be publicly available
• Scriptable device architecture: a design in which core functions are handled by the firmware, while customer-specific behaviour is defined in a separate script layer
• Scripting API: the set of functions that the firmware makes available to scripts, defining what a script can read, control or change on the device