Coding4Fun : home automation

Shutdown/Restart/Logoff your PC using TweetMyPC

Coding4Fun — Tue, 23 Jun 2009 22:01:00 GMT

In this article I will show you how you can use Twitter API to Shutdown/Restart/Logoff your PC remotely using VB.net.

Compiled version: CodePlex.com
Source Code: Codeplex.com
Difficulty: Beginner
Time Required: 2 hours
Cost: Free
Software Needed: Visual Basic or Visual C# Express
Libraries: Yedda Twitter Library

Introduction

I have a very slow internet connection at home and most of the time Downloads takes hours to complete. I decided to write an application which will help me Shutdown my PC from a remote location. I wanted to use it to shutdown when I go out when some downloading is going on in my laptop. Instead of using a server and client architecture I decided to use Twitter API and use “My Timeline” to supply commands. One other reason to use Twitter is that I will be able to tweet from my mobile as well. I don’t need to look for a computer with an internet connection when I am on the move.

Why Yedda Twitter framework?

The Twitter REST API methods allow developers to access core Twitter data. This includes update timelines, status data, and user information. It’s very easy to connect to Twitter and get user time line using .net. But I dint wanted to reinvent wheel and decided to use an existing Twitter library. Yedda Twitter framework is the best open source Twitter library available in the internet. You can learn more and download the library from yedda’s home page.

Designing the Interface

I wanted the interface to be as simple as possible. Below is the screenshot of TweetMyPC’s interface which does not have more than 2 Text Boxes, 1 Check Box, Label and a Button.

The form also has a Notify Icon, Context Menu Strip and a Timer. Following are the names of all the controls in the form.

From : frmTweetMyPc
Text Boxes : txtUserName, txtPassword
Button : btnSave
Check Box : chkStartAutomatic
Timer : tmrTweet (Interval : 10000)
Label : lblSatus

There are few My.settings properties to store user information. These properties are shown below.

The Code
Add the following code which minimizes the Form on Load and Enable Timer to check for Tweets every 1 minute.

Me.WindowState = FormWindowState.Minimized
Me.ShowInTaskbar = False
tmrTweet.Enabled = True

The following code in Button’s Click event will validate Twitter username, Password and save it to My.Settings.

If txtUserName.Text.Trim = "" Then
    lblSatus.Text = "Please enter Twitter Username"
    txtUserName.Focus()
    Exit Sub
End If
If txtPassword.Text.Trim = "" Then
    lblSatus.Text = "Please enter Twitter Password"
    txtPassword.Focus()
    Exit Sub
End If

lblSatus.Text = ""


'Check for valid Username and Password and then Save Settings
Dim objTwitter As New Yedda.Twitter
Dim Updates As XmlDocument

Try 'Try Logging in
    Updates = objTwitter.GetUserTimelineAsXML(txtUserName.Text.Trim, txtPassword.Text.Trim)
    My.Settings.UserName = txtUserName.Text.Trim
    My.Settings.Password = txtPassword.Text.Trim
    Me.WindowState = FormWindowState.Minimized
    Me.ShowInTaskbar = False
    tmrTweet.Enabled = True
Catch ex As Exception
    MsgBox("Failed to Login to Twitter with the values supplied. Please check your login details.")
    txtUserName.Focus()
    Exit Sub
End Try

Yedda library is used to login to Twitter to check for valid username and password. The Label lblSatus is used to display any error messages.

Add the following code to the Checkbox’s CheckChanged event which will add the required registry keys to start this app on Window’s startup

If chkStartAutomatic.Checked = True Then       My.Settings.AutomaticStart = True
      Dim regKey As RegistryKey
      regKey = Registry.CurrentUser.OpenSubKey("Software\Microsoft\Windows\CurrentVersion\Run", True)
      regKey.SetValue(Application.ProductName, Application.ExecutablePath)
      regKey.Close()
Else
      My.Settings.AutomaticStart = False
      Dim regKey As RegistryKey
      regKey = Registry.CurrentUser.OpenSubKey("Software\Microsoft\Windows\CurrentVersion\Run", True)
      regKey.DeleteValue(Application.ProductName)
      regKey.Close()
End If

The following code in Timer’s Tick event will do the job of checking Twitter Timeline every one minute and Shutdown/Restart/Log off the system based on the Tweet.

If My.Settings.UserName.Trim = "" Then
    Exit Sub
Else
    'Check for new Tweet 
    Dim objTwitter As New Yedda.Twitter
    Dim Updates As XmlDocument
    Dim node As XmlNode
    Try 'Try Logging in
        Updates = objTwitter.GetUserTimelineAsXML(My.Settings.UserName.Trim, My.Settings.Password.Trim)
        Catch ex As Exception
        MsgBox("Error : Failed to Login to Twitter with the values supplied. Please check your login details.")
        Exit Sub
    End Try
    Try
        node = Updates.SelectSingleNode("/statuses/status/id")
        If node.InnerText.Trim <> My.Settings.LastID.Trim Then 
            'Compare the Tweet ID to check for new tweets
            My.Settings.LastID = node.InnerText.Trim
            node = Updates.SelectSingleNode("/statuses/status/text")
            ProcessTweet(node.InnerText.Trim)
          End If
    Catch ex As Exception
        Exit Sub
    End Try
End If

If the Tweet is new then we process the tweet.

Private Sub ProcessTweet(ByVal Tweet As String)
    If Tweet = "Shutdown" Then
        System.Diagnostics.Process.Start("shutdown", "-s -f -t 100") 'Shutdown
    ElseIf Tweet = "Logoff" Then
        System.Diagnostics.Process.Start("shutdown", "-l -f -t 100") 'Logoff
    ElseIf Tweet = "Restart" Then
        System.Diagnostics.Process.Start("shutdown", "-r -f -t 100") ' Restart
    End If
End Sub

The Context Menu strip has two menu items. They are Edit Setting and Exit.

Add the following code the “Edit Settings” Client event and Notify Icon’s Mouse Double Click Event.

tmrTweet.Enabled = False
txtUserName.Text = My.Settings.UserName.Trim
txtPassword.Text = My.Settings.Password.Trim
If My.Settings.AutomaticStart = True Then chkStartAutomatic.Checked = True
Me.WindowState = FormWindowState.Normal
Me.ShowInTaskbar = True

TweetMyPC runs silently on startup. To Edit Settings double click/Right Click the notify icon.

Working

Conclusion

Even though TweetMyPC is a simple app it has lot of interesting potential. Think about switching off your TV or washing machine using Twitter. It is possible with a little extra hardware and a simple .net program. TweetMyPC is free and open source. Feel free to download the sour code and add more functionality.

About The Author

Shoban Kumar is a Senior Software Engineer working for Allianz Cornhill India. Programming is his passion. He also writes about .net in http://www.dotnetcurry.com/ and an active participator in stackoverflow and speaker in Microsoft user group sessions. You also can follow him in Twitter.

Controlling Your Festive Lights with the .NET Micro Framework

Coding4Fun — Fri, 28 Nov 2008 07:58:46 GMT

Author:	Rob Miles: www.robmiles.com
Download:	http://coding4fun.net/source/festivelights1.0.zip
Software:	Visual Studio 2008 Express Edition or better, .NET Micro Framework 3.0
Hardware:	Digi Connect-ME GHI Electronics Embedded Master Devices Solutions Tahoe II
Time Required:	3 hours
Cost:	30 dollars for lights plus the .NET Micro Framework device

The Micro Framework is one of the newest kids on the .NET block, but it does something really rather wonderful. It brings embedded development within the reach of any C# programmer. If you know C# and love Visual Studio, you can now get started building hardware and controlling it with your software. Moreover, it lets developers achieve one of their most cherished dreams, to control their festive lights using programs that they have written. This project shows you how to do just that and adds an extra magical feature, in that you can make all your festive lights flash red whenever I, Rob Miles, make a new post on that most famous of blogs, www.robmiles.com.

Actually, you can modify the code so that you can make your lights do most anything in response to an event that happens on the web. You could signal home that you are running late, send the weather forecast to your Christmas tree or explore any number of communication options. You might decide that this is so useful that you leave your decorations up all year round.

If you just want to play with the .NET Micro Framework and get a feel for how easy it is to create software for tiny devices you don't actually need to use any extra hardware at all. The project comes with a complete emulation of the lights display so that you can run the whole thing on your computer and learn how hardware and software can be made to work together without burning your fingers with a soldering iron.

However building the hardware will give you an understanding of how some simple electronic components can be controlled from C# and even how serial and parallel data transfer works. It is also great fun.

To get started you will need some hardware and some software. Let's take each in turn.

Hardware

Processor Hardware

The .NET Micro Framework lets you run C# programs on tiny embedded devices. There are a number of these available today, and they are getting progressively cheaper. You can base this project on any.NET Micro Framework device that has a network port and three or more output ports. The ones I'd recommend are:

Digi Connect-ME: http://www.digi.com/products/embeddedsolutions/digiconnectme.jsp
GHI Electronics Embedded Master: http://www.ghielectronics.com/embeddedmaster.php
Devices Solutions Tahoe II: http://devicesolutions.net/Products/Tahoe.aspx

I built the project for Digi Connect board but the code can be customised for any of the above platforms. The beauty of the .NET Micro Framework is that you hardly need to change your program even if the underlying hardware is completely replaced. The only thing you will have to do is adjust the code to target different output pins. I'll flag this part of the program up when we get to it.

The project as supplied runs on a special emulator that runs on the PC and behaves like a .NET Micro Framework device with lights connected, so you can get started exploring the code right away.

Lights

I'm keeping things deliberately low voltage for this project. This means that kids of all ages can have a go at building the hardware without messing around with mains. The lights that I used were supplied as lines of twenty leds wired up as four strands of five leds each. All the leds in each strand were the same colour. The lights were fitted with a little battery box which held three AA batteries and a tiny controller. To get my display I simply removed the battery box and connected the strands to my hardware.

Figure 1: My Battery Powered Lights

You can do the same with any low power lighting kit that you wish to use. The drivers that I'm using can handle around 500 milliamps of continuous current and so you can connect a fair number of lights to each strand.

Buying the Lights

The lights I used can be bought in the UK from Lights4Fun: www.lights4fun.co.uk and are called "C-LED-4.5-M 20 Multi Coloured Battery Operated LED Fairy Lights". They are supplied with a battery box and controller that you can remove to connect to the Darlington drivers. I used an old 5 volt mobile phone charger to power the lights. If you search eBay for "led christmas lights battery" you should find plenty of suppliers.

Driver Hardware

We can't connect a .NET Micro Framework device directly to our lights. There are two reasons for this:

The Micro Framework device will not be able to switch the amount of current that we need to drive the lights themselves.
The Micro Framework device will not have enough outputs to control all the lights that we want to use.

This means that we need to make some hardware that goes between the processor and our lights. I actually don't see this as a problem. Making hardware is great fun, seeing something that you've built spring into life is very nice. The hardware we are going to use will provide a means by which we can control many hundreds of lights from a single Micro Framework board if we wish. It also has the ability to switch reasonable amounts of current, so you can use quite large numbers of lights if you wish. We are going to use two semiconductor components, a CD4094 Shift Register/Latch and a ULN2803 Octal Darlington Driver. A pair of these chips will allow us to control 8 outputs. If you want to control more outputs you simply get more chips and chain them together. For my version of the project I just used one of each chip, you can use as many as you like.The shift registers and Darlington amplifiers can be obtained in the UK from Maplin: www.maplin.co.uk. The chip numbers and part numbers as are as follows: QW54J 4094 Shift Register, QY79L ULN2803A Darlington Driver. In the US you can obtain the components and breadboard from Digi-Key: www.digikey.com.

Serial and Parallel Data

You might be wondering how we can use just three output lines to control lots of lights. We are going to do this by using the three output lines to provide a serial data stream which is converted by our hardware into parallel data that can be used to control our lights. This is a fundamental principle of digital electronics and is how, amongst many other things, computer networks transfer data.

We are going to use three signals which are called clock, data and latch. Each of these can be set high (a voltage is present) or low (no voltage is present) by the .NET Micro Framework device under the control of our software. The signals are connected to the clock, data and latch inputs of our CD4094 shift register so that the program can talk to it.

The clock line triggers the shift register to do two things:

Shift all the bits along to make room.
Sample the value of the data input and store this value in the space that was created.

To get a feel for how this works, take a look at Figure 2 below. It shows a shift register with a pattern of bits in it. The pattern is 01100001. Note that although this represents a number; it can also be regarded as a pattern of 0s and 1s in the shift register itself. The value 0 means 0 volts and the value 1 means some volts. These are the signals that will be used to control our lights. I'm going to call them 0 and 1 from now on. The Shift Register has Clock, Data and Latch signals connected and they are all set to 1. We can ignore the latch part of the chip for now.

Figure 2: A shift register and latch with some data in it

When the clock signal changes from 1 to 0 this causes the shift register to perform the two steps described above. First the data is shifted along to the right. Note that this means that there is an "empty" location at the start of the register, and that the right most bit in the register "falls off" the register and disappears. Figure 3 shows how this works.

Figure 3: Shifting along the values in the shift register

Once the shift has finished the shift register can copy the data signal into the empty bit at the left as shown in Figure 4 below.

Figure 4: Storing the new data bit

By repeating this process 8 times a program can load a new pattern of 8 bits into the shift register. Then it is time to latch the new value to control the lights. This is the point at which the lights will appear to change. When the latch value is changed from 0 to 1 this causes the chip to copy the value in the Shift Register into the latch, as shown in Figure 5 below.

Figure 5: Copying the shift register pattern into the latch.

The latch is required so that the lights will not flicker as the new patterns are shifted into position. Each of the bits in the latch is connected to an output pin on the CD4094 which is used to switch a particular light colour on or off.

We need to create some C# that will provide the appropriate sequence of signals. It turns out that using the .NET Micro Framework to achieve this is actually very easy. The displayByte method below sends an 8 bit value into a shift register and then latches it into the output. If you read through the code you can see how the clock, data and latch values are all set to true (high) or false (low) to first clock the data out and then trigger the latch to display the pattern on the lights. The input is an 8 bit byte value and the program uses a mask to pick out the value of each bit in turn and set the data output accordingly.

private static void displayByte(byte value)
{
    latchPort.Write(false);
    clockPort.Write(false);

    byte mask = 1;

    for (int i = 0; i < 8; i++)
    {
        if ((value & mask) > 0)
        {
            dataPort.Write(true);
        }
        else
        {
            dataPort.Write(false);
        }
        clockPort.Write(true);
        clockPort.Write(false);
        mask <<= 1;
    }
    latchPort.Write(true);
    latchPort.Write(false);
}

The dataPort, clockPort and latchPort variables are instances of the .NET Micro Framework class OutputPort, which provides a method called Write which can be used to control the state of the output signal. We will consider how these are created a little later in the article.

The sample code for this project comes with a software emulator of the CD4094 which shows how it works. Figure 6 below shows that a new pattern is in the process of being shifted into the shift register, while the lights retain the previous one in the latch. The Clock and Data signals are high and the next statement will drop the Clock signal to add the next bit into the new pattern.

Figure 6: The light emulator

This figure also shows that I have two bits in the pattern controlling a strand of each colour. You can single step through the displayByte method above and watch it perform this output.

You can use this technique every time you want to control a large number of outputs using a small number of output pins. The CD4094 has "daisy chain" inputs and outputs so that the devices can be connected in sequence. If I used two devices I could control 16 bits, with three I could control 24 and so on. This would require only minimal changes to the software.

Output Driver

The CD4094 device will produce a signal output, but it is not really powerful enough to drive things like lights. To do this we need an amplifier and the ULN2803 Octal Darlington Driver is perfect for this. It is packaged as a single chip which contains 8 pairs of transistors. Each transistor pair is wired in a "Darlington" configuration and can be used as a switch which is controlled by on output from the CD4094. When the transistors are turned on they allow current to pass through them and this will cause the lamps to light. The lights that I bought used a "pull down" arrangement to make them light up. All of the light emitting diode (LED) lamps had one end wired to a common line that was connected to the positive supply. To make the a chain of LEDs light the other end that controls that chain needed to be pulled down to the ground level. This is a common arrangement with lights like these. The ULN2803 driver has the transistors wired in an arrangement that allows it to pull signals low in this way. Figure 7 shows how this arrangement works. The resistor shown is actually wired into each LED in the set of lights that I used.

Figure 7: Lighting the LEDs

Complete Circuit

The complete circuit shown in Figure 8 simply links each output of the CD4094 shift register to an input on the ULN2803 Darlington Driver. Note that there is no reason to link any particular bit with any other, the diagram shown is one which will translate most easily to a prototype "breadboard".

Figure 8: The Complete Circuit

The diagram just shows four lights connected to OUT1 from pin 18 of the ULN2803, the other 7 channels are connected in exactly the same way. Some of the pins can be left unconnected. Pins 9 and 10 of the CD4094 are only required if you are connecting multiple shift registers together and the common connection on pin 10 of the ULN2803 is not required. The Latch, Data and Clock signals on the CD4094 are connected to the output signals from the Micro Framework device.

Figure 9 shows the completed circuit built up on a prototype breadboard. The chip on the left is the CD4094 and the one on the right is the ULN2803.

Figure 9: The Completed Circuit

The red wires carry the positive voltage from the power supply, which is connected to the top left of the circuit. The green wires are ground. Other coloured wires are used for signals. The Clock, Latch and Data signals are brought out to a connector which will fit a Digi-ME prototyping board.

Selecting Lights

Each bit in the value sent to the displayByte method and then into the shift register will be mapped to a particular chain of lights. The mapping of these is not particularly important, since you can use program constants to represent particular values. I wired the red signals to output pins 4 and 8. To light up just the red lights I used the value 0x88 which is the appropriate bit pattern. I then set up constants for all the other colors:

const byte GREEN = 0x11;
const byte BLUE = 0x22;
const byte YELLOW = 0x44;
const byte RED = 0x88;

Setting Up the Hardware

The .NET Micro Framework provides a set of classes that can be used to represent the hardware in a system. The program uses instances of the OutputPort class to represent the output pins. These are created in the method that sets up the hardware:

const Cpu.Pin clockPin = Cpu.Pin.GPIO_Pin0;
const Cpu.Pin dataPin = Cpu.Pin.GPIO_Pin1;
const Cpu.Pin latchPin = Cpu.Pin.GPIO_Pin2;

static OutputPort clockPort;
static OutputPort dataPort;
static OutputPort latchPort;

private static void setupOutputs()
{
    clockPort = new OutputPort(clockPin, false);
    dataPort = new OutputPort(dataPin, false);
    latchPort = new OutputPort(latchPin, false);
}

In this version of the hardware I have connected pin 0 of the processor to the clock, pin 1 to the data and pin 2 to the latch. If you use different pins you can change the settings above.

Software

Now that we have working hardware we can consider how the software is to work. Note that this version of the program works correctly but lacks exception handlers that would make it truly robust. I've left these out to simplify the explanation. To make sense of this description you will need to have a copy of the program itself available for reference.

You can develop the code using Visual Studio 2008 Express edition, which you can download from http://www.microsoft.com/express/

The software is written for the .NET Micro Framework 3.0 which you can download from http://www.microsoft.com/downloads/details.aspx?FamilyID=9356ed6f-f1f0-43ef-b21a-4644dd089b4a&displaylang=en

Reading the Blog

The program reads the RSS feed from a blog and looks for the <pubDate> value. This contains the date when the feed was last updated. Whenever this date changes the lights must flash red for a few seconds before resuming a random display. Users of the full .NET Framework can use the HTTPRequest class to build a GET command to be sent to a server. Unfortunately the .NET Micro Framework does not support this, so we have to access the web feed using socket based communication. This part of the program is heavily based on the SocketClient example supplied with the .NET Micro Framework.

// This method requests a page from the specified server.
private static String GetWebPage(String server, string webPage)
{
    const Int32 c_httpPort = 80;
    const Int32 c_microsecondsPerSecond = 1000000;

    // Create a socket connection to the specified server and port.
    using (Socket serverSocket = ConnectSocket(server, c_httpPort))
    {
        // Send request to the server.
        String request = "GET "+ webPage + 
             " HTTP/1.1\r\nHost: " + server + 
             "\r\nConnection: Close\r\n\r\n";
        Byte[] bytesToSend = Encoding.UTF8.GetBytes(request);
        serverSocket.Send(bytesToSend, bytesToSend.Length, 0);

        // Allocate a buffer to receive HTML chunks
        Byte[] buffer = new Byte[1024];

        // 'page' refers to the HTML data as it is built up.
        String page = String.Empty; 

        // Wait up to 30 seconds for initial data 
        // Will throw exception if connection closed
        DateTime timeoutAt = DateTime.Now.AddSeconds(30);
        while (serverSocket.Available == 0 && 
               DateTime.Now < timeoutAt)
        {
            System.Threading.Thread.Sleep(100);
        }

        // Poll for data until 30 second time out
        // Returns true for data and connection closed
        while (serverSocket.Poll(30 * c_microsecondsPerSecond,
                                 SelectMode.SelectRead))
        {
            // Zero all bytes in the re-usable buffer
            Array.Clear(buffer, 0, buffer.Length);

            // Read a buffer-sized HTML chunk
            Int32 bytesRead = serverSocket.Receive(buffer);

            // If 0 bytes in buffer, then connection is closed, 
            // or we have timed out
            if (bytesRead == 0)
                break;

            // Append the chunk to the string
            page += new String(Encoding.UTF8.GetChars(buffer));
        }

        return page;   // Return the complete string
    }
}

This method is called to fetch the journal RSS feed from my blog:

string address = "www.robmiles.com";
string name = "/journal/rss.xml";

string html = GetWebPage(address, name);

You can use it to download from any RSS feed or page on the web. It will throw an exception if the page cannot be read. This version of my program does not perform exception handling however.

Getting the Published Date

The date is held in the form:

<pubDate>Wed, 05 Nov 2008 22:38:52 +0000</pubDate>

It would be enough just to record this content and check for changes in the text, but I decided that I might want to use the date information in a later version of the program and so I created some small helper methods to read numbers from the input string and a larger method to read the publish date itself:

private static DateTime getRecentPubDate(string html, string startTag)
{
    int index = html.IndexOf(startTag) ;

    if (index < 0) 
        throw new Exception("Missing tag " + startTag);

    index += startTag.Length;

    // spin past the name of the day
    while (index < html.Length && html[index] != ',') index++;
    if (index == html.Length) 
        throw new Exception("Short publish date");

    int dayValue = getInt(html, ref index, ' ');

    string monthName = getString(html, ref index, ' ');
    int monthValue = getMonth(monthName);

    int yearValue = getInt(html, ref index, ' ');
    int hourValue = getInt(html, ref index, ':');
    int minuteValue = getInt(html, ref index, ':');
    int secondValue = getInt(html, ref index, ' ');

    return new DateTime(yearValue, monthValue, dayValue, 
                        hourValue, minuteValue, secondValue);
}

The main body of the program uses this method to extract the date out of the RSS feed. When a new date is found it is time to update the lights.

Lights and Threads

My first version of the program flashed the lights for a while and then checked to see if a new blog post had been made. This worked OK, but the process of loading the RSS feed from the server and checking the dates can take a few seconds, which meant that the flashing lights would freeze every now and then. This did not look very good, and so I decided to use two threads instead. One is in charge of flashing the lights in a random pattern and the other loads the RSS feed from my blog and checks the date of the most recent publication.

Note that the threading I am using is exactly the same as threading in the full .NET Framework.

Thread Communication

The two threads communicate by means of a single boolean variable which is set to true when the blog alert is to take place. The display thread reads this flag and flashes the lights red if it is time to alert.

public static bool alert = false;

public static void flasher()
{
    setupOutputs();

    while (true)
    {
        randomDisplay(400, 10);
        if (alert)
        {
            alert = false;
            flashRed(600, 20);
        }
    }
}

The methods randomDisplay and flashRed do exactly what you would expect. Each of them gets two numbers to control the lights. The first number gives the delay in milliseconds between flashes (a few hundred milliseconds giving best results). The second gives the number of times that the lights should be flashed before the method finishes. RandomDisplay displays random colors, whereas flashRed is simply flashes the red lights. The alert flag is cleared before the red lights are flashed so that the system will resume normal display after the alert.

The second thread in the system performs the blog download and date test behaviour. This all happens inside the Main method:

public static void Main()
{
    flashThread = new System.Threading.Thread(flasher);

    flashThread.Start();

    string address = "www.robmiles.com";
    string name = "/journal/rss.xml";

    String html = GetWebPage(address, name);

    DateTime lastUpdate = getRecentPubDate(html, "<pubDate>");

    Debug.Print("Initial Update Value : " + lastUpdate.ToString());

    while (true)
    {
        System.Threading.Thread.Sleep(10000);

        html = GetWebPage(address, name);

        DateTime blogUpdate = getRecentPubDate(html, "<pubDate>");

        if (!blogUpdate.Equals(lastUpdate))
        {
            Debug.Print("Updated at : " + blogUpdate.ToString());
            lastUpdate = blogUpdate;
            alert = true;
        }
    }
}

To reduce the load on the network the system only checks the blog feed every 10 seconds.

Future Work

The program itself works fine, but the error handling is not wonderful. Although some of the methods used throw exceptions these are not caught anywhere, causing the blog reading thread to terminate. This does not stop the lights flashing, but it does mean that there will be no more alerts. However, it is not too hard to create a version which contains proper error handling and even flashes the lights different colors to indicate the alarm conditions. I have created a version that flashes the lights yellow every now and then if the network connection fails. There is also considerable scope for reading other web based sources and changing the output accordingly. Feel free to do all these things and make sure that you have fun.

Thanks

Thanks go to Ian Mitchell of Ormston Technology (http://www.ormtec.co.uk/) for doing such a great job of hardware design and build.

Stall Status: Know before you go

Coding4Fun — Wed, 13 Aug 2008 21:03:27 GMT

	Stall Status is a Silverlight-based Vista Sidebar Gadget that uses the Z-Wave wireless protocol and door sensors to notify you of the occupied/available state of the bathroom stalls.
Jerry Brunning Clarity Consulting, Inc Difficulty: Easy Time Required: 1-3 hours Cost: $50-$100 Software: Visual C# Express Edition Hardware: ControlThink Z-Wave SDK, Hawking Technologies Z-Wave HRDS1 door sensor Download: Download

Stall Status

Every now and then someone throws out an idea for a completely off-the-wall application that just has to be built. When Jon Rauschenberger, Clarity’s CTO, came into my office with his “brilliant idea” for a monitoring system to track the “occupied/available” state of our washroom stalls, I immediately recognized it as one of those moments. I had been doing some research on the Z-Wave wireless protocol for a client project earlier that week, and I thought “Stall Status” would be a fun way to get some hands on experience using Z-Wave.

In this article I will walk you through how to write managed code that interacts with Z-Wave devices. I’ll also show how to use Silverlight 2.0’s access policies to write “connected clients”: client applications that establish a persistent TCP connection to a remote server and thereby avoid having to poll the server for status changes. Finally, I’ll walk through the steps necessary to deploy a Silverlight 2.0 application as a Windows Vista Sidebar Gadget.

What is Z-Wave?

Z-Wave is a wireless communication protocol that works over radio frequency and is specifically designed for low-power, low-bandwidth usage scenarios. Typical usage scenarios for Z-Wave devices are monitoring and control applications – such as home automation. Available devices include door sensors, switches, and motors. Z-Wave devices are interoperable - devices labeled as Z-Wave compliant should all work together.

A Z-Wave network consists of one or more devices and a centralized controller. A controller can be a standalone (often hand held) hardware unit or a software-based kit. Devices on a Z-Wave network handle the routing of messages automatically without the need to set up pre-defined routes. This means that if you have several devices in your network that need to communicate together (e.g. a door sensor and an alarm), the devices can route messages through each other. This “mesh” communication capability allows you to extend the range of your network much farther than you would be able to if the devices all required direct connections to each other. For example, if you have three devices, A, B and C, device A can communicate with device C, even if C is outside of A's range, by routing its messages through device B. This all works automatically.

My simple Z-Wave network for Stall Status consists of door sensors to notify me when a stall door is opened and closed, and a software based controller. I used Hawking Technologies’ HRDS1 battery powered door sensors for each stall door in the washroom. The HRDS1 is considered an “occasionally on” device – it quietly sits in sleep mode until it detects an open/close event from the door. This is the same type of device you would use, for example, when building an alarm system for monitoring windows and doors. For the Z-Wave controller I used an excellent software-based controller and SDK from ControlThink, which you can purchase for $70. The controller consists of a USB dongle and a set of APIs for connecting to and communicating with devices. ControlThink includes a number of .Net sample applications, but be warned that the sample applications are not device specific, and the available devices usually assume you are integrating them into an existing hardware-controlled environment, so the documentation surrounding their usage tends to be sparse.

Using the ControlThink SDK is very straight forward. You simply plug in the USB dongle, reference their DLL from your .Net application, and connect to the controller with a single line of code. Once connected, you can manage your network by adding devices, removing devices, iterating the list of devices, etc.

I ended up writing three applications to support Stall Status:

An administrative application for adding/removing/listing the Z-Wave devices on my network. This is called StallStatusAdmin.
A Windows Service to listen for open/close events from the door sensors and notify any connected client. This is called StallStatusController.
A Silverlight 2.0 client application (the end-user interface) that connects to the Windows Service to receive event notifications. This is called StallStatusSilverlight.

Setting up the Z-Wave network

The administration application is a simple Windows Forms EXE that allows me to manage the network by adding, removing and listing the devices. This is simple to do using the ControlThink SDK – in most cases involving just a couple lines of code. Each Z-Wave device has some mechanism to put the device into “programming mode” . The HRDS1 has a button on the back that when pressed, puts the device into programming mode and allows the device to accept programming codes from the controller.

Listing 1 shows how to add a device to the network. Adding a device consists of registering the device with the controller, and then creating a relationship between the controller and the device's association group to enable the device to route messages to the controller. Once a device is registered, the controller assigns a unique NodeID that we will use to differentiate the three sensors from each other.

ZWaveController controller = Connect(); 
MessageBox.Show("After pressing OK, press the \"programming\" button on your device.");
ZWaveDevice device = controller.AddDevice();
            
device.Groups[1].Clear();
device.Groups[1].Add(controller.Devices.GetByNodeID(controller.NodeID));

VB.Net

Dim controller As ZWaveController = Connect()
MessageBox.Show("After pressing OK, press the ""programming"" button on your device.")
Dim device As ZWaveDevice = controller.AddDevice()

device.Groups(1).Clear()
device.Groups(1).Add(controller.Devices.GetByNodeID(controller.NodeID))

Listing 1 – Adding a device to the network.

Getting a list of the registered devices on the network is as easy a iterating through the Devices collection on the controller.

string result = "";
ZWaveController controller = Connect();

if (controller.Devices.Count > 0) {
   foreach (ZWaveDevice d in controller.Devices)    {
    result += d.GetType().ToString() + " as Node #" + d.NodeID + " PollEnabled = " + d.PollEnabled + "\r\n";
   }
}
else {
   result = "No devices found on the network";                
}
MessageBox.Show(result);

VB.Net

Dim result As String = ""
Dim controller As ZWaveController = Connect()

If controller.Devices.Count > 0 Then
   For Each d As ZWaveDevice In controller.Devices
    result &= d.GetType().ToString() & " as Node #" & d.NodeID & " PollEnabled = " & d.PollEnabled & Constants.vbCrLf
   Next d
Else
   result = "No devices found on the network"
End If
MessageBox.Show(result)

Listing 2 – Listing the devices in the network.

Receiving Z-Wave Events

Once the devices are registered on the network, they will send event notifications back to the controller each time the sensor is triggered. The next steps for us are to write code to receive the events and forward them to any client applications that are connected. To do this we’ll write a Windows Service that listens for events from the sensors.

All of the work for listening for events from the Z-Wave devices is handled for us by the ControlThink SDK. We simply connect to the controller and sink the LevelChanged event. We do this in our Run method, which is called from within our service’s OnStart function.

C#

public void Run() {
   try  {
       _controller = new ZWaveController();
       try  {
          _controller.Connect();
       }
       catch (Exception ex) {
          throw new Exception("Unable to connect.\r\n" + ex.ToString());
       }

       _controller.LevelChanged += new ZWaveController.LevelChangedEventHandler(_controller_LevelChanged);

       _policyListener = new PolicyListener();
       _listener = new SocketListener();
       _listener.Port = 4530;
             
        new System.Threading.Thread(new System.Threading.ThreadStart(_listener.StartSocketServer)).Start();
        new System.Threading.Thread(new System.Threading.ThreadStart(_policyListener.StartSocketServer)).Start();
        new System.Threading.Thread(new System.Threading.ThreadStart(ClearRecent)).Start();
   }
   catch (Exception ex) {
       Logger.WriteException(ex);
   }
}

VB.Net

Public Sub Run()
   Try
       _controller = New ZWaveController()
       Try
          _controller.Connect()
       Catch ex As Exception
          Throw New Exception("Unable to connect." & Constants.vbCrLf & ex.ToString())
       End Try

       AddHandler _controller.LevelChanged, AddressOf _controller_LevelChanged

       _policyListener = New PolicyListener()
       _listener = New SocketListener()
       _listener.Port = 4530

        CType(New System.Threading.Thread(New System.Threading.ThreadStart(AddressOf _listener.StartSocketServer)), System.Threading.Thread).Start()
        CType(New System.Threading.Thread(New System.Threading.ThreadStart(AddressOf _policyListener.StartSocketServer)), System.Threading.Thread).Start()
        CType(New System.Threading.Thread(New System.Threading.ThreadStart(AddressOf ClearRecent)), System.Threading.Thread).Start()
   Catch ex As Exception
       Logger.WriteException(ex)
   End Try
End Sub

Listing 3 – Listening for Z-Wave events when our service starts up.

In addition to listening for events from the ZWave Controller, our Run method also sets up socket listeners for talking to the Silverlight client application, which we will talk about later. An important detail to note, however, is the use of threading in the Run method. Remember that this is called directly from our service’s OnStart code which we should not block - if you block OnStart, you’ll see the service stuck at “Starting...” in the Service Control Manager. Anything that will block or that is long running (such as a socket listener) needs to run on a separate thread.

When the controller detects that one of the sensors has changed its state, it throws the LevelChanged event to our service. Our service handles LevelChanged in the _controller_LevelChanged method. The signature for the LevelChanged event looks like this:

void _controller_LevelChanged(object sender, ZWaveController.LevelChangedEventArgs e)

The LevelChangeEventArgs contains the original device that raised the event. We have three door sensors connected to our network. When any of them are triggered, LevelChanged is raised and we can inspect the LevelChangedEventArgs to get the NodeID of the unique identifier of the device. That’s all there is to interacting with the Z-Wave network.

Silverlight 2.0

Now that we’ve got the server infrastructure set up it is time to build a client application so we can actually start using Stall Status. I built the client application in Silverlight as an exercise to show how to use Silverlight 2.0’s access policy to make cross domain network calls from a Silverlight client application. I also knew that it is simple to deploy a Silverlight application as a Windows Vista Gadget, and the Sidebar was to be my preferred deployment model for the application.

Figure 1 – Stall Status interface

The main UI for the application is pretty simple – three ellipses, one for each stall, colored green if the stall is available and red if the stall is occupied. Most of the challenge with building the client piece has to do with connecting to the service and listening for updates. To do this, we create a persistent TCP connection and wait for data to be sent from the service over the socket. This is much better than a polling approach for an application like this because of the way the Z-Wave door sensors work. They are in sleep mode most of the time, and are only using power when they transmit a signal due to the door opening or closing. If we polled the devices frequently, it would kill the batteries in the device. Also, most of the time there is no change to the state of the doors, so polling would really be a waste.

Silverlight contains certain security mechanisms around network connectivity, especially TCP sockets. This is due to the fact that a Silverlight application runs in the context of the user’s browser, so special controls need to be in place to limit the type of connectivity that Silverlight applications can initiate. For socket-based connections, Silverlight 2.0 requires an access policy to be in place on the target server. This access policy essentially is a challenge/response mechanism that prevents a Silverlight application from connecting to an arbitrary server, potentially masquerading as the end user.

Access Policy

An Access Policy must be in place on the server for in order to enable a Silverlight 2.0 client to connect using sockets. The Silverlight framework handles all of the validation for the presence of the access policy, so your client application does not need to do anything. However, if the proper policy is not in place on the target server, Silverlight will throw an Access Denied exception, so your client application should be prepared to handle this situation. This is all very similar to how network access in Flash applications work. In fact, Silverlight can consume Flash policy files directly, as well as Silverlight policy files. In the Stall Status application, we’re going to be using Silverlight policy.

When a Silverlight application attempts to open a socket to a target server, Silverlight will automatically look for an access policy on the server by establishing a TCP connection over port 943, and sending a policy request. The policy request is simply an XML-style string: <policy-file-request/>. It is up to the author of the service that is receiving the request to ensure that they properly respond to this request, or else Silverlight will raise an exception on the client. All of this is described in detail in the MSDN documentation on the new network security restrictions in Silverlight 2.0.

In order to respond to a request for an access policy on our server, we need to implement a network listener on port 943 that responds to Silverlight’s policy file request. Dan Wahlin wrote a multi-part blog post showing exactly how to do this, and the listener I used for Stall Status, plus much of the other socket code, is copied from his example. I recommend reading his post - it is a great primer on writing TCP socket clients in Silverlight 2.0.

Our listener class run in our windows service and simply sets up a listener on port 943. When it receives a policy file request, it returns the appropriate response, as shown below.

<?xml version="1.0" encoding ="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from>
        <domain uri="*" />
      </allow-from>
      <grant-to>
        <socket-resource port="4530" protocol="tcp" />
      </grant-to>
    </policy>
  </cross-domain-access>
 </access-policy>

This response tells Silverlight to allow incoming connections to port 4530, which is the port that our service is listening on to accept connections from our Silverlight client.

Why is this important? Well, without access policy in place, there is nothing that prevents a malicious Silverlight application from connecting to a server without permission. For example:

Suppose you have an active session with your online bank. A malicious Silverlight application served up from Site A could attempt to connect to your bank using your existing login token (which may be stored as a cookie). With access policy in place, your bank would need to have a policy stating that it allowed Silverlight applications originating from Site A to connect to your bank.
Suppose you connect to Site A and download a malicious Silverlight application. The application can potentially connect to your corporate intranet and because you are on a corporate domain, the Silverlight app impersonates you. With the access policy rules in place, this would be prevented.

Persistent client connections

Now that we’ve got our access policy in place, we’re ready to code up our Silverlight client to connect to our server and wait for updates. Silverlight 2.0 can only connect using sockets over the port range 4502-4534. Our Windows Service uses 4530. It creates a listener on this port and then sits and waits for connections from our Silverlight clients.

_listener = new TcpListener(IPAddress.Any, Port);
_listener.Start();
while (true)
{
   _waitEvent.Reset();
   _listener.BeginAcceptTcpClient(new AsyncCallback(OnBeginAccept), null);
   _waitEvent.WaitOne();
}

VB.Net

_listener = New TcpListener(IPAddress.Any, Port)
_listener.Start()
Do
   _waitEvent.Reset()
   _listener.BeginAcceptTcpClient(New AsyncCallback(AddressOf OnBeginAccept), Nothing)
   _waitEvent.WaitOne()
Loop

Listing 4 – Our main listener for client connections

We’re using asynchronous sockets, so we’ve set up a delegate – OnBeginAccept – to accept and process our connections. The code to process the connects is listed below.

_waitEvent.Set();
TcpListener listener = _listener;
TcpClient client = listener.EndAcceptTcpClient(ar);

if (client.Connected)
{
   Logger.WriteLine("Accepted a connection from " + client.Client.RemoteEndPoint.ToString());

   StreamWriter writer = new StreamWriter(client.GetStream());
   writer.AutoFlush = true;
   _clients.Add(writer);
   writer.WriteLine("Connected.");

   if (ClientConnected != null)
   {
     ClientConnected(this, null);
   }
}

VB.Net

_waitEvent.Set()
Dim listener As TcpListener = _listener
Dim client As TcpClient = listener.EndAcceptTcpClient(ar)

If client.Connected Then
   Logger.WriteLine("Accepted a connection from " & client.Client.RemoteEndPoint.ToString())

   Dim writer As New StreamWriter(client.GetStream())
   writer.AutoFlush = True
   _clients.Add(writer)
   writer.WriteLine("Connected.")

   If ClientConnected IsNot Nothing Then
     ClientConnected(Me, Nothing)
   End If
End If

Listing 5 – Accepting a new client connection

Here we are simply adding a StreamWriter for each connected client to a List. We do this so when we receive events from the door sensors, we can loop through this List and notify all of the clients. We notify them by writing a tokenized string to the StreamWriter. We also have code to remove any clients from the list if we fail to write to their stream. This way we can catch the situation where the client disconnected.

C#

for (int i=_clients.Count-1;i>=0;i--)
{
   try
   {
      _clients[i].WriteLine(eventText);
   }
   catch (Exception ex)
   {
      Logger.WriteException(ex);
      Logger.WriteLine("Removing client # " + i + " because we failed to send them data.");
      _clients.Remove(_clients[i]);
   }
}

VB.Net

For i As Integer = _clients.Count-1 To 0 Step -1
   Try
      _clients(i).WriteLine(eventText)
   Catch ex As Exception
      Logger.WriteException(ex)
      Logger.WriteLine("Removing client # " & i & " because we failed to send them data.")
      _clients.Remove(_clients(i))
   End Try
Next i

Listing 6 – Sending an update to all clients

The text we pass to each client (represented in the code above by the eventText variable) is simply the NodeID of the sensor that triggered the event and the state (open/closed) on the sensor. The Silverlight client receives this text, parses it out, and updates the color of the ellipse accordingly.

C#

private void UpdateText(string text)
{
    string[] parts = text.Split(' ');

    if (parts.Length != 2) {
        return;
    }

    int stallNumber = Convert.ToInt32(parts[0]);
    string status = parts[1].ToLower();

    StatusIndicator thisStall = null;
    switch (stallNumber) {
        case 1:
            thisStall = this.Stall1;
            break;
        case 2:
            thisStall = this.Stall2;
            break;
        default:
            thisStall = this.Stall3;
            break;
    }

    if (status.Trim() == "open") {
        thisStall.Status = StallStatus.Open;
    }
    else if (status.Trim() == "closed") {
        thisStall.Status = StallStatus.Closed;
    }
    else if (status.Trim() == "recent") {
        thisStall.Status = StallStatus.Recent;
    }
    else {
        thisStall.Status = StallStatus.Unknown;
    }
}

VB.Net

Private Sub UpdateText(ByVal text As String)
    Dim parts() As String = text.Split(" "c)

    If parts.Length <> 2 Then
        Return
    End If

    Dim stallNumber As Integer = Convert.ToInt32(parts(0))
    Dim status As String = parts(1).ToLower()

    Dim thisStall As StatusIndicator = Nothing
    Select Case stallNumber
        Case 1
            thisStall = Me.Stall1
        Case 2
            thisStall = Me.Stall2
        Case Else
            thisStall = Me.Stall3
    End Select

    If status.Trim() = "open" Then
        thisStall.Status = StallStatus.Open
    ElseIf status.Trim() = "closed" Then
        thisStall.Status = StallStatus.Closed
    ElseIf status.Trim() = "recent" Then
        thisStall.Status = StallStatus.Recent
    Else
        thisStall.Status = StallStatus.Unknown
    End If
End Sub

Listing 7 – Receiving the update on the client from the server

The only other thing the application contains is the concept of "recently occupied". Once a stall has been vacated, we track it as recently occupied. This shows up on the client application as a yellow ellipse. To do this we keep track of a timestamp whenever the door opens. Our Service contains a dedicated thread that checks for doors opened more than 2 minutes ago. If it finds any, it changes the door's status from “Recent” to a status of “Opened”.

C#

private void ClearRecent()
{
  while (!_wait.WaitOne(10000,false))
  {
    var q = from stall in _stalls
      where stall.Timestamp.AddMinutes(2) < DateTime.Now && stall.State.Equals(DoorState.Recent)
      select stall;

    foreach (Stall stall in q)
    {
      if (stall.State.Equals(DoorState.Recent)) {
        stall.State = DoorState.Open;
        Broadcast(stall.NodeID, DoorState.Open);
      }
    }
  }
}

VB.Net

Private Sub ClearRecent()
  Do While Not _wait.WaitOne(10000,False)
    Dim q = From stall In _stalls _
            Where stall.Timestamp.AddMinutes(2) < DateTime.Now AndAlso stall.State.Equals(DoorState.Recent) _
            Select stall

    For Each stall As Stall In q
      If stall.State.Equals(DoorState.Recent) Then
        stall.State = DoorState.Open
        Broadcast(stall.NodeID, DoorState.Open)
      End If
    Next stall
  Loop
End Sub

Listing 8 – Clearing the “recently opened” flag

Vista Sidebar Gadget

Once I had the Service and Silverlight client apps written, it was time to deploy the client as a Vista Sidebar Gadget. This is actually pretty simple to do with a Silverlight application, but there are a couple things to work through for 64-bit versions of Vista.

Packaging a Silverlight application to run as a Gadget is not that different than running it locally or via a web page. You simple collect all of the files for your application, add a manifest file, zip them up, and rename the ZIP file so it has a .gadget file extension.

One easy way to create the manifest file is to start from an existing file from one of your existing gadgets. You can find your installed gadgets in the folder \Users\<user name>\AppData\Local\Microsoft\Windows Sidebar\Gadgets. Note that by default the AppData folder is hidden. Check the folders of any of your gadgets and you’ll see that they all contain an gadget.xml file. Copy one of these, open it, and make any changes that you need to. Most of the elements in the file are self explanatory, but for a full explanation, check out this article.

Once you’ve got your files and manifest packaged up, you can distribute your gadget. Users can run .gadget files directly in Vista and Vista automatically installs them into the sidebar.

Figure 2 – Stall Status deployed as a Vista Sidebar gadget

One note with Silverlight-based gadgets and the 64-bit version of Windows Vista: Since Silverlight is a 32-bit application, you cannot directly host Silverlight-based gadgets in the 64-bit version of Sidebar.exe (which is the running by default on 64-bit Vista). As a work around, you can run the 32-bit version of Sidebar.exe, which is located in the \Program Files (x86)\Windows Sidebar\ folder.

As we’ve seen in this article it is easy to use .Net to control a Z-Wave network, and there are tons of creative uses for the technology. Writing network-enabled Silverlight applications has become much more powerful in Silverlight 2.0. And deploying Silverlight-based applications as Vista Sidebar Gadgets is pretty simple.

Home Automation with Microsoft Robotics Developer Studio 2008

Coding4Fun — Sat, 24 May 2008 09:56:55 GMT

Typically we think of robots as machines from science fiction or as industrial robots such as those that build and paint cars. In the world of Microsoft Robotics Developer Studio, anything that has sensors and/or actuators can be considered a robot. In this article, we look at an automated house as a robot and apply the Decentralized Software Services model of Microsoft Robotics Studio to implementing some home automation tasks.

Charles Stacy Harris III

Difficulty: Intermediate

Time Required: 6-10 hours

Cost: $100-$200 for hardware (Optional, $0 if using only simulation)

Software: Visual Studio or Visual Studio Express, Microsoft Robotics Developer Studio 2008 CTP April, ControlThink Z-Wave PC SDK

Hardware: (All Optional) Elk M1G/M1EZ Security and Automation Panel, Z-Wave Dimmer Switches, Z-Wave Controller such as the ControlThink ThinkStick or equivalent.

Download: Download

House, Robot

Those of you who know me or who have read my previous Coding4Fun article Home Automation with Windows Workflow, know that I’m nuts about home automation. I’m even more passionate about robotics and I’ve wanted to try out some things with Microsoft Robotics Studio since the very first version. Recently I had a long weekend, so I spent a few hours putting together some simple home automation examples using Microsoft Robotics Developer Studio 2008 CTP April. Check out the Microsoft Robotics Developer Center for details on how to get the CTP.

The examples in this article duplicate what I did using Windows Workflow in my previous article, but instead use the Decentralized Software Services (DSS) approach of Microsoft Robotics, and Microsoft Visual Programming Language (VPL) for a simple way to write automation tasks. The Microsoft Robotics Developer Center contains a lot of detailed information about DSS, VPL, and the other technologies found in Microsoft Robotics Developer Studio. For now, let’s just cover some basics. To get further along with the code in this article, you’ll want to check out some of the excellent tutorials presented by the Microsoft Robotics team.

Services, Messages, and Ports

A DSS Service is the basic component upon which Microsoft Robotics applications are built. In fact, DSS services are a generic construct that can and have been used outside of the context of robotics. DSS services contain state and the service state is manipulated via messages sent to the service on a service port.

Messages sent to a service are structured .NET classes that may contain a message payload that determines how or even if state will be modified, or what part of a service state should be retrieved. There are also message that do not directly manipulate state, but may have some other side-effects. Services respond to messages such as CREATE, LOOKUP, UPDATE, etc. In addition, you can define messages that extend the semantics of the core messages.

Ports are the mechanism through which services communicate. Ports accept a set of message types that are defined by the service itself. In addition, ports are also used for outbound communication in situations such as subscribing to event notification from a service.

Again, there are excellent online resources for learning the details of Microsoft Robotics, DSS, and the underlying technologies for Microsoft Robotics developer Studio. You’ll probably want basic familiarity with the Microsoft Robotics architecture including the Concurrency and Coordination Runtime (CCR) along with the notion of Arbiters and iterators.

Robo-Moose

The security and automation system in my house is centered on an Elk M1G alarm panel from Elk Products Incorporated . This panel allows for up to 208 input zones in the form of contact switches, motion sensors, and so on. It also allows for up to 208 outputs, on-board task scripting and many other features. One of the key features for my use is the capability of being able to monitor and control the panel via an Ethernet adaptor. So, my first order of business was to write a DSS service – the ElkService – to communicate with the Elk M1G via sockets. This ElkService exchanges messages with the Elk M1G via an ASCII protocol that is documented here.

The code that the ElkService uses to read from the Elk M1G hardware is shown below. Note that the code looks sequential, but is actually asynchronous. The StreamAdapter.Read method sets up a task to do an asynchronous IO operation and the line “yield return (Choice)ioResultPort;” returns this task to the runtime which is iterating over all tasks returned by ElkReader.

/// <summary>
/// ElkReader opens a socket connection to the hardware panel. It then
/// enters a loop that
/// </summary>
/// <returns></returns>
public IEnumerator<ITask> ElkReader()
{
    Connect();

    // Send a request to the Elk panel get a report of the entire zone status.
    SendElkMessage(RequestStrings.ZoneStatus);

    byte[] buffer = new byte[256];

    int bytesRead = -1;
    Exception ex = null;

     do
    {
        var ioResultPort = StreamAdapter.Read(networkStream, buffer, 0, buffer.Length);

        yield return (Choice)ioResultPort;

        ex = ioResultPort;
        if (ex != null)
            throw ex;

        bytesRead = ioResultPort;
        if (bytesRead != 0)
            ProcessRawElkMessage(Encoding.ASCII.GetString(buffer, 0, bytesRead));

    } while (bytesRead != 0);
}

When the ElkService receives a packet from the hardware panel, it converts the packet from a string to a custom message containing the raw sensor data and posts the message to the main port of the ElkService itself. For example, when the service receives a “ZC” message from the hardware, it converts this to an UpdateRawZone message that contains the raw data from the security panel. This happens in the method ProcessRawElkMessage. Here is a fragment of that code:

public void ProcessRawElkMessage(string message)
{
    string messageType = message.Substring(2, 2);

    switch (messageType)
    {
        case "ZC": // Zone status change
            var zoneState = new UpdateRawZoneRequest
            {
                Id = byte.Parse(message.Substring(4, 3)),
                State = byte.Parse(message.Substring(7, 1),
                              NumberStyles.HexNumber)
            };

            var updateZoneMessage = new UpdateRawZone();
            updateZoneMessage.Body = zoneState;

            _mainPort.Post(updateZoneMessage);
            break;
…

UpdateRawZoneRequest is the message payload and is used to send data about a zone change event to a subscriber. UpdateRawZone is the actual message type that is transmitted on the port for the ElkService.

[DataContract]
[Description("UpdateRawZone Request Message Payload")]
public class UpdateRawZoneRequest
{
    [DataMember]
    public byte Id { get; set; }

    [DataMember]
    public byte State { get; set; }
}


/// <summary>
/// Update Elk zone status
/// </summary>
[Description("UpdateZone request message")]
public class UpdateRawZone : Update<UpdateRawZoneRequest,
        PortSet<DefaultUpdateResponseType, Fault>>
{
}

The message processing code can also be written a bit more compactly as:

public void ProcessRawElkMessage(string message)
{
    string messageType = message.Substring(2, 2);

    switch (messageType)
    {
        case "ZC": // Zone status change
            var updateZoneMessage = new UpdateRawZone
            {
                Body = new UpdateRawZoneRequest
                {
                    Id = byte.Parse(message.Substring(4, 3)),
                    State = byte.Parse(message.Substring(7, 1),
                          NumberStyles.HexNumber)
                }
            };

            _mainPort.Post(updateZoneMessage);
            break;
…

UpdateRawZoneHandler is a message receiver that is active on the main port and which responds to the update message by updating internal state, and notifying subscribers of the change in state.

[ServiceHandler(ServiceHandlerBehavior.Exclusive)]
public IEnumerator<ITask> UpdateRawZoneHandler(UpdateRawZone message)
{
    _state.ZoneStates[message.Body.Id - 1] = message.Body.State;

    SendNotification(_submgrPort, message);

    message.ResponsePort.Post(DefaultUpdateResponseType.Instance);

    yield break;
}

In the Zone

The ElkService represents the core service that communicates with the Elk M1G hardware. The next service – ElkZoneSensor – represents a higher level “sensor array” that is attached to the Elk hardware. ElkZoneSensor “partners” with the ElkService. This means that the ElkZoneSensor relies on the ElkService to function. The DSS infrastructure will ensure that the ElkService is started if needed when starting the ElkZoneSensor service.

The ElkZoneSensor subscribes to updates from the ElkService for changes in the hardware zones. When these changes occur, the ElkService notifies the ElkZoneSensor which updates its state and notifies any of its subscribers. The ElkZoneSensor uses a higher level message – UpdateZone – that contains a sensor ID and an enumeration that describes the state of the sensor.

[DataContract]
public class Zone
{
    [DataMember]
    [Description("The Elk hardware zone id of the sensor")]
    [DataMemberConstructor]
    public byte Id { get; set; }

    [DataMember]
    [Description("The Elk defined state of the sensor")]
    public ZoneStatus Status { get; set; }
}

Candlepower

The next services that we need for the robotic house are services to control the lights. In this case, I started with a generic contract for the DSS service. A generic contract in DSS terms just defines the set of messages to which a service will respond and defines the port type on which those messages will be sent. The generic contract does not contain code to actually implement the service behavior. One of the benefits of a generic service contract is that you can specify the contract, write algorithms that use the contract, and later connect the generic service contracts to code that actually implements the behavior. This is very much like programming to an abstract interface in the object oriented world, and having multiple classes that actually implement the interface.

We start off with a generic service called the GenericDimmer that represents a dimmer switch and we implement two concrete services: the SimulatedDimmer and the ZWaveDimmer. SimulatedDimmer just logs a message to represent its state change. The ZWaveDimmer actually controls the lights via a hardware Z-Wave controller.

Here’s what the GenericDimmer contract looks like:

namespace Robotics.GenericHouseControls.Dimmer
{


    /// <summary>
    /// GenericDimmer Contract class
    /// </summary>
    public sealed class Contract
    {
        /// <summary>
        /// The Dss Service contract
        /// </summary>
        [DataMember]
        public const String Identifier = "http://schemas.tempuri.org/2008/04/generichousecontrolsdimmer.html";
    }

    /// <summary>
    /// The GenericDimmer State
    /// </summary>
    [DataContract]
    public class GenericDimmerState
    {
        [DataMember]
        [DataMemberConstructor(Order = 1)]
        public int Id;

        [DataMember]
        public int Level;
    }

    /// <summary>
    /// GenericDimmer Main Operations Port
    /// </summary>
    [ServicePort(AllowMultipleInstances = true)]
    public class GenericDimmerOperations : PortSet<DsspDefaultLookup, DsspDefaultDrop, Get, HttpGet, On, Off, SetLevel>
    {
    }

    /// <summary>
    /// GenericDimmer Get Operation
    /// </summary>
    public class Get : Get<GetRequestType, PortSet<GenericDimmerState, Fault>>
    {

        /// <summary>
        /// GenericDimmer Get Operation
        /// </summary>
        public Get()
        {
        }

        /// <summary>
        /// GenericDimmer Get Operation
        /// </summary>
        public Get(Microsoft.Dss.ServiceModel.Dssp.GetRequestType body) :
            base(body)
        {
        }

        /// <summary>
        /// GenericDimmer Get Operation
        /// </summary>
        public Get(Microsoft.Dss.ServiceModel.Dssp.GetRequestType body, Microsoft.Ccr.Core.PortSet<GenericDimmerState, W3C.Soap.Fault> responsePort) :
            base(body, responsePort)
        {
        }
    }

    [DataContract]
    public class OnRequest
    {
    }

    [Description("Turn the switch on")]
    public class On : Update<OnRequest, PortSet<DefaultUpdateResponseType, Fault>>
    {
    }

    [DataContract]
    public class OffRequest
    {
    }

    [Description("Turn the switch off")]
    public class Off : Update<OffRequest, PortSet<DefaultUpdateResponseType, Fault>>
    {
    }

    [DataContract]
    public class SetLevelRequest
    {
        [DataMember]
        [DataMemberConstructor]
        public int Level { get; set; }
    }

    [Description("Set the dim level")]
    public class SetLevel : Update<SetLevelRequest, PortSet<DefaultUpdateResponseType, Fault>>
    {
    }
}

This code defines the contract only. Now to implement that contract we can run the DssNewService utility with the /implement switch and generate a service based on this contract. For example:

dssnewservice /s:SimulatedDimmer /n:Robotics.HouseControls.SimulatedDimmer /i:GenericHouseControls.Y2008.M04.Proxy.dll

will generate a new service called SimulatedDimmer in the .NET namespace Robotics.HouseControls.SimulatedDimmer. The service will have a stubbed out implementation of the GenericDimmer contract including service startup code, state, and stubbed out message handlers.

Here’s what the main service file looks like for the simulated dimmer after I added logging to the generated methods. I’ve also deleted some of the using statements for easier reading.

using pxdimmer = Robotics.GenericHouseControls.Dimmer.Proxy;

namespace Robotics.HouseControls.SimulatedDimmer
{


    /// <summary>
    /// House Controls Service
    /// </summary>
    [DisplayName("Simulated Dimmer")]
    [Description("The Simulated Dimmer Switch Service")]
    [Contract(Contract.Identifier)]
    [AlternateContract(pxdimmer.Contract.Identifier)]
    public class SimulatedDimmerService : DsspServiceBase
    {

        /// <summary>
        /// _state
        /// </summary>
        [ServiceState]
        [InitialStatePartner(Optional = true)]
        private pxdimmer.GenericDimmerState _state = new pxdimmer.GenericDimmerState();

        /// <summary>
        /// _main Port
        /// </summary>
        [ServicePort("/simulateddimmer", AllowMultipleInstances = true)]
        private pxdimmer.GenericDimmerOperations _mainPort = new pxdimmer.GenericDimmerOperations();


        /// <summary>
        /// Default Service Constructor
        /// </summary>
        public SimulatedDimmerService(DsspServiceCreationPort creationPort) :
            base(creationPort)
        {
        }

        /// <summary>
        /// Service Start
        /// </summary>
        protected override void Start()
        {
            base.Start();

            // Add service specific initialization here.
            LogInfo(string.Format("Dimmer State => Id:{0} Level:{1}", _state.Id, _state.Level));
        }

        [ServiceHandler(ServiceHandlerBehavior.Concurrent)]
        public IEnumerator<ITask> OnHandler(pxdimmer.On update)
        {
            LogInfo(string.Format("Simulated Dimmer => Id:{0} On", _state.Id));

            update.ResponsePort.Post(DefaultUpdateResponseType.Instance);
            yield break;
        }

        [ServiceHandler(ServiceHandlerBehavior.Concurrent)]
        public IEnumerator<ITask> OffHandler(pxdimmer.Off update)
        {
            LogInfo(string.Format("Simulated Dimmer => Id:{0} Off", _state.Id));

            update.ResponsePort.Post(DefaultUpdateResponseType.Instance);
            yield break;
        }

        [ServiceHandler(ServiceHandlerBehavior.Exclusive)]
        public IEnumerator<ITask> SetLevelHandler(pxdimmer.SetLevel update)
        {           
            _state.Level = update.Body.Level;
            LogInfo(string.Format("Simulated Dimmer => Id:{0} Level:{1}", _state.Id, update.Body.Level));

            update.ResponsePort.Post(DefaultUpdateResponseType.Instance);            
            yield break;
        }
    }
}

Check the code download for the implementation of the ZWaveDimmer. You’ll find that it’s pretty straightforward. It should be simple to write similar code if you use a different technology for lighting control. You just write a service that matches the GenericDimmer contract, and you should be able to configure the GenericDimmer using a manifest to point to the actual dimmer service. Check out the documentation in Microsoft Robotics Developer Studio for more information on manifests and how to use the manifest editor.

Bulb On, Bulb Off!

The “Hello, World” application for any home automation software that I’ve tested in my house has always been the automating of my pantry light. The pantry has a Z-Wave light switch inside and the pantry door has a contact switch that is connected to the Elk M1G. When the door is open, we want the light to turn on, and when the door is closed we want the light to turn off. Now that we have all the pieces for this, here’s what the VPL diagram for this looks like:

As you can see, it was also a relatively easy matter to add text-to-speech to announce the opening and closing of the pantry door. You may find out quickly that this is an annoyance to those in the testing areas – for me that was my kitchen – so it’s nice to know that two quick hits of the delete key will also remove the text-to-speech. This is part of the beauty of the Microsoft Robotics programming model!

The second example shows how you can use a motion detector – in this case connected to zone 19 on the Elk – to trigger a light. The light comes on at a level that you control from the VPL code, and stays on for a duration that you can also control from the code. For the example, I set the timer to a pretty low level, but you can customize it. You could also add additional rules to only turn on the light at certain times, or better still connect an ambient light sensor to decide whether you should turn the light on.

In this diagram, if motion is detected – that is zone 19 is triggered with a status of ViolatedOpen – the light is turned on at a low dim level and a timer is set. When the timer completes, the light is turned off. If, however, there is more motion before the timer completes, the SetTimer message will cancel the old timeout and restart the timer.

There are more VPL examples included in the download including an extra service that you can use to send email from your VPL code. I’m experimenting with using the email service to send me a text message whenever my alarm is armed or disarmed.

Miscellanea

Since I haven’t had a lot of time to study the testing framework and simulation environments used by Microsoft Robotics, I included a service called the ElkTestDataPlayback service that allows me to replay the contents of a text file to simulate the ElkService getting actual data. This works pretty well for testing. The contents of the file are merely raw data captures that I made from the data sent by the Elk M1G panel. To use this service in VPL, you just drop it onto your diagram, configure it’s TestDataFileName via “Set initial configuration” to point to a data file, and send it a message to start playback.

Important: If you have the Elk hardware, you will want to uncomment the SpawnIterator(ElkReader) line in the ElkService.Start method. I know this is a hack for now. It would probably be better to write a SimulatedElk service based on a generic service contract. If I have time, I will do that in the future. That would involve a lot more work than I had for this weekend project!

TODO List

Since this was my first foray into Microsoft Robotics Developer Studio and I had limited time to really explore the features in depth, there are a few things that I’ve left unimplemented. Here are some of the things that I would like to expand on in the future:

1. Support for more of the Elk features: Currently, I only support Zone Change notifications. Fuller support of the Elk hardware would not be difficult and would be beneficial to anyone wanting to use this on an ongoing basis. There’s some stub code for a few other notifications if you want to add to the service.

2. Generic contracts for the Elk M1G: I didn’t base the Elk services on generic contract because I’m not familiar with enough other types of security and automation panels to make the needed generalizations. It would be interesting to try to come up with something more generic. I thought about using the Generic Contact Sensor array, but I’m not sure that it models what we need. For example, a door contact is considered violated when it’s open, but a water sensor is considered violated when it’s closed.

3. Additional Z-Wave features: I’ve left out notification for lighting level changes, support for scenes and a host of other features. There’s so much more that’s possible with full Z-Wave support.

4. Refined Generic Contracts: Generic contracts allow developers to write code that is independent of the final hardware. That is one of the major benefits of the model used by Microsoft Robotics. You could for example have a generic light switch for simulation and testing, and based on configuration you could plug in a Z-Wave switch or an Insteon switch when it’s time to deploy the actual solution.

5. Simulation Support: One of the major benefits of Microsoft Robotics Developer Studio is the simulation environment. For example, if we had a motion detector in the simulation environment, we could test some of the algorithms that I presented above by having a simulated mobile robot “violate” the motion detector’s zone and trigger the corresponding VPL code.

6. Exception Handling: As I build more on the code in this article, I’ll add exception handling and retry logic. Microsoft Robotics has some extremely robust features such as Causalities that make handling exceptions in a concurrent environment much easier.

7. HttpHandlers: I have a start at code for handling HTTP requests in the ZWaveController service. Handling HTTP requests is handy for building client applications that access your services without themselves having to be DSS services.

Other experiments that might be fun to try include integrating your Microsoft Robotics controlled home with remote control applications that are based on WPF or Silverlight, or perhaps integrating control from a Windows Media Center PC or Windows Home Server.

I hope you enjoy Microsoft Robotics Developer Studio as much as I have. I look forward to seeing what other people build with this fantastic technology. If people are interested, I can continue to share my home automation experiments. I think Microsoft Robotics Developer Studio will be the major tool in my home automation toolbox for quite some time.

Project Settings Note:

You will have to modify the project settings for the projects included in the House.Robot solution since your installation of Microsoft Robotics Developer Studio will be in a different directory than mine. The DssProjectMigration.exe command line tool will make short work of this. Just run it with a parameter that specifies the directory you want it to search, and it will find all of the project files in that directory and subdirectories and convert them to be buildable with your installation settings.

If you use the ElkTestDataPlayback service, in the examples, you’ll need to set the path to the location of the test data file either in the initial configuration for the component, or in a manifest that configures the component. Make sure that you do not put quotes around the path name. I included a test data file from my system.

Control Windows Media Center using a Windows Mobile 5 Device

Coding4Fun — Mon, 14 May 2007 20:08:00 GMT

This article demonstrates how to use a smartphone running Windows Mobile 5 to remotely control a host machine running Windows Media Center. I will describe how to create an add-in application that runs within Windows Media Center, and how to create a Windows Mobile 5 application that you can use to communicate with the Media Center over a wireless internet connection. Finally, I will demonstrate how to use this implementation to manipulate Media Center using the Windows Media Center API.

Matt Ivers

Difficulty: Intermediate

Time Required: 6-10 hours

Cost: $100-$200

Software: Visual Basic or Visual C# Express Editions, Windows Media Center SDK 5.0, Windows Mobile 5.0 Smartphone SDK

Hardware: Mobile device running Windows Mobile 5.0

Download: C# and VB.Net

Introduction

Starting with Windows Media Center Edition 2005, Media Center added extensibility support through hosted add-in assemblies. By implementing an add-in interface and registering the assembly with Media Center, the add-in assembly is given access to the Microsoft.MediaCenter.Hosting.AddInHost object. Using this object model, an add-in assembly can programmatically inspect and manipulate various aspects of Windows Media Center. In addition to the exposed Media Center namespaces, the add-in has complete access to all the capabilities of the .NET Framework.

By combining the power of a Media Center add-in with a mobile device running Windows Mobile 5.0, we can extend the capabilities of a Media Center add-in even further. The add-in service I developed runs as a listener service within Windows Media Center on the host machine. It is initialized when Windows Media Center is started, runs invisibly in the background, and allows mobile devices to connect and submit requests to it. The mobile solution leverages an existing WiFi internet connection to communicate with the add-in via TCP socket connections. The mobile device runs a .NET Compact Framework 2.0 forms application designed for devices running Windows Mobile 5 or higher.

The included remote control application is capable of the following functionality:

Retrieve metadata about currently loaded media
Affect playback of currently loaded media – Play, Pause, Stop, Next Track, Previous Track
Control Media Center volume
Retrieve a list of available media – Photos, Audio, Video
Explicitly load media for playback – Audio, Video

Creating a Windows Media Center add-in application

The first step in our implementation is creating an add-in that will run within Windows Media Center. This involves creating a new Windows Media Center Presentation Layer Application project, implementing an interface, signing the assembly, and creating a setup project to install the assembly and register it with Media center.

Creating a new project – Windows Media Center Presentation Layer Application

Installing the Windows Media Center SDK makes this step simple. Once installed, you create this project like any other in Visual Studio:

Figure 1 - Creating the project

Using the Windows Media Center Presentation Layer Application project template yields the following project skeleton:

Figure 2 - Solution Explorer for our new project

There are two files of interest here: AddIn.vb and App.xml. AddIn.vb contains our add-in class. Interface methods implemented in this class will be invoked by Windows Media Center when our add-in is launched. App.xml contains configuration information identifying our assemblies and add-in attributes. The setup project will use this XML to register our add-in with Windows Media Center during installation.

The AddIn class

Media Center add-in applications must implement two interfaces in order for Media Center to invoke them: Microsoft.MediaCenter.Hosting.IAddInEntryPoint, and Microsoft.MediaCenter.Hosting.IAddInModule. By using the project template, our add-in class already implements both (AddIn.vb):

Visual Basic .NET

Public Class Class1
    Implements IAddInModule
    Implements IAddInEntryPoint

    ' Initialize (IAddInModule)
    Public Sub Initialize(ByVal appInfo As Dictionary(Of String, Object), ByVal entryPointInfo As Dictionary(Of String, Object)) Implements IAddInModule.Initialize
        ' Initialization logic goes here
    End Sub

    ' Uninitialize (IAddInModule)
    Public Sub Uninitialize() Implements IAddInModule.Uninitialize
        ' Clean-up logic goes here
    End Sub

    ' Launch (IAddInEntryPoint)
    Public Sub Launch(ByVal host As AddInHost) Implements IAddInEntryPoint.Launch
        ' This is where normal execution begins
    End Sub
End Class

Visual C#

public class Class1 : IAddInModule, IAddInEntryPoint 
{
    //  Initialize (IAddInModule)
    public void Initialize(Dictionary<string, object> appInfo, Dictionary<string, object> entryPointInfo)
    {
        //  Initialization logic goes here
    }    
    //  Uninitialize (IAddInModule)
    public void Uninitialize() 
    {
        //  Clean-up logic goes here
    }    
    //  Launch (IAddInEntryPoint)
    public void Launch(AddInHost host) 
    {
        //  This is where normal execution begins
    }
}

The IAddInModule.Initialize and IAddInModule.Uninitialize interface methods are used by Media Center to signal the beginning and end of the add-in application’s lifetime. Use Initialize to create any internal objects your application may require, and the Uninitialize to perform any clean-up. Keep in mind that since the add-in application runs within Media Center, it may decide to close your add-in application before it has a chance to exit on its own. In any case, Media Center will call the Uninitialize method and give the add-in a window of execution to exit as gracefully as possible.

The IAddInEntryPoint.Launch method is where normal execution code should begin. Media Center will pass an AddInHost object as an input parameter. Through this object, your add-in application can access all the features of the Media Center API.

Signing the assembly

Windows Media Center requires that all add-in assemblies be strongly-named. This requires that the assembly be signed using a key file. Thanks to Visual Studio 2005, signing an assembly is a straightforward process. From your add-in project’s “Properties” menu, you can browse to the “Signing” tab to create a new strong name key file for the project:

Figure 3 - Signing our assembly

Explicit instruction is also available here:
How to: Sign an Assembly (Visual Studio)

Tweaking the App.xml file

Media Center requires every add-in application to explicitly define a point of entry by which the application is to be launched. The App.xml file contains this configuration information. The Media Center project template used earlier generates the following sample:

<application title="DemoProject" id="{f6dd1141-f288-46fe-bcdb-2d9c5ffd986e}">
  <entrypoint id="{31a15ce9-0487-43bc-94de-a43409129641}" 
              addin="DemoProject.Class1, DemoProject,Culture=Neutral,Version=6.0.6000.0"
              title="DemoProject"
              description="DemoProject"
              ImageUrl=".\AppIcon.png">
    <category category="More Programs"/>
  </entrypoint>
</application>

The XML definition specifies the add-in applications and their points of entry within Media Center. Add-in applications can be launched on demand from various locations within Media Center, such as from an icon in the “More Programs” group. A full listing of all the available points of entry can be found here. Add-in applications can also be launched in the background when Media Center starts. To indicate this, we specify “Background” in the “category” attribute. The “addin” attribute must also be modified to point to our add-in class in the format “Assemblyname.ClassName”. The “title”, “description”, and “ImageUrl” attributes are used primarily for on-demand add-ins.

After making our changes, the Windows Media Center Remote application XML looks like this:

<application title="WMCServerAddIn" id="{7b71a7ca-b459-4023-ab12-d5cc8c56b991}">
  <entrypoint id="{5fe9982b-ca4a-459e-b62c-40399e875d66}" 
              addin="WMCServerAddIn.ServerAddIn, WMCServerAddIn,Culture=Neutral,Version=6.0.6000.0"
              title="WMCServerAddIn"
              description="WMCServerAddIn"
              ImageUrl=".\AppIcon.png">
    <category category="Background"/>
  </entrypoint>
</application>

Creating the setup project

With a basic interface implementation complete and a configuration XML created, we are ready to create the setup project. The setup project will install our assemblies into the Global Assembly Cache and register our XML-defined entry point with Media Center. A full step-by-step walkthrough can be found here:

Creating a Windows Installer File for a Windows Media Center Add-in

Once the setup project is complete, it’s time for a test. By using the Host.MediaCenterEnvironment.Dialog class off of the AddInHost object, we can present a dialog box to the user to ensure the add-in launches successfully. After compiling the solution, run the installer by right-clicking the setup project and choosing “Install”. Once installation has completed, run Windows Media Center. A few seconds after startup, the add-in is launched:

Figure 4 - Running our Hello World Media Center Add-in

Creating a Windows Mobile 5.0 client application

The second step in our implementation is creating a .NET Compact Framework 2.0 forms application. This is a mobile application that will run on a mobile device running Windows Mobile 5 or higher.

Creating a new project – Windows Mobile CE 5.0 application

Installing the Windows Mobile Smartphone SDK 5.0 makes this step simple. Once the SDK is installed, you can create a project in Visual Studio using the Windows CE 5.0 Project template.

The only other typical setup required for developing mobile apps is to change the deployment settings to point to your WM5 device. This can be configured within the Visual Studio toolbar:

Figure 5 - changing the deployment settings to target the mobile device

Implementing the Media Center Add-in service

With a test harness in place at both ends of the implementation, it was time to get to the real code. To facilitate the control of Media Center through the hosted add-in, the service requires a few key components. These include choosing a server / client conversation protocol, creating a multithreaded socket server, implementing object serialization, and implementing the programmatic manipulation of Media Center.

Implementing the socket server

The socket server uses the Socket object from the System.Networking.Sockets namespace for all of its communications. The listener service begins by binding to the host machine’s local address and listening on a port of your choosing. Once the socket is instantiated and bound to a local port, it begins listening for and accepting inbound connections. When a new connection is established, a target method BeginSocketConversation will be invoked on a new thread, where the actual communication between the two parties will take place. Once the new thread has been invoked, execution will continue in the AcceptConnections method. At this time the newly launched thread notifies the listener to begin accepting new connections again. A ManualResetEvent from the System.Threading namespace can be used to communicate changes in state between two or more threads. Here is the code implementation of the socket listener:

Visual Basic .NET

Private Sub AcceptConnections()
        Dim localMachineInfo As IPHostEntry
        Dim localEndPoint As IPEndPoint
        Dim listener As New Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp)
        Try
            localMachineInfo = Dns.Resolve(String.Empty)
            localEndPoint = New IPEndPoint(localMachineInfo.AddressList(0), _port)
            listener.Bind(localEndPoint)
            listener.Listen(10)
            While True
                threadEvent.Reset()
                listener.BeginAccept(New AsyncCallback(AddressOf BeginSocketConversation), listener)
                threadEvent.WaitOne()
            End While
        Catch ex As Exception
          Log.Write(ex)
    End Try
End Sub

Visual C#

Public Class Class1
    Implements IAddInModule
    Implements IAddInEntryPoint

    ' Initialize (IAddInModule)
    Public Sub Initialize(ByVal appInfo As Dictionary(Of String, Object), ByVal entryPointInfo As Dictionary(Of String, Object)) Implements IAddInModule.Initialize
        ' Initialization logic goes here
    End Sub

    ' Uninitialize (IAddInModule)
    Public Sub Uninitialize() Implements IAddInModule.Uninitialize
        ' Clean-up logic goes here
    End Sub

    ' Launch (IAddInEntryPoint)
    Public Sub Launch(ByVal host As AddInHost) Implements IAddInEntryPoint.Launch
        ' This is where normal execution begins
    End Sub
End Class

Once a connection has been established, the server begins to listen for inbound messages. When new data is received, it is parsed into a custom Message object for easy inspection by a consuming class. An event is then raised to any consuming classes, passing a reference to the newly created Message object. The server then resumes listening for new data on the same socket. Here is the code implementation:

Visual Basic .NET

Private Sub BeginSocketConversation(ByVal ar As IAsyncResult)
    threadEvent.Set()
    RaiseEvent ClientConnected()
    Dim listener As Socket = CType(ar.AsyncState, Socket)
    _socket = listener.EndAccept(ar)
    Dim buffer(PACKET_SIZE) As Byte
    Dim bytesReadCount As Integer = 0
    While True
        Dim sb As New System.Text.StringBuilder
        Do
            Try
                bytesReadCount = _socket.Receive(buffer, buffer.Length, SocketFlags.None)
            Catch ex As Exception
                _socket.Close()
                Exit While
            End Try
            sb.Append(System.Text.ASCIIEncoding.ASCII.GetString(buffer, 0, bytesReadCount))
        Loop While _socket.Available > 0
        Dim requestMessage As New RequestMessage()
        requestMessage.DeSerialize(sb.ToString())
        RaiseEvent MessageReceived(requestMessage)
    End While
    RaiseEvent ClientDisconnected()
End Sub

Visual C#

private void BeginSocketConversation(IAsyncResult ar)
{
    threadEvent.Set();
    ClientConnected();
    Socket listener = ((Socket)(ar.AsyncState));
    _socket = listener.EndAccept(ar);
    byte[,] buffer;
    int bytesReadCount = 0;
    while (true)
    {
        System.Text.StringBuilder sb = new System.Text.StringBuilder();
        for (
        ; (_socket.Available > 0);
        )
        {
            try
            {
                bytesReadCount = _socket.Receive(buffer, buffer.Length, SocketFlags.None);
            }
            catch (Exception ex)
            {
                _socket.Close();
                break;
            }
            sb.Append(System.Text.ASCIIEncoding.ASCII.GetString(buffer, 0, bytesReadCount));
        }
        RequestMessage requestMessage = new RequestMessage();
        requestMessage.DeSerialize(sb.ToString());
        MessageReceived(requestMessage);
    }
    ClientDisconnected();
}

Object serialization

The limited resources of a mobile device require an efficient method of transferring data and commands between the device and the host machine. Due to their large size, the .NET remoting libraries and the binary serialization libraries provided by .NET 2.0 are not available in the .NET Mobile Framework. I chose custom serialization to facilitate the transfer of objects. While less flexible, this enabled objects to be transferred using very little bandwidth.

Implementing the AddIn.Launch method

The custom server object created in the previous section encapsulates all the grunt work of socket-level protocol, accepting connections, serializing / deserializing message objects, and data transfer. Within the AddIn class implementation, all we have to do now is instantiate the Server class, indicating the port to listen on:

Visual Basic .NET

Public Sub Launch(ByVal host As AddInHost) Implements IAddInEntryPoint.Launch
    _wmcHost = host
    _waitForExit = New System.Threading.ManualResetEvent(False)
    _server.Start(DEFAULT_PORT)
    System.Threading.Thread.CurrentThread.Priority = Threading.ThreadPriority.Lowest
    _waitForExit.WaitOne()
End Sub

Visual C#

public void Launch(AddInHost host) 
{
    _wmcHost = host;
    _waitForExit = new System.Threading.ManualResetEvent(false);
    _server.Start(DEFAULT_PORT);
    System.Threading.Thread.CurrentThread.Priority = Threading.ThreadPriority.Lowest;
    _waitForExit.WaitOne();
}

We also perform two other critical tasks at this time. First, we assign a reference to the AddInHost to a private member variable for later use. Second, we reduce the priority of the add-in’s main thread and use a ManualResetEvent to put it to sleep until Media Center is closed. The reason for this relates to the nature of an add-in’s lifetime within Media Center. The Media Center add-in hosting process will only allow an add-in to execute for the duration of its Launch method. This means that as soon as the Launch method returns, the add-in and any child threads it has spawned will be terminated. For this reason, we must keep the add-in alive by blocking the Launch method from exiting.

Media Center manipulation

Using the communications layer and socket listener developed in the previous sections, we can finally get to the task of performing something useful with the input requests. By subscribing to the custom Server object’s MessageReceived event, the AddIn class’s OnDataReceived method will automatically be invoked when a new request message is received from the listener:

Visual Basic .NET

Private Sub OnDataReceived(ByVal message As RequestMessage) Handles _server.MessageReceived
    Select Case message.RequestAction
        Case RequestMessage.Action.PauseMedia
_wmcHost.MediaCenterEnvironment.MediaExperience.Transport.PlayRate = PlayRates.PLAYRATE_PAUSE
        Case RequestMessage.Action.VolumeUp
           _wmcHost.MediaCenterEnvironment.AudioMixer.VolumeUp()
        Case RequestMessage.Action.VolumeDown
           _wmcHost.MediaCenterEnvironment.AudioMixer.VolumeDown()
        Case RequestMessage.Action.NextMedia _wmcHost.MediaCenterEnvironment.MediaExperience.Transport.SkipForward()
        Case Else
    End Select
    SendAcknowledgement(message)
End Sub

Visual C#

private void OnDataReceived(RequestMessage message) 
{
    switch (message.RequestAction) 
    {
        case RequestMessage.Action.PauseMedia:
            _wmcHost.MediaCenterEnvironment.MediaExperience.Transport.PlayRate = PlayRates.PLAYRATE_PAUSE;
            break;
        case RequestMessage.Action.VolumeUp:
            _wmcHost.MediaCenterEnvironment.AudioMixer.VolumeUp();
            break;
        case RequestMessage.Action.VolumeDown:
            _wmcHost.MediaCenterEnvironment.AudioMixer.VolumeDown();
            break;
        case RequestMessage.Action.NextMedia:
            _wmcHost.MediaCenterEnvironment.MediaExperience.Transport.SkipForward();
            break;
    }
    SendAcknowledgement(message);
}

The RequestMessage class shown above is a custom object, originally created by Windows Mobile 5 application running on a connected mobile device. The transport object was then serialized on the device, transmitted, deserialized in the listener service, and raised to the add-in class via the MessageReceived event. The RequestAction property is an enumerable type indicating the type of action to take within Media Center. The Media Center API exposed by the AddInHost object (_wmcHost) can then be used to actually perform the desired Media Center operation. Finally, we send an acknowledgement message to the mobile device.

Implementing the Windows Mobile 5 remote client application

After completing the Media Center add-in, the mobile application is relatively simple by comparison. The remote application’s role is to present the user with a user interface similar to that of an actual remote control. The remote application directs user input to the listener add-in, and displays any response data if necessary.

Implementing the socket client

The design of the socket client is much simpler than that of the socket server. All execution will be performed on the primary thread. The client begins by establishing a connection with an add-in server. Once established, the socket client sends and receives data synchronously over the socket. Consumers of the socket client need only call the Send method, which will return with the transactional response:

Visual Basic .NET

Public Function Send(ByVal request As Message) As String
    Dim responseString As String = Nothing
    Try
        If ((Not (_socket) Is Nothing) _
                    AndAlso _socket.Connected) Then
            Dim requestString As String = request.Serialize
            Send(requestString)
            responseString = RecvSynchronous
            Return responseString
        End If
    Catch ex As Exception
        Return Nothing
    End Try
    Return responseString
End Function

Visual C#

public string Send(Message request)
{
    string responseString = null;
    try
    {
        if (_socket != null && _socket.Connected)
        {
            string requestString = request.Serialize();
            Send(requestString);
            responseString = RecvSynchronous();
            return responseString;
        }
    }
    catch (Exception ex)
    {
        return null;
    }
    return responseString;
}

Adding the UI layer

With the communications layer in place the next step in our remote implementation is the user interface. In this final stage, we hook up UI controls to construct the request messages that will be sent to the host service. However, before we do that we must first connect with the Media Center host machine. Here’s a look at the connection configuration screen:

Figure 6 - The configuration screen on the mobile device

Once we’ve specified the host and port of our running Media Center add-in service, we can click the “Connect” button to initialize the TCP/IP socket connection. Using the TCP Client class developed earlier, the code required to handle this event is simple:

Visual Basic .NET

Private Sub btnConnect_Click(ByVal sender As Object, ByVal e As EventArgs)
    Dim host As String = Me.txtHost.Text.Trim
    Dim port As String = Me.txtPort.Text.Trim
    _client.Connect(host, Convert.ToInt32(port))
End Sub

Visual C#

private void btnConnect_Click(object sender, EventArgs e)
{
     string host = this.txtHost.Text.Trim();
     string port = this.txtPort.Text.Trim();
     _client.Connect(host, Convert.ToInt32(port));
}

Once connected, the user can navigate the application using the provided tabs at the bottom of the screen. Since this application is intended to function as a remote control, there is a standard media control screen:

Figure 8: The control screen on the mobile device

Nothing exotic here, but the basic media control functionality you’d expect from a remote is available. Here’s a sample of the code required to support the “Stop” button’s click event:

Visual Basic .NET

Private Sub btnConnect_Click(ByVal sender As Object, ByVal e As EventArgs)
    Dim host As String = Me.txtHost.Text.Trim
    Dim port As String = Me.txtPort.Text.Trim
    _client.Connect(host, Convert.ToInt32(port))
End Sub

Visual C#

private void btnStop_Click(object sender, EventArgs e)
{
    RequestMessage message = new RequestMessage();
    message.RequestAction = RequestMessage.Action.StopMedia;
    message.Data = String.Empty;
    string responseString = client.Send(message);
    ResponseMessage response = new ResponseMessage(responseString);
}

The UI form uses the connected Client object to execute the Stop command. First, the form constructs a Request message, populating the type of action desired (StopMedia). Next, the Request message is passed to the Client class, where it is serialized for transport and sent over the connected TCP socket. From there, the running Media Center service will receive the request, perform the media stop, and send an acknowledgement. The Client then returns a Response message, which will contain a Boolean indicating if the request was successful or not.

On a Media Stop request, examining the Response object is not very informative. However, for other commands, the Media Center add-in service can be designed to return any kind of information required of the host. The Detail screen is a good example:

Figure 9 - The detail page

When a song or video is currently playing, the above screen can be used to retrieve any metadata associated with it. The event handler for the screen’s “Refresh” button looks similar in form to the Stop button’s handler:

Visual Basic .NET

Private Sub btnRefreshDetail_Click(ByVal sender As Object, ByVal e As EventArgs)
    Dim request As RequestMessage = New RequestMessage
    request.RequestAction = RequestMessage.Action.GetMediaMetadata
    Dim responseString As String = _client.Send(request)
    Dim response As MediaMetadataMessage = New MediaMetadataMessage(responseString)
    For Each item As MediaMetadataMessage.MediaMetadataItem In message.Data
        If ((Not (item.Value) Is Nothing) AndAlso (item.Value.Length > 0)) Then
            Me.txtDetail.Text = (Me.txtDetail.Text + (item.Key + (": " + item.Value)))
            Me.txtDetail.Text = (Me.txtDetail.Text + "" & vbCrLf)
        End If
    Next
End Sub

Visual C#

private void btnRefreshDetail_Click(object sender, EventArgs e)
{
    RequestMessage request = new RequestMessage();
    request.RequestAction = RequestMessage.Action.GetMediaMetadata;
    string responseString = _client.Send(request);
    MediaMetadataMessage response = new MediaMetadataMessage(responseString);
    foreach (MediaMetadataMessage.MediaMetadataItem item in message.Data) {
        if (item.Value != null && item.Value.Length > 0){
            this.txtDetail.Text += item.Key + ": " + item.Value;
            this.txtDetail.Text += "\r\n";
        }
    }
}

This time, however, the Response object has a list of metadata keys and values, which are then enumerated and displayed in a textbox. This Response object was originally populated by the Media Center add-in service:

Visual Basic .NET

Private Sub SendMediaMetadata()
    Dim response As New MediaMetadataMessage()
    Dim val As String
    For Each key As String In _wmcHost.MediaCenterEnvironment.MediaExperience.MediaMetadata.Keys
    val = _wmcHost.MediaCenterEnvironment.MediaExperience.MediaMetadata.Item(key).ToString()
    response.Data.Add(New MediaMetadataMessage.MediaMetadataItem(key, val))
    Next
    response.ResponseIndicator = MediaMetadataMessage.ResponseCode.Success
    _server.Send(response)
End Sub

Visual C#

private void SendMediaMetadata() 
{
    MediaMetadataMessage response = new MediaMetadataMessage();
    string val;
    foreach (string key in _wmcHost.MediaCenterEnvironment.MediaExperience.MediaMetadata.Keys) 
    {
        val = _wmcHost.MediaCenterEnvironment.MediaExperience.MediaMetadata.Item[key].ToString();
        response.Data.Add(new MediaMetadataMessage.MediaMetadataItem(key, val));
    }
    response.ResponseIndicator = MediaMetadataMessage.ResponseCode.Success;
    _server.Send(response);
}

After receiving a request from the mobile device for the currently playing media’s metadata, the Media Center add-in service constructs a list of custom objects (MediaMetadataItem). It populates this list by enumerating properties of the AddInHost object, through the namespace MediaCenterEnvironment.MediaExperience.MediaMetadata. It then sends this list on the Response object, where the mobile device will inspect and display the data, as shown above.

The last feature that the mobile remote application provides is the ability to select specific media to play based on a list of available media on the host. This functionality is provided for audio, video, and images:

Figure 10 - Music and Video list management

The mobile application requests the list of available media in a similar fashion to the Details screen implementation. The resulting list of files is then bound and displayed in a DataGrid. The Media Center add-in service can then be instructed to play individual songs or videos using the AddInHost’s MediaCenterEnvironment.PlayMedia method.

Mobile Application UI design considerations

Developing on the mobile platform introduces design challenges not found in Windows Forms applications due to the small amount of screen real estate available. Many typical form layouts found in Windows Forms applications won’t work well on a mobile device’s small screen. When developing for a mobile application, try to keep the user interface as simple as possible. Window containers and managers such as a tabbed control enable the developer to functionally divide an application into logical components. This alleviates the clutter created by having too many controls in a single window. Also try to keep your text and controls as simple and large as possible. This makes the application easier to view and manipulate, especially in outdoor or bright conditions.

Conclusion

Once complete, the remote application gives you a level of control simply not available on hardware-based remote controls. I really enjoyed working on this application because it gave me a chance to integrate a number of different technologies into a single implementation. Be sure to download the code and take the remote for a spin. For those not familiar with all of the components used in this article (Media Center add-in services, socket communication, installer and assembly signing, etc.), don’t be intimidated. The Microsoft-provided SDK packages for both parts of the solution make creating your own add-in projects a snap. Plus, the technical challenges unique to this project have already been overcome! Feel free to modify my implementation, or reuse the included socket classes to create an add-in all your own. Finally, please post feedback or questions here or at my blog.

About the Author

Matt Ivers is a software engineer at Chicago-based Clarity Consulting. He has extensive professional experience developing .NET solutions in both Visual C# .NET and VB.NET. Check him out at his blog or through the Clarity blog site, Clarity Blogs.

References

Windows Media Center SDK 5.0
Windows Mobile 5.0 Smartphone SDK

How to: Sign an Assembly using Visual Studio 2005
How to: Create a Windows Installer File for a Windows Media Center Add-in

Windows Media Center - SDK Overview
Windows Media Center - Understanding the Basics
Windows Media Center - Development Tools
Windows Media Center - AddIn example: "Time Travel"

Using an Asynchronous Server Socket

Controlling Your Lights with Your PC

Coding4Fun — Thu, 21 Dec 2006 05:59:06 GMT

Chris Walker
ControlThink LC

Difficulty: Easy

Time Required: 1-3 hours

Cost: $50-$100

Software: Z-Wave PC SDK

Hardware: Z-Wave PC SDK

Download:

December 20, 2006

Controlling your lights with a remote is pretty cool, but doing it from your PC opens up a whole world of fun possibilities.

In this article, we’ll add your computer to the Z-Wave network which we set up in the previous article. We’ll run software to demonstrate how to set up and activate scenes with the PC. And then we’ll see how easy it is to write our own code and totally personalize the system.

What you need

For this project, you’ll need a copy of ThinkEssentials, our Z-Wave PC SDK, and a compatible Z-Wave USB Stick. Here, we’ll use the Z-Wave PC SDK bundle which includes all three. You can get it for $69 from http://www.controlthink.com.

Intermatic’s HA22 USB Stick; we’ll plug this into our computer.

Once you have the kit, simply plug the Z-Wave USB stick into your PC. If a USB extension cable was provided, plug the USB stick into it instead and then move the USB stick away from walls and metal objects for best reception. Finally, install the USB stick drivers and both software products (all of which are on the CD).

Now that the software and hardware are installed, we’re ready to get started.

Adding your computer to the Z-Wave network

To add your computer to the network we set up in the previous article, we’ll use the ThinkEssentials software (although you can also join a network with a line or two of code—see the Z-Wave PC SDK Primer sample code ). Go ahead and start the software up now. Then, switch to the Advanced Settings tab on the left side of the screen.

If you haven’t set up your Z-Wave network with a remote already, you could set it up with your PC instead--using the ThinkEssentials software or by writing some code. If you’d rather go that route, you can find full details in the Z-Wave PC SDK Primer .

The ThinkEssentials Advanced Settings tab; we’ll add our computer to the network here.

On the Advanced Settings tab, click the “Join Existing Network” button. This will put our USB stick into a mode where it can be added into an existing network. On your HA09 (Tabletop Remote), flip open its lid and press and hold the INCLUDE button for a few seconds until it displays “COPY”. If you have an HA07 (Handy Remote) instead, hold down INCLUDE until the red and green LEDs start flashing. Finally, press the CHANNEL 1 ON button to start adding your PC to the network. This process may take five or ten seconds to get started.

The JOIN EXISTING NETWORK button (left); holding the INCLUDE button (right)

Once your computer is added to the network, ThinkEssentials may close automatically and save the changes. Simply restart the software.

Controlling your devices from the PC

Switch to the Home tab in ThinkEssentials, and you’ll see icons for each of your devices at the bottom-right corner of the window. To turn them on or off, simply click on them. Go ahead, try this now. If you have lamp modules or dimmable light switches, simply right-click on them for dimming options.

If you’d like, you can also draw your home’s floor plan, set up mood lighting (scenes), set up scheduled events for those scenes, etc. I’ll leave these to your experimentation; if you need any guidance, a shortcut to the User’s Guide is included in the Start Menu Programs folder alongside the software.

Turning on lights from Visual Basic Express or Visual C# Express

When you’re done experimenting with the ThinkEssentials software, go ahead and close it so we can use the Z-Wave USB stick from Visual Studio Express. You can download Microsoft’s Visual Studio Express. If you’ve set up any scheduled events, you’ll need to right-click on the software’s system tray icon and select “Exit” from the pop-up menu.

To completely shut down ThinkEssentials, right-click on its tray icon and click Exit.

Now, we’re ready to get started controlling our lights using Visual Studio Express. With Visual Studio Express, we can personalize our home in unlimited ways. For now, we’ll start out simple and turn on the lights.

Creating our Visual Basic Express and Visual C# Express project

With this sample, we’re going to turn on all of our lights. So to prepare for this sample, go ahead and turn off all the lights connected to Z-Wave devices (plug-in modules).

Then, start up Visual Basic Express or Visual C# Express. Create a Windows Application named “TurnOnLights”. Once you’ve created the project, select “Add Reference…” from the Project menu, switch to the dialog’s Browse tab, and then add in the ControlThink.ZWave.dll file that came with the Z-Wave PC SDK. If you don’t know where it is, look in your Program Files folder for a ControlThink and Z-Wave PC SDK folder.

To add the Z-Wave assembly to the project, select Add Reference from the Project menu…

In the Add Reference dialog, change to the Browse tab and then add in ControlThink.ZWave.dll.

Once you have added in the Z-Wave assembly, double-click on the default form; this should open up the Form_Load method in code. Once there, we’ll create an instance of the ZWaveController object. This will let us connect to our Z-Wave network with the USB stick. In the Form_Load method, add the following code:

Visual Basic

Dim zwaveController As New ControlThink.ZWave.ZWaveController()

Visual C#

ControlThink.ZWave.ZWaveController zwaveController = new ControlThink.ZWave.ZWaveController();

Next, we’ll connect to the network. It only takes two lines of code to get “online” with the home.

Visual Basic

zwaveController.Connect()

Visual C#

zwaveController.Connect();

Now that we’ve created the necessary code to connect to the network through our Z-Wave USB stick, we’ll add just a few more lines of code to turn on all the lights. Every device in our network is ultimately based on the ZWaveDevice object, and this class gives us the ability to turn on and off devices as well as change their dim level so we’ll use it here.

Let’s also include a Try…Catch block here; our remotes and some other devices cannot be turned on and off and consequently throw an exception if we try.

Visual Basic

For Each device As ControlThink.ZWave.Devices.ZWaveDevice In zwaveController.Devices

Try

device.PowerOn()

Catch ex As Exception

End Try

Visual C#

foreach(ControlThink.ZWave.Devices.ZWaveDevice device in zwaveController.Devices)

{

try

{

device.PowerOn();

}

catch(Exception ex)

{}

}

That’s it. Run your code, and watch your lights turn on!

Of course, you can also turn everything off. To do that instead, just change the PowerOn method to PowerOff:

Visual Basic

For Each device As ControlThink.ZWave.Devices.ZWaveDevice In zwaveController.Devices

Try

device.PowerOff()

Catch ex As Exception

End Try

Visual C#

foreach(ControlThink.ZWave.Devices.ZWaveDevice device in zwaveController.Devices)

{

try

{

device.PowerOff();

}

catch(Exception ex)

{}

}

What to try next

Now that you’ve experienced the basics of using Z-Wave from Visual Studio Express, here are a few ideas you can use to personalize your own home:

1. device.Level can be set to 0 for off, or 1-99 for dim levels (99 = full on).

2. zwaveController.Devices is a collection of all the devices in your network. Each of those devices has a unique ID on the network called a Node ID. Access the devices individually by index, or use zwaveController.Devices.GetByNodeID(…) to access each device by its unique Node ID.

3. Alarm Clock sample from Coding4Fun, and customize it to turns up the heating set point 30 minutes before the alarm goes off.

About the author

Chris Walker is President and Chief Software Architect of ControlThink, creator of the Z-Wave SDKs for .NET platforms, and is an outspoken advocate of reliable home control technology. He is determined to make home control technology easy to use and affordable for all homeowners.

Decking Out Your Home Entertainment System with Theater-style Lighting

Coding4Fun — Thu, 16 Nov 2006 22:22:35 GMT

	This article walks through how to get that real movie theater feeling at home using the Intermatic HomeSettings Kit.
Chris Walker ControlThink LC Difficulty: Easy Time Required: Less than 1 hour Cost: $100-$200 Software: None Hardware: Intermatic Home Settings Kit Video: Watch the Channel9 Video

To deck out your home entertainment system, typical options include buying a bigger TV or a better speaker system. But for something really unique and cool, add automated lighting to yours for less than $100 to give it that real movie theater feeling.

In just a few minutes, you’ll be dimming the lights when movies start and will have the coolest system around!

What you need
For this project, you’ll need a Z-Wave® remote control and two Z-Wave plug-in lamp modules. Here, we’ll use Intermatic®‘s HomeSettings™ Lighting Control Starter Kit (model HA101K). I found it for $99 at Lowes, although you can buy it at other retail stores or online.

You’ll also need 4 AA batteries.

NOTE: if your lighting is built-in and controlled by switches, you can pick up Z-Wave light switches from any manufacturer and use them instead of the plug-in modules—but you’ll want to follow the switches’ installation instructions or hire an electrician to wire those up.

Intermatic’s HomeSettings Lighting Control Starter Kit (model HA101K)

You’ll quickly notice that this system is wireless. There have been powerline home automation systems in the past, but those have often been plagued with reliability problems. But don’t let that worry you: Z-Wave devices are wireless and will even act as mesh-networked repeaters automatically. If you’re not familiar with how that works, just know that it’s quite a reliable system.

Hooking up the lights
Since we’re using plug-in modules here, there’s no need to break out voltage meters or screwdrivers. Simply plug the lamps into the modules and then plug the modules into the wall. Also, be sure to turn on the lamps themselves.

Plugging lamp into module (left); module plugged into wall outlet (right)

Adding the lights to the remote
Now, we just need to add the lamp modules to the remote control. Make sure there are batteries in the remote, and flip it open to reveal the INCLUDE and DELETE buttons.

To add a lamp module to the remote, simply press and release the INCLUDE button. The display will show a small “INCL” indicator in the top-right corner of the LCD and will flash “TRANSMITTING.” Then, press the button on the lamp module. The remote should flash “SUCCESSFUL” indicating that it now recognizes your module. You have just paired the lamp module with your remote!

Go ahead and repeat this now with your second lamp module.

Pressing the INCLUDE button (left); pressing the button on the device (right)

Setting up the lighting scene
For our home theater experience, we want to fade the lights off when we start the movie and turn them back on just slightly when the movie is over so that we don’t blind our movie-watching guests.

Let’s add the lamp modules to scene one on the remote. This is a quick three step process.

NOTE: there are six sets of scene buttons (on and off for each scene) on this remote. Pressing the SHIFT button will switch to scenes 7 through 12, so make sure you’re currently looking at scenes 1 through 6; if you’re not, simply press the SHIFT button.

First, simultaneously press and hold both the ON and OFF buttons for scene one. After holding down these two buttons for three or four seconds, the display will show “LEARN” in big text. Now, press and hold the INCLUDE button—and don’t let go of it quite yet.

While you’re holding down the INCLUDE button, press the button on the lamp module to include in this scene. If the lamp module is off or turns off, press the button on the lamp module again to turn it on. When the lamp is on, go ahead and release the INCLUDE button on the remote. That’s it!

Now, go ahead and repeat this process for the other lamp module, again using scene one.

Pressing scene one’s ON and OFF buttons (left); pressing and holding the INCLUDE button (right)

Settling in for the ultimate home theater experience
Now it’s time to grab your favorite movie and snack, gather your friends, and enjoy your new setup. To turn off the lights (with nifty ramping effect), press scene one’s OFF button. When the movie is over, press the ON button. If you want to dim the lights up or down, simply hold down the scene’s ON (dim up) or OFF (dim down) button respectively.

Lights off! Pressing scene one’s OFF button sets the mood for “Batman Begins”…

More cool things to do with your new setup
One of the great things about Z-Wave is that you can do new things with your existing devices and can add on new devices anytime. Here are a few cool things to do with your new setup:

1. Set up a second scene with the lights at 20%; this will be good to switch to when the movie is over so you don’t blind your friends.

2. When I’m tired, getting out of bed wakes me up. Set up your bedroom instead and enjoy this new convenience when going to bed (or getting up!)

3. For an even better home theater experience, wire up your overhead lights—or add in motorized blinds. If it has the Z-Wave logo on it, it’ll work with your system.

About the author
Chris Walker is President and Chief Software Architect of ControlThink, creator of the Z-Wave SDKs for .NET platforms, and is an outspoken advocate of reliable home control technology. He is determined to make home control technology affordable and available to the average homeowner.