Before you attend this event you need to get a few things in order. We don't have a lot of time during the event to spend it setting up your development environment so make sure you check out Getting Ready For the Meeting.
You will be building one of the following devices in the home security system:
Determine which one of the devices that you want to attempt to build. Some of the devices are harder to complete than others. If you want to start out easy then you can do the doorbell device. If you want a tougher challenge then go ahead and try the Alarm Control Panel.
There will be some code that is already written for you so that you don't have to worry about the communication protocols
needed to publish and subscribe to the MQTT message bus. Since the protocol is abstracted away from you
all you need to know is that the MQTT messages are basically made up of two parts: a Topic and a Message. There is a lot more to the MQTT standard that
you can read up on your own but you won't need it for this project. Basically, topics are a series of words separated by a / topic separator.
The message is simply any string. The devices on the bus are expected to understand the topics and message formats, but like all
pub/sub designs the devices don't know about each other. So the topics and messages are the contracts between the devices.
MQTT does not specify that topics need to be a specific number of levels deep nor place any rules around topic definition. However for the purpose of this project we will be placing some rules around how topics are constructed. Each topic will be 4 levels deep and each level will have a special meaning.
The detailed documentation for each device will outline the topics and messages it publishes as well as the topics and the messages it should subscribe to.
There are two main components that already exist in Azure that the devices will interact with: MQTT Message Broker and Master Control Panel. The message broker runs under an Azure Worker Role. The Master Control Panel runs in Windows Azure Web Role. The broker simply routes MQTT messages and has no real home security specific business logic on it. The Master Control Panel manages the state of the security system as well as the business rules around how the security system functions as a whole. SignalR is used to update the client browsers when the state of the security system changes. Take a look at the Master Control Panel for more details on how it functions.
The following diagram shows the communications between the devices in the home to the Azure message broker and eventually to a browser. What is important to notice here is that the devices in the home talk to one another through the message broker.
The following picture zooms in on the 4 different types of devices that are part of this security system. It's a little easier to see the LED's and Switches that are connected up to each Netduino.