In December I will be presenting this talk for the Charlotte Alt.Net users group. This talk is less about presenting and more about actually coding up a device that connects to the cloud.
This is not a sit back and watch the speaker meeting. As a participant in this project you will be building the devices that complete a Simulated Home Security system. There will be some basic code that is written for you but for the most part it will be your job to complete the code and make the device functional. The cloud service that connects all the devices via a message bus will already be completed and deployed to Windows Azure for you to use. Your device will publish and subscribe to messages on the bus.
Come out to the event and learn how to connect a Netduino Plus to Windows Azure.
Head on over to the meeting invite and sign up now.
I am re-vamping my home automation strategy from a home grown publish/subscribe messaging system to use MQTT instead. I was using Azure Service Bus to connect remote devices such as my phone with devices in my home such as my lawn irrigation system. This worked well as a messaging infrastructure for remote devices but I wanted to have a more standard messaging infrastructure that could work in my home network without connectivity to the outside world.
A few reasons why I switched to MQTT:
- Light weight
- Many Clients already exist for many platforms and languages
- Support for on-premise message broker
- Support for off-premise message broker
- Support for bridging brokers (on-premise to off-premise)
- Fast
- Used by companies like COSM (was Pachube) and Github
- Simple topic subscription model that is also powerful
- I don’t want to write a message broker
For the most part I am moving toward having devices in the home that are relatively dumb and having services running on a home server that add the smarts behind the devices. This will give me the flexibility to change the behavior of the system a lot quicker without the hassle of tearing apart a device to upgrade the software on it. This means I needed to have my services available all the time. Placing these services in the cloud for mission critical things would mean I am left with devices in the home that cannot function while my internet connectivity is down. This was the biggest reason I moved to an off the self pub/sub infrastructure like MQTT.
Like most messaging protocols, MQTT works on the notion of a topic and a message. The topic is just a unique way of addressing a message. I struggled a lot and I probably will continue to struggle on what my topic structure for my home automation should look like. One thing I wanted to do is try to make the topics readable so that troubleshooting message problems would be easier. Hear are a few standards I am trying to settle on:
- When a device or service changes state and wishes to notify interested parties the topic will end with /event
- When a device or service wants to know the status of another device or service the topic will end with /getstatus
- When a device or service receives a topic /getstatus the response topic it generates will end with /status
- When a device or service needs to set the state of another device or service the topic will end with /set
Here are a few examples of topics and messages for my irrigation system:
| Description | Topic | Message |
| Zone 1 turned on | irrigation/zone/event | z1 On |
| Request the current schedule from the irrigation service. The service will respond to this request by publishing various status topics | irrigation/schedule/getstatus | |
| Set the time that the irrigation service should start watering | irrigation/schedule/starttime/set | 09:00 AM |
| Status of the schedule start time in response to the getstatus request | irrigation/schedule/starttime/status | 09:00 AM |
| Set the days of the week that the irrigation system will water | irrigation/schedule/days/set | MON WED FRI |
| Status of the scheduled days of the week in response to the getstatus request | irrigation/schedule/days/status | MON WED FRI |
| Set the zones that the irrigation system will run and how long | irrigation/schedule/zones/set | z1 10 z2 8 z3 10 |
| Status of the scheduled zones in response to the getstatus request | irrigation/schedule/zones/status | z1 10 z2 8 z3 10 |
| Sets the zones to run on the irrigation device and how long | irrigation/zones/run | z1 10 z2 8 z3 10 |
MQTT does have a concept of publishing messages with a retain bit. This just tells the broker to hang onto the last message for a topic and when a new subscription arrives the client will receive the last message. I could have used this concept instead of the /getstatus standard that I have show above. I might change over to using the retain bit but for now the /getstatus works for me. I am also making my messages a little verbose as they tend to contain multiple values that could have been broken down into more granular topics.
Overall I really like how simple MQTT is and it is very easy to get a device like the Netduino to understand MQTT messages. I am sure I will make modifications on how I actually define my topics and message body over time as I develop more and more devices and services that do useful stuf in my home.
I am excited about presenting on this topic for the Charlotte Alt.Net users group on May 8th in Charlotte. Head on over to the event posting and sign up to attend.
Here are the details about the talk:
The most recent release of Microsoft Robotics Developer Studio 4 (RDS4) has introduced two very exciting concepts that make building robotic applications a reality to all developers: Kinect and Reference Platform Design specification. The Kinect is the hot device that gives a new perspective on sensing your surroundings. RDS 4 fully supports the Kinect and opens up all kinds of opportunities for awesome applications. Do you want skeletal tracking in a robotics application, RDS 4 gives you that. Do you want to perform obstacle avoidance with Kinect's depth sensor, RDS 4 gives you that. Do you want to simulate a Kinect in a virtual environment to test out your high level code, RDS 4 gives you that. The Reference Platform gives vendors a common design specification for building a working robot that includes sensors, motors and low level control. This allows for a developer that has little hardware experience to get up and running fast. In this session I will introduced you to RDS 4 using the Kinect and an Eddie robot.
Eddie Robot http://www.parallax.com/eddie
Microsoft Robotics Developer Studio http://www.microsoft.com/robotics/