Why We Chose Lua for SmartThings Edge Drivers

[Samsung Newsroom]

By Patrick Barrett, Robert Masen, and Zach Varberg

How we got here

Last month, we announced the launch of SmartThings Edge! Looking back, SmartThings provided a few different ways to integrate devices onto the platform. For Hub Connected devices we have always used Device Type Handlers (DTHs). These were written in Groovy and would run in a sandboxed environment on the SmartThings Cloud. While Groovy DTHs helped us launch SmartThings, they presented special challenges for local execution on the hub.

With the ongoing work to modernize the platform and move away from legacy systems, we wanted to provide a better way to handle devices. Similar to DTHs, we looked to provide a way for developers (both internal staff and partners) to define the behavior of a Hub Connected device through some combination of data and code. Given that one of our primary goals is to support the execution of these on hubs—which we see as the edge of the SmartThings platform—we decided to call these “Edge Drivers.”

We set out to engineer a solution that would be able to deliver the developer and user experience that we were looking for. As you may have guessed from the title, Edge Drivers are built around Lua © as the programming language... So why Lua?

Simple

The Hub is a resource-limited environment. With the need for users to potentially run many Edge Drivers at a time, we were looking for something lightweight.

Lua has a small set of core structures and functionality. This leads to a small footprint, which works well for executing on hubs. With the core language being pretty small, it is pretty easy for developers to learn. Additionally, as an interpreted language, developers building Edge Drivers do not need to worry about compiling their code.

Embeddable

It should not come as a surprise that the SmartThings hub platform software is a complex system. It is responsible for managing many aspects of how devices connect and execute within the SmartThings platform. Most of this software is written in Rust and C (stay tuned for more on this in the future!) and we needed something that would work well in this environment.

When looking for solutions, we began by investigating “prior art” to answer the question: Are there other complex systems out there that needed to solve a similar problem, and if so, what did they do? We have a set of core functionality that needs to execute in a performant manner (HubCore), but want to allow extensions that give developers the tools to build unique use cases (Device Drivers).

We found that Lua had been extensively used in the video game industry (along with other non-video game software) as a way to allow developers to extend existing functionality—which is exactly what we were looking for! This means that Lua could work well with C and Rust, allowing your Hub to run extensions with a minimal impact to the existing hub software.

Safe

Historically, all locally executing DTHs were either written or reviewed by our engineering teams. Allowing users to run code locally on their hub that we did not write, review, and test brings up complex questions about boundaries and guardrails. As a result, it was important to identify a solution that we could sandbox—that is, lock the untrusted code in a room where it cannot hurt anyone else.

Lua itself provides some opportunities to tweak and limit the runtime. In addition to this, we wrap all Device Drivers in a second, more secure sandbox layer, with a coherent API to further protect hubs in instances where we did not believe the built-in options were enough.

Learn more

You can visit the SmartThings Community to learn more about integrating your Zigbee, Z-Wave, and LAN devices with SmartThings Edge. Lua is free software distributed under the terms of the MIT license. If you want to learn more about developing with Lua, we recommend getting involved with the Lua Community.

View the full blog at its source