Microsoft last month introduced DeviceScript, a sub-set of the company’s TypeScript programming language, specifically for the IoT. DeviceScript apps are meant to bring a more modern coding approach to small connected devices that run on microcontrollers. Given my ongoing development education, I took a brief look at DeviceScript by installing it and running through some of the code examples. I can already say that I’m probably never going to code an IoT prototype on an Arduino board using that hardware’s native coding language again. If you’re a JavaScript or TypeScript developer already, you’ll like what Microsoft has created here.
When I said I “installed” DeviceScript, you might have thought this was a complicated process. It’s not.
That’s because DeviceScript is packaged as a Visual Studio Code extension, not as a standalone environment. Like many JavaScript or TypeScript apps, it leans on Node.js, which is a runtime environment for those two similar coding languages. Since I’m learning to code in JavaScript, I already had Node installed. All I needed was the DeviceScript extension and one Terminal command to install the DeviceScript CLI or command line interface.
This process took me less than a minute. And from there, getting started was a keyboard shortcut to see the DeviceScript commands available and choosing the one to create a new project.
By using the DeviceScript command to create a new project, the extension builds a project, complete with all of the required files and folders to get going. It’s definitely a more modern, simple approach that anyone who builds prototypes with breadboards or dev kits will appreciate. The necessary code “scaffolding” is built for you.
Since I don’t currently have any Raspberry Pico or ESP32 boards lying around, I thought I might be stymied at this point. The whole point of DeviceScript is to create code that can read or write commands and data to connected devices. Without either supported microcontroller board, I’m out of luck, right?
Nope! The DeviceScript extension includes a device simulator with dozens and dozens of virtual devices. Looking through the choices, I see light bulbs, LEDs, and a range of sensors including humidity, motion, and temperature to name a few. To get started, I ran through the LED blink example code and simulated a LED.
This is definitely a basic example project but it provides a quick understanding of DeviceScript’s power and simplicity. Here you can see the code along with the simulated LED when I run the project. This code switches the LED state between on and off every 200 milliseconds. Note that the default code changes the state every 1,000 milliseconds, i.e. every second; I modified it in the below image.
Even if you’re not a coder, you can probably understand the gist of the sample code. That’s one of the benefits of using a commonly-used modern language. I can see, for example, that a variable called “brightness” is created to hold the value of the LED bulb’s intensity. For simplicity’s sake, an intensity value of “0” means the LED is off. Any other value means it is on. And that’s where the “newbrightness” level comes into play.
The value of “newbrightness” looks at the current value of “brightness”. If the brightness value (the current state of the LED being on) is greater than zero, the new brightness is assigned the value zero. If the brightness value isn’t greater than zero (meaning the bulb is on), the new brightness is assigned the value of .5, which is a signal to turn the bulb on. Lastly, on line 17, the new brightness value is written to the bulb and stays that way for 200 milliseconds. Simplified, this is how the LED bulb is switched from on to off and from off to on.
Again this is a basic example, but there’s more. Built into the Visual Studio Code programming environment is a way to watch for data or values in real-time. The above image shows this during the running simulation as I’ve set up a way to watch this in the left pane, under “Watch”. Sure, in this case, that value is just flipping between a 0 and a 1 to indicate on or off. But now apply this concept to more complex programs and devices.
If I simulated an RGB bulb, for example, I could see the bulb’s color value in real-time. I could create custom color themes using DeviceScript and simulate those, watching to see if the color value properly changes to the colors I programmed. Or I could read values from a thermostat or humidity sensor and then use them to test code that takes action upon a certain temperature or percentage of humidity.
That’s a huge benefit if you’re a developer for connected devices, You don’t always get such tools to see data in real-time; at least not unless you code your own outputs to view them. And you typically have to compile your code before you can actually run it. That’s the process where the code you typed is rewritten in a low-level language your IoT hardware can understand. DeviceScript does this for you and it does it on the fly. I can change and save my code file, then immediately run it.
Of course, simulations are just that: simulations. You’re not going to push code from a simulation to already deployed devices in people’s homes. However, you can connect devices to DeviceScript for testing and flash your code to the microcontroller.
I noted that the Raspberry Pi Pico and ESP32 products are supported by DeviceScript. So too is the wireless card in the Blues Wireless LoRa dev kit that I reviewed back in September. That’s my next step now that I know how powerful, yet accessible, DeviceScript is. I plan to try Microsoft’s modern coding platform with the Blues hardware to create another LoRa network and read sensor data from that hardware.
In the meantime, if you’re a device maker or an IoT tinkerer, I highly recommend taking DeviceScript for a spin. While you’ll get the most benefit from coding for actually connected hardware, you can simulate a wide range of devices on day one. You’ll also likely get your code running faster and have a more detailed, real-time look at how it’s working, and what it’s doing to, the IoT device you’re building.
Would it be possible to use devicescript for some matter-related smart home applications?
Did we need another language?
Or if this yet another msoft solution seeking a niche?
Not really either. This is trying to address a very specific industry issue. Take a company that creates a large number of tiny low power devices, like the parts of a solar energy system.
Writing code for those particular devices tends to be hard because most programmers don’t know how to write for such a highly constrained environment. Every byte counts.
But there are a lot of programmers who already know how to use typescript. If you could give those folks a tool that required very little retraining, but that kept everything to the very limited code size required for these sorts of applications, it would vastly expand the potential labor pool. That’s the industry problem that devicescript is supposed to help solve. Not the technical aspects of the language itself but the fact that there are already a lot of programmers who will be comfortable using it.
Note that this is a VM architecture. It’s going to run about 10 times slower than native architecture maybe even 100 times. Again, it’s not trying to solve a technical problem. It’s basically a typescript frontend to a JavaScript VM for highly constrained microcontrollers.
As one of the devicescript developers recently said:
“note that high performance is not the primary goal here – the goal is good developer experience. ”
As far as Matter, eventually they could add types That would be matter compliant, but the little devices this is intended for probably aren’t going to have IPv6 addresses, or do that kind of networking. They’d need to be connected to a bridge. So maybe someday, but not now.
Devicescript has been a topic of conversation on the IEEE and hacker boards for about a month. I don’t know anyone who is intending to use it as a starting language for a project for themselves. There are just a lot of other language options already. But the HR managers are really excited about it.
The official Microsoft docs go through the differences between Typescript and DeviceScript. It’s all about constrained resources. For example, it uses Unicode not UTF-16.
https://microsoft.github.io/devicescript/language
Also, for those asking about Matter, note that DeviceScript is intended for programmers writing firmware for a device which IS a sensor, not for a device which is talking to another device which is a sensor. I’m struggling to think of a use case where Matter would be applicable: as I mentioned before, I think if needed that would be handled with a bridge that the device using code created with DeviceScript would connect to.
I don’t really understand what the comments in the article referring to real time reporting as a feature are all about. Most languages offer logging already, and what DeviceScript offers is no more “realtime“ than any other buffered observable. In fact, it’s just a subset of RxJS. Nothing new there. It could still be several minutes or even hours before the device reports, depending on how it’s configured. (this is usually a sleepy device issue designed to save battery life.)
So, sure, it’s easy to turn on logging in DeviceScript but that doesn’t mean it’s hard to do in other languages.
Back to the announcement: speaking, just for myself, I’d almost certainly choose Rust over DeviceScript for any personal project because of the greater efficiency. But if I were setting up a new team with 100 programmers that I hadn’t hired yet, DeviceScript would let me widen the candidate pool considerably, so I understand the appeal.
Sorry, voice dictation dropped a phrase. My bad. That should have been
It’s easy to turn on logging or subscribe to events in DeviceScript, but that doesn’t mean it’s hard to do in other languages.
Here is the official Microsoft documentation which confirms DeviceScript’s observables management is just a subset of RxJS.
https://microsoft.github.io/devicescript/api/observables