12/28/2023 0 Comments Smartthings audifyYou can visit the SmartThings Community to learn more about integrating your Zigbee, Z-Wave, and LAN devices with SmartThings Edge. 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. Lua itself provides some opportunities to tweak and limit the runtime. 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. 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. Historically, all locally executing DTHs were either written or reviewed by our engineering teams. 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. 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). 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. It is responsible for managing many aspects of how devices connect and execute within the SmartThings platform. It should not come as a surprise that the SmartThings hub platform software is a complex system. Additionally, as an interpreted language, developers building Edge Drivers do not need to worry about compiling their code. With the core language being pretty small, it is pretty easy for developers to learn. This leads to a small footprint, which works well for executing on hubs. Lua has a small set of core structures and functionality. With the need for users to potentially run many Edge Drivers at a time, we were looking for something lightweight. The Hub is a resource-limited environment. As you may have guessed from the title, Edge Drivers are built around Lua © as the programming language. We set out to engineer a solution that would be able to deliver the developer and user experience that we were looking for. 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.” 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. With the ongoing work to modernize the platform and move away from legacy systems, we wanted to provide a better way to handle devices. While Groovy DTHs helped us launch SmartThings, they presented special challenges for local execution on the hub. These were written in Groovy and would run in a sandboxed environment on the SmartThings Cloud. For Hub Connected devices we have always used Device Type Handlers (DTHs). Last month, we announced the launch of SmartThings Edge! Looking back, SmartThings provided a few different ways to integrate devices onto the platform. By Patrick Barrett, Robert Masen, and Zach Varberg How we got here
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |