This is the first is a series of posts, entitled “The PowerShellToolbox,” where I'll be talking about everyone's favourite shell/scripting language. I'm assuming a lot of you will at least have heard of it, and there will also be some fanatics out there, so I thought it might be of interest if I covered some aspects that come up in my role as a sales engineer. Specifically, I learned many of these lessons when I wrote the PowerShell Module based on the SDK.

 

These will include topics such as:

  • Reusing scripts by making them into cmdlets and modules
  • How to properly test your scripts using Pester
  • Creating a PowerShell jumpbox
  • A look at Desired State Configuration

 

... and many more. I'm writing this series based on the assumption that you, the reader, have a certain level of experience with PowerShell. For those wanting to learn the basics, I couldn't recommend enough the excellent training videos Jeffrey Snover and Jason Helmick created over at Microsoft® Virtual Academy. To begin with, we'll look at a project I've been thinking of for a while, and over the coming weeks iterate the solution, beginning today with a high-level planning phase. We’ll then move on to some basic cmdlets, before adding those to a module. Along the way, we'll also look at using unit testing for the scripts, error handling, and source-control. While the code here is specific to a use case for me, the overall goal is to show you how to take an idea, convert it to PowerShell, and then build it into a robust tool in your arsenal.

 

The Scenario

I work from home and while I'm usually the only one in the house, there are times when it's obviously useful to have some sort of indicator as to whether the door to my office is closed due to the fact I'm on a call (and "do not disturb") or whether it's okay to pop in. While trying to find  a solution, I stumbled across Scott Hanselman's blog on using a Kuando Busylight. Essentially, it's a USB light that indicates presence based on your Lync® presence, but it can also work with other technologies. There are Alpha and Omega models, but given there wasn't much of a price difference on Amazon®, I went for the Omega. And by pairing it with a 5m USB extension cable, I should be able to locate it outside my office.

 

However, some of the technologies I use aren't supported, so I want to have a way to manually control the colour. While there is a manual sample app for this, I want to be able to script these changes, since I use some PowerShell scripts to configure certain workflows on my system—like when I'm running a WebEx®, I'll connect to another network and ensure that certain apps are not running—and I want to be able to control the device from PowerShell.

 

Buslyight and Jabra headset

Busylight alongside Jabra headset for perspective

 

PowerShell for Busylight

  Fortunately, there is also a

Busylight SDK available (I'm using Vers

. 3.0.0.6), and while it ships with C++, C#, and VB code samples, a really strong feature of PowerShell is that it’s easy to expand its reach by using objects designed for other technologies. I'm not going to do a huge amount of coding today, but just for a quick proof of concept, I want to very quickly just do something basic—like setting the color to blue—from PowerShell. Once I download and install the SDK, the next step is to look at the included help file documentation, and I note there are a few classes: busylightcolor, busylightdevice, PulseSequence, and SDK. That might be of interest.

Help File.png

Busylight SDK  Help

 

At this stage, don't panic if you don't know what constructors, methods, and properties are; I'll explain as we go along. In my case, I'm fortunate that I also have a basic understanding of some programming concepts—I've worked with C, C++, and Java, as well as various VB & FoxPro applications I developed in previous roles—but the key thing I noted that in the "SDK" class is that it is described as “This class handles all connected Busylight Devices,” so it seems like a good place to start.

1. I'll load the DLL, so that PowerShell knows what code I want to use (the "add-type" line)

2. Next I'll create a new object, which from the documentation, is in a namespace called "Busylight" (tab-completion will help!), and I assign this to a $BusyLightDevice variable. (Just in case you're interested, at this stage the "constructor" that you see is called implicitly, so you don't have to worry about it)

3. And finally, I'll just now check the variable, to make sure it's connected, and sure enough we're now seeing info.

PowerShell to Connect to Busylight

 

And to set the color, again only 3 lines of code.

PowerShell to set the colour

 

Blue Busy Light

This time, however, we are now creating a color object that the busylight can interpret, has just blue set to max, and the rest to 0. This Busylightcolor object is then used as a parameter by the "method" called "Light" in the SDK class. (To get technical: in a class a method "does" something, like setting or reading a value, while the value of something, such as the BlueRGBValue in the Busylightcolor class, is called a "property.")

ViewColor.png

By setting the different red, green, and blue combinations as RGB values we can now set different colors. So if I now add in red, and check the settings:

CodeForPurpleBusyLight.png

 

And as we can now see, we have a purple!

Purple Busy Light

 

Wrap Up

In the next post, I'll iterate on the above code by writing some functions that will allow us to reuse the code in multiple places. But in the meantime, I'd love to hear if you've already begun working on a toolbox with these types of scripts. If you have any feedback on things you'd like to see in future posts, please let us know!

 

Exit-PSSession "Blog Post"