Subscribing to DigiLinX

As a developer who is interested in working with the NetStreams DigiLinX infrastructure, you have two basic integration options. This blog has focused mostly on the first option, which is to develop Lua drivers that allow the DigiLinX system to issue commands to an external system. A good example of this is the Proliphix driver I recently published.

The other option, which I haven’t yet covered on this blog, is to communicate with DigiLinX using their ASCII protocol. DigiLinX devices communicate with each other by broadcasting specially formatted ASCII instructions to a multicast address, allowing other devices who are interested to “tune in” for updates. These messages contain data that contains either control or status information. My DigiLinX debugger works in this fashion, listening for all debug messages that arrive at the multicast address.

But what if, as a third party system, we’re not interested in every message that is sent across the wire? What if we’re writing an application that simply wants to know when a song on a stream has changed or when a specific SpeakerLinX amplifier has been turned on? DigiLinX offers us an alternative solution in this case. Using Dealer Setup, one can configure what NetStreams refers to as a “subscription”. By providing an IP address and port number, the integrator can direct the DigiLinX system to sent ASCII messages to a device using UDP. The integrator can further specify what they are interested in by subscribing only to those services which interest him. Let’s look at an example.

Setting Up A Subscriber

My goal for this exercise is to be alerted whenever an event occurs within an amplifier in one of the rooms. Maybe I’d like to shut off one amplifier when another one is turned on. Maybe I’d like to update a UI with the current volume level in each room. Maybe I just need an example.

In this test project, I have one SL220, one TL380, and a CL100. I’ve also added a dummy SL220 to give my system interface a second room.

Project List

I’d like to configure my development machine as a subscriber. I’ll write code that listens on a specific port for messages arriving from the Digi system. To do this, from within Dealer Setup 2.2 I click Tools -> Edit Subscribers. I see the following screen (click to expand):

ConfiguredSilverSubscriber

As you can see, I’ve specified that my development machine Silver, with an IP Address of 10.15.15.56, will be listening on port 10590 for messages from the Bedroom and Study player services. There are other services available to me as well, but they’re outside of the scope of this post. For more information on which services are made available by which devices, refer to the DigiLinX Programming for 3rd Party Control document available in the dealer area on NetStreams.com.

Once my machine is subscribed, I’ll send the updated configuration to the devices and wait for them to restart. When they do, status updates will start being delivered to my machine for the services I’ve subscribed to. Let’s see what they’re saying to me by writing code to listen on that port.

A Basic Client

I’m going to throw together a basic client that simply dumps the arriving messages to the console. Using Visual Studio.Net, I’ll create a new C# Console application. Visual Studio creates a default Program.cs file with a static void Main method in it. This is the code that will run automatically when the console app is executed. I’ll stub out a method call:

private static void Main(string[] args) {
    TestSubscriber();
}

Now I have to write my TestSubscriber method. It need to:

  1. Open a socket and bind to port 10590 (the subscriber port)
  2. Create a buffer that’s large enough to handle the incoming messages
  3. Tell the socket that we want the next arriving UDP packet and then
  4. Write it to the console.

Easy enough, since I do much the same thing with my DigiLinX Debugger. Sorry about the formatting:

private static void TestSubscriber() {
  Socket aSocket = new Socket(AddressFamily.InterNetwork,
                              SocketType.Dgram,
                              ProtocolType.Udp);

  IPEndPoint anEndpoint = new IPEndPoint(IPAddress.Any, 10590);
  aSocket.Bind(anEndpoint);
  char[] myTrimChars = new char[] {”, ‘\n’, ‘\r’};

  while (true) {
      byte[] buffer = new byte[8192];
      int numBytes = aSocket.Receive(buffer);
      Console.WriteLine(”{0} – {1}”,
          numBytes,
          Encoding.ASCII.GetString(buffer).Trim(myTrimChars));
  }
}

And there you go – that’s all the code you need to act as a subscriber. Fire it up, press a few buttons on the TouchLinX while listening to audio, and you’ll see the following:

Subscriber Output

All that’s left now is to write some code to parse the messages, looking for those that interest you. Again, information about the formatting of these messages can be found in the Programming for 3rd Party Control document published by NetStreams. 

Lots of Updates!

I just released updates to the following:

DigiLinX Debugger – look for a lot more stability, as well as some more advanced logging and filtering options. I feel like I’m close to a 1.0 release, having squashed a few bugs that have been bothering me for some time.

HTTP Library – Yup, another release today. This is a good one, as I managed to catch a number of edge case bugs and smack them down. I also did some code readability updates and improved some tracing output. I’ve had this running in a dev environment for days, being called every 10 seconds, and my ControlLinX hasn’t caught fire.

Proliphix Driver – This is the target I’ve had in my sights for some time now. With the HTTP library finally stabilizing, I’ve been able to wrap this bad boy up into an alpha release. Want to play but don’t have a Proliphix thermostat? No problem – you can use my Proliphix emulators on an XP or Vista machine that has Internet Information Services installed and fool Digi into thinking that it’s talking to a live thermostat.

The Proliphix driver is definitely an alpha build, but I wanted to get a release out to the community for a couple of reasons. First, I wanted to draw a line in the sand and declare the driver to be ready for general consumption. This should help me version in future changes at a regular pace. Second, I’ve had a number of direct requests for the driver, and I’ve seen a couple of questions on the forums about the feasibility of integrating another HVAC vendor.

I’ve also started another CodePlex project to host the Http and Proliphix assets. Version management for plain text code files is a pain without something like CodePlex, and I wanted to be sure that people were always using the proper version of my drivers.

That’s it! Have at them!

A Proliphix thermostat driver for NetStreams’ HVAC interface

The DigiLinX system has a nice looking interface that allows users to monitor and control the current status of their HVAC system. The screen’s appearance and layout make it one of the more compelling features of the Digi system. Unfortunately, it was built to support the AprilAire line of automated thermostats. I’ll resist my compulsion to lambaste the AprilAire system, but as a whole it

  • costs a heckuva lot to put together because of the cost of the individual parts, and the number of devices required to make it work
  • only offers setback programming if you purchase a “system controller” which can cost consumers ~$850. This is amazing – several thousand dollars into an install you may find that you can’t turn the A/C off when you go to work every day unless you do it manually at each thermostat.
  • has been reported that it occasionally stops responding to third party system commands, including NetStreams, Crestron, and AMX
  • offers no remote administration or interface without the part mentioned above

Anyway, it’s safe to say that I’m not a fan. At all. I suppose it could be that pile of thermostats, controllers, and temp sensors that I have sitting in the corner of my office. I ripped it out of my home after the above points came to light when I began testing the Digi integration. A nice lesson that only cost me ~$1500. Yes, I’m bitter.

Enter Proliphix

But good things come to those who hate overpriced crap! I discovered the Proliphix line of thermostats when looking for a replacement for my AprilAire system. Proliphix thermostats are great, and include the following features:

  • They are IP based, like DigiLinX, and require no central brain to operate.
  • They have an embedded web server that enables remote monitoring, setback scheduling, and the ability to set vacation cooling schedules
  • They have a fully documented open API that is based upon the open standard of Http
  • They offer advanced features found in top quality systems, such as humidity monitoring, remote sensors, and alarms
  • They have a free service that allows you to monitor all your thermostats while away from home. The thermostats report to a central server stored at Proliphix, and you can pull up a dashboard in a web browser from anywhere.
  • They are competitively priced for the feature set that they provide

More good news for those of you who have wired for an AprilAire system – they use the same cabling approach. A Cat-5 run back to a head end connects the thermostats to a mini hub which provides network access and Power Over Ethernet to the devices themselves.

So once I decided on Proliphix, I went to work on writing a driver to tie the HVAC interface found in DigiLinX to the API made available by Proliphix. The API allows a programmer to retrieve and configure many of the settings and statuses related to the HVAC system. By sending simple HTTP POSTs to a device, one can change the setback temperature, query for current zone temps (both local and remote), determine if the fan is running, and more. The API is secured with a username and password configured when you first install the thermostat, which you pass along with your commands using the Basic Authentication scheme. I adopted an implementation of HTTP from LuaSocket, which I’ve posted on my projects page. This library allowed me to focus on the basics of the API in my driver implementation.

Driver Design

I won’t get into the details of how the driver works in this post, but I wanted to point out one design decision that I made. Since a home usually has more than one thermostat in it, I broke the driver into two files. The first, pro.lua, is simply the setup and scheduler for the implementation. It is responsible for binding to the thermostats during the initial load, and then scheduling and executing the status updates.

The second part of the driver is a module that marries the Proliphix API and the DigiLinX system. ProliphixAdapter.lua is self-contained, and is an implementation wrapper for a single thermostat. The host driver (pro.lua) actually creates one adapter for each thermostat in the system. This gives good code isolation, and makes it easier to determine which thermostat is generating trace messages.

I plan to write more posts in the future explaining how the driver works, especially if I see questions from the community on it.

Caveats and Configuration

Since this driver was not built by NetStreams, you must configure it manually by editing the text of the driver file. In pro.lua you will see  the following code:

thermostatIPlist = {”10.15.15.55″,”10.15.15.56″}
userName=”testuser”
password=p@ssword1

Replace the list of IP addresses with the IP addresses of the thermostats that are installed in the home. You should ensure that the thermostats are on the same subnet as the DigiLinX system, and that a patch cable connects the SwitchLinX to the POE hub that the thermostats are wired to. You will also want to replace the username and password values with the admin username and password for your Proliphix thermostats. Note that all thermostats must have the same username and password configured. That’s is for pro.lua, unless you want to flip debugging categories on and off.

ProliphixAdapter.lua doesn’t require any configuration if you have Proliphix thermostats installed. However, the driver also supports using the asp emulators I developed during the authoring of this driver. If you would like to use these instead, drop them in the root of the web server for the development machine that will emulate the Proliphix thermostat, and change the doDebug in proliphixadapter.lua variable from false to true. Note! The drivers ship in Debug mode!

Read the comments at the top of both files for more information on driver assumptions and caveats.

Lastly, here is a list of all the files that will need to be installed on the ControlLinX that hosts the HVAC interface. You’ll need to use the Dealer Setup “Load Files ” feature, as explained in my Sample HTTP Driver posting to download them all. As I mentioned, the actual driver to use as the Driver File for the ControlLinX is pro.lua.

  • http.lua
  • httpPrivate.lua
  • url.lua
  • ProliphixAdapter.lua
  • pro.lua

Don’t Skip This Section!

I hope everyone who downloads this driver reads this first: I’m releasing this driver before I get it fully working. Yes, that’s right – the driver only works a little. Occasionally. My decision to release this was based upon wanting to help people understand the HVAC interface, and to offer more code samples to the DigiLinX development community. This driver should be treated as an alpha build, and should not be installed at a customer location. If you want to play with it without installing a Proliphix ’stat, you can run it against the Proliphix emulator I wrote in classic ASP.

Also, these drivers contain a ton of debugging messages. The sheer volume of messages introduced into your network may have some adverse effect on your Digi system. When I feel that the drivers are stable enough, I will maintain two versions of each of these files – one that has debugging stubs left in, and another that doesn’t.

This driver is the result of a lot of work, so I’d really appreciate any feedback, bug reports, or overall comments from those who use it.

More information on where to obtain the drivers can be found on my projects page.