Scripting in IoT: Flexibility, sustainability, and protection

Why separating core firmware from customer-specific logic makes your devices easier to maintain, update, and adapt. Without compromising reliability or intellectual property.

Many IoT deployments fail when each new customer request requires a firmware change. Scripting solves that by separating customer logic from core functions, it enables faster updates, long-term maintenance, and secure control over unique features.

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.

FAQs about scripting in IoT

What exactly do you mean by “scripting” in IoT devices?

Scripting refers to an additional software layer that allows custom logic to be executed on the device, without touching the core firmware. In ACRIOS devices, this layer is written in Lua and can control behaviour like data filtering, frequency of readings, or protocol-specific handling, while keeping the firmware stable and secure.

What are the benefits of separating firmware from user logic?

It allows the same tested firmware to be deployed across many installations, while still meeting individual customer needs. You reduce maintenance risk, shorten the development cycle, and avoid repeated firmware updates. Plus, custom behaviour can be tailored quickly at site or remotely.

How does scripting help protect customer know-how?

Unlike embedded firmware logic, which is often reused across projects, scripts can be delivered per customer, password-protected, and remain isolated. This ensures the intellectual property embedded in the custom functionality stays in the customer’s hands.

Do customers need to write or edit scripts themselves?

Not necessarily. Scripting doesn’t mean customers must become developers. ACRIOS offers custom scripts tailored to each use case. In the future, a simplified configuration interface will allow editing basic parameters without touching the code.

Is scripting only for advanced users?

While the full scripting interface is ideal for integrators or power users, the design of ACRIOS devices makes scripting usable even for those without programming experience, especially when delivered with preconfigured templates.

Can scripts be updated remotely?

Yes. Devices support remote script updates over NB-IoT, in addition to local configuration via optical head. This allows integrators to react quickly to changing requirements without physical access to the device.

Where can I learn more about the scripting API?

The full scripting API documentation is available here.

Ready to script your own logic? Whether you're an integrator looking to customise behaviour across hundreds of devices, or a customer who needs a tailored solution without waiting for firmware updates — scripting gives you the flexibility, speed, and control to do just that. Get in touch.
No items found.
Blog
Slash header ACRIOS Systems brand
I will be happy to discuss everything with you.
Lukáš Smetana
CSO
Thank you for your inquiry. We will address it as soon as possible.
Oops! Something went wrong while submitting the form.