When I said I “installed” DeviceScript, you might have thought this was a complicated process. It’s not.
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.