Monitoring a BBQ Smoker with a Pub/Sub Message System

by Mike Linnen 3. January 2010 20:43

At one of the Charlotte Alt.Net meetings I gave a presentation on how I utilized a simple Pub/Sub messaging architecture to allow for several applications to communicate across machine boundaries.  This blog post won’t be about that system I demoed at the meeting, but it will be about a suggested example that will get the Pub/Sub concept across in a simple way.

Requirements 

The system that is being built to demonstrate the Pub/Sub concept will fulfill the following requirements:

  • Simulate a BBQ Smoker
  • Monitor the temperature of a BBQ Smoker
  • Provide feedback at what temperature the Smoker is currently at.
  • Provide visual Alarm indicators that identify three states of the temperature
    • Low
    • Normal
    • High
  • Ability to have multiple smokers
  • Ability to have multiple monitors monitoring a single smoker

Pub/Sub Infrastructure

The Pub/Sub Infrastructure was taken from a previous MSDN article written by Juval Lowy.  The infrastructure uses WCF as the communications mechanism. The source code I have in my sample project might be a little different than what was in the original MSDN article so I will explain how it is organized in the Visual Studio Solution. 

First a little background on what makes up a Pub/Sub Messaging system.  A Pub/Sub Messaging system has three components: Broker, Publisher and Subscriber.

Broker

The broker is the enabler.  The broker’s job is to connect publishers with subscribers. The broker contains a list of subscribers and what messages they are interested in.  The broker exposes endpoints that allow for subscribers to subscribe to messages and a publisher to publish interesting messages.  In my example solution the broker is a WCF service that is hosted by a console application (Broker.ConsoleHost).  Since this is a WCF service it can also be hosted under IIS or a Windows Service just as easily.

The WCF Contract for messages that the broker accepts for the BBQ Smoker is as follows:

image    

Since the broker also manages what subscribers want to subscribe to a contract also exists for subscribers as follows:

image

Publisher

The only thing the publisher knows is that when it has anything to publish it simply sends the message to the Broker.  The publisher has no idea on the final destination of the message or if there even is a final destination.  This promotes a very decoupled system in that the publisher knows nothing about their subscribers.  In my example solution the publisher is the Smoker device and it publishes the, Smoker Alarm and Temperature Changed messages.  A Smoker Alarm message is published when the smoker reaches a temperature that is too low of too high.  A Temperature Changed message is published when the temperature of the smoker has changed at all. 

Since the Smoker Temperature is simulated by a slider on the UI here is the event that fires when the slider changes and publishes the Alarm and Temperature changed messages:

image

The _publish object in the above code snippet is simply a web service proxy that calls the broker.

Subscriber

A subscriber communicates with the broker to tell it what published messages it is interested in.  The subscriber in my example solution is the Smoker Monitor.  The job of the subscriber is to listen for Smoker Alarm and Temperature Changed messages and display information to the user when these messages arrive.  The Smoker Alarm message will turn the display Yellow when the temperature is too low and Red when the temperature is too high.  The temperature changed message will update the screen with the actual temperature that came from the smoker.

The subscriber needs to register the class that implements the interface (IMessage) that will be the callback that gets executed when either of messages are received.  In my example solution this is done in the constructor of the Form1 class in the Smoker Monitor project as shown below:

image

Additional logic exists in the SmokerAlarm (callback) method that sets the UI components to the proper color and text based on the alarm state as shown below:

image

Conclusion

Since the broker is capable of hooking up multiple subscribers to a single publisher you can run multiple monitors across multiple machines all monitoring the same smoker.  This is very powerful because the monitors could be providing the same feedback to the user just in a different location of the house or the monitor could be providing feedback via a different means. For example another monitor could be created that sent a text message or a twitter message when the alarm is published.  These new monitors can be added without changing the existing contract.  Even a third party could create a monitor that did some special thing on published messages and you could run their monitor without changing the broker or smoker.      

A zip that contains the entire code for the BBQ Smoker Monitor via Pub/Sub messaging can be found here.  Feel free to download the code and look at it in more detail.  Also take a look at the ReadMe.txt for additional information on how to run the application.

I hope to expand on this in a later project that will allow me to create an actual embedded device that can detect the temperature of a smoker instead of using a simulated Smoker Device.  This embedded device will have to be able to publish the messages to the broker so that a PC does not have to be connected to the smoker.

Tags: ,

Using Microsoft Technologies for the FIRST 2007 robotics competition

by Mike Linnen 20. December 2007 23:20

I have been meaning to blog about one of the coolest projects I have been involved with for a while now but I have been too busy to do so.  Back in June of 2006 I got involved with Bob Pitzer (Botbash), Chris Harriman and Joel Meine, in providing a software/hardware solution for the FIRST Robotics Competition for their upcoming 2007 season.  FIRST is a non profit organization that is dedicated to teaching young minds about science and technology through several fun filled robotics competitions.  Make sure you check out their web site to see how you might be able to get involved in this great program.  Also check out the 2007 video archive to see how exciting these events can be.  Make sure you pay attention to the computer graphics that are superimposed over the live video because that is what we built! 

The software and hardware we built was used to manage multiple 3 day events over a months time frame.  This ended up being around 40 events across the US in roughly 30 days.  Each event had anywhere from 30 to 70 teams competing.  Each day of the event had to be executed in an efficient manor in order to complete the tournament style competition.  The system was designed at a high level to do the following:

  • Lead an event coordinator through the steps of managing a tournament
  • Maintain a schedule of matches over a 3 day period
  • Inform the audience of match scoring in real time
  • Broadcast live video mixed with real time match score information to the web
  • Inform the other competitors in the Pit area of upcoming matches, match results, and real time team ranking details as each match completes.
  • Control the field of play from a central location
  • Gather scoring details from judges located on the field
  • Provide periodic event reports for online viewing as the tournament progresses

All of this was done using Microsoft .Net along with various open source .Net projects to speed up the development process and provide a robust system that was easy to use by various volunteers. 

I used various pre-built components in order to build this system.  Since this application needed to interface with multiple hardware components and provide a rich user interface a Windows Forms application was going to be required.  I chose the Patterns and Practices Smart Client Software Factory (SCSF) as the basis for the Windows Forms framework.  I had used this Framework in a previous project and I knew it would give me the modular design I needed to accomplish the functional goals of the design.  I wanted a solution that allowed for me to do a lot of Unit Testing as I was going to be the only developer doing the work and the amount of QA testing was going to be very small.  Since the SCSF used a Model View Presenter pattern I knew that testing would not be an issue.  Also SCSF uses a dependency injection pattern that would also lend itself very well for unit testing.  Another benefit of the dependency injection pattern was that I could mock out some of the hardware interfaces so that I did not have to have a fully functional robot arena in my home office!  I actually developed the hardware interface without ever connecting to the hardware on my development machine.  This was done by establishing a good interface and using a mock implementation of this interface to complete all the business logic without having any hardware.  Then at a later date we implemented the real hardware layer and even to this day I use the mock implementation for all development work since I do not have an arena in my office. 

For the data access layer I choose to use SubSonic as it provided a very fast way to generate the data access layer from a database schema.  Using SubSonic gave me the flexibility to grow the data model really fast as the solution emerged over time.  The database back end was SQL Server Express 2005.  Since the solution only required a small set of clients and it had to be disconnected from the Internet  SQL Server Express was right for the job. 

Deployment of the application was done with ClickOnce in a full trust environment.  This enabled me to make changes to the application throughout the tournament and the software on each playing field computer remained at the most recent version.  The click once deployment also managed the upgrade process for any database changes as well. 

The central control of the field of play was handled by a single .Net Win Forms application that interfaced to Programmable Logic Controllers (PLC) via a third party managed library.  This library allowed for me to set PLC memory locations as well as monitor locations without having to worry about the TCP/IP communications protocol.  This was a great time saver as I could concentrate on high level business value rather than low level communications.  Since the low level communications was not required I did not have to spend a lot of time with debugging hardware/software integration problems.

Another key area of integration was providing a Hardware UI that consisted of LCDs and Buttons that enabled a field operator to manage the match process without using the computer keyboard or mouse.  This was done using a serial port communicating to a BX24 from Netmedia.  The user would actuate buttons on the hardware UI in order to start or stop the match as well as many other tournament related functions.  The hardware UI would lead the operator to the next step by flashing the most appropriate button for the current point of the match.  This made the operators job a lot easier. 

The audience needed to be informed about what is going on during the event.  An announcer was always present at these events but the audience also needed visual cues that made it apparent what was going on.  So I created a win forms audience display application that would provide the detail the audience needed.  This detail was not only displayed to the live audience but it was also broadcast over the Internet to individuals that where not able to attend physically.  This audience display showed live video as well as match statistics mixed together on one screen (you can see this in action in the video links I mentioned above).  This screen was projected up onto a huge screen so all audience members could see with great ease.  The live video mixing was done using a green screen technique that is often used with the weatherman on local news stations.  Basically a green color is used in a color keying process to superimpose the live video over the green color.  The screen snapshots below give you an idea of the type of information that was presented to the audience as well as the web broadcast.

 

2007-02-21_135125      2007-02-21_135226

AlliancePairingSample      2007-02-21_135201

Well I could go on and on about details of the application we wrote to make the 2007 FIRST FRC event a great success but I think I will save it for a set of later posts.  Also I have been working on the software for the 2008 season that uses WPF for an even more richer user experience (can anyone guess I used some animations!).

Hero robot is coming back!

by Mike Linnen 16. December 2007 09:21

Heathkit was an awesome company that supplied electronic kits for educational purposes back in the 80's and 90's.  Their products where a bit on the pricey side but where else could you get a TV in kit form that you had to build.  I bought an Oscilloscope from them and put it all together in several weekends.  I also had a single board computer that was sold by Heathkit that I did not actually build but I used it for teaching myself how to program using machine(Assembly) language.

Well Heathkit is back in action and one of the best products they offered is also back.  The Hero Robot of the 80's is now called HE-RObot.  Back in the 80's you could get this robot in kit form or fully assembled.  I was never able to purchase one but I worked for a company repairing electronic equipment and the owner's son ended up getting one.  It was one of the coolest things I saw and it probably was one of the reasons I became so interested in robotics in the first place.  I don't remember all the specifics of the original robot but from what I remember it had sonar ranging, optical wheel encoders, light sensors, current sensors, and sound sensors.

Well the new Hero is a partnership between White Box Robotics and Heathkit.  The new HE-RObot comes with an onboard PC with an XP operating system and Microsoft Robotics Studio as the programming environment.  Finally a product is in the market place that combines both of my passion's: Robotics and Microsoft .Net.  This is a very powerful robot but I do not see too many details on what sensors will be offered.  On the web site it looks like it will include IR, Web Camera, and Audio.  I sure would like to see a few more details on what other capabilities it will have as far as sensors go. 

The web camera is going to be real powerful as a sensor.  I was fortunate enough to evaluate an ER1 robot from Evolution Robotics.  I wrote an article about this experience called 30 Days of ER1 back in 2003.  The live video pattern recognition routines put a whole new meaning to navigating your environment.  I am pretty sure White Box Robotics has licensed the software that handled pattern recognition from Evolution Robotics so the HE-RObot will have the same capabilities.

Interfacing a PC to the outside world Part 2

by Mike Linnen 24. November 2005 20:26
Interfacing a PC to the outside world Part 2

In Interfacing a PC to the outside world Part 1 I mentioned that I wanted to work on a set of articles to discuss interfacing your PC to the outside world.  In part 2 I am going to continue the series and talk about what my first connection to the outside world is going to be. 

 

There are a number of devices that are designed to communicate over I2C.  I2C is a serial interface developed in the 1980's at Phillips Semiconductor.  The architecture allows for multiple devices to co-exist on the same 2 wire bus.  You can get more information on the I2C bus at the following: http://www.esacademy.com/faq/i2c/. 

 

There are a considerable number of devices that support the I2C bus.  A compass can be used to determine direction.  A sonar module can be used to detect obstacles.  A motor controller can be used to drive motors on a robot.  A servo controller to drive hobby servo motors.  All of these I2C capable devices (and several more) can be found at www.acroname.com.  I have done some research on PC I2C devices but so far everything I have found is fairly expensive.  I believe I can make a device that will bridge the PC to I2C gap and open up the world of I2C devices to PCs.

 

So a .Net I2C library is going to be the first project that I will do.  The library will support communicating on the I2C bus to other devices.  The consumers of this library should not care how the I2C communication is actually implemented.  So the primary goal of this exercise is to architect a provider model for communicating to these devices.  The benefits of this model allows for different I2C providers to be used without affecting the consumers. 

 

The first provider I will be creating will be a micro controller RS232 I2C Provider.  This will be  a small device that sits between the PC and the I2C devices.  The micro-controller's job is to intercept the serial commands from the PC and convert them into I2C commands.  I will be using a BX24 from Netmedia as this micro controller.  Later I will create a parallel port I2C provider that can be used in place of the micro controller RS232 provider.

 

The PC to BX24 I2C solution is a little more expensive than I intended to start with.  However I have a few BX24s lying around from other projects so it won't take a dent out of my pocket.  Also I have a Deventech compass to try the library out on.  Besides I also intend to use the BX24 for other interfacing projects.

 

    

Tags: , , ,

Robotics

Interfacing a PC to the outside world Part 1

by Mike Linnen 23. November 2005 10:15
Interfacing a PC to the outside world Part 1
 

I have been reading some of the Coding4Fun articles that are on MSDN.  Several of the articles are focused on connecting your computer up to external devices and writing .Net code to interface with the devices.  This has always been a main interest of mine since I am interested in robotics and home automation.  The resent release of .Net 2.0 has made some nice features available for doing serial communications.  Also Microsoft has made the Visual Studio Express editions freely available for 1 year.  This makes up a great solution for the general hobbyist to play with software and hardware.  So I thought it was time that I start my own set of articles on building software and integrating it to hardware devices.

 

So I gave it some thought on where to begin.  What project will be a prime candidate?  How would I build the foundation so I could leverage different hardware solutions to a given interface problem.  So I decided on a few goals to keep in mind about the project:

  • Provide a solution to an interfacing problem that could be used in many projects.
  • Build the library using .Net 2.0.
  • The library should extract the consumer from any hardware implementation.
  • The library should be testable without hardware implementation. 
  • The library can use external pluggable components to fulfill the interface to the hardware itself.  So 3rd party components can be built and plugged into the library.

 

Stay tuned for a series of articles on this project

Tags: , ,

Robotics

.Net 2.0 Serial Port

by Mike Linnen 19. November 2005 17:53
.Net 2.0 Serial Port

Hey looks like the new .Net 2.0 supports a serial class that makes serial communications a snap.

http://msmvps.com/coad/archive/2005/03/23/39466.aspx

I need to get going on some project to try this out.  Maybe a PC to BX24 project that will be useful in my house.  I need to give it some thought. 

VS.Net 2005 and NUnit

by Mike Linnen 17. November 2005 21:50
VS.Net 2005 and NUnit

Well I have been looking at VS.Net 2005 some since it has released.  I wanted to try out some of the new features.  Well I am pretty attached to using NUnit so once I got a little bit of code going in VS.Net 2005 I decided it was time to try NUnit.  Fortunately there is a new iteration release of NUnit (2.2.3) that works with VS.Net 2005. 

So I downloaded it and wrote my first test like I always do.  Create a test project, add a reference to NUnit, add a new class, put a TestFixture attribute on the class, and add a public method that returns void that also has the Test attribute. I then proceeded to fire up NUnit GUI and run the test. However the test I wrote does not show up in the GUI. I fiddled around with the test code for a while and I even downloade the NUnit source code to try and figure out why my test was not seen by NUnit. Well after about 30 minutes of messing around I realized that when you add a new class to VS.Net 2005 project it looks like the following

using System;
using System.Collections.Generic;
using System.Text;
namespace ProtoSystem.Scrum.Business.Tests
{   
   class Class1
   {
   }
}
I never noticed the fact that public does not appear before the keyword class. So the test class could not be seen by NUnit.

Copy podcast program update

by Mike Linnen 30. June 2005 20:26
Copy podcast program update
Noticed another little problem with my copy podcast program. I need to do some clean up on the directories of the destination (SD card). After I delete podcasts on my pocket PC many empty folders start to accumulate. So I need to add a process to clean up empty folders on the destination folder.
So far I have been using this program for almost 2 weeks. I like this setup a lot better than just relying on Doppler and Microsoft Media Player to manage the synchronization process. All I need to do is make the copy program a little more friendly and add a few abilities to the Media Player to support bookmarks and auto delete.

About the author

Mike Linnen

Software Engineer specializing in Microsoft Technologies

Month List