25. December 2014 21:11
I just posted my initial code for my Garage door project using the Spark Core on github. This is a work in progress and will evolve over time.
20. December 2014 01:21
I recently moved to a new home and I now have 2 garage doors to control instead of one. So I decided to revamp my garage door home automation project by using the Spark Core. This is a fascinating device as it is designed to connect to the Spark.IO cloud service without doing a lot of coding to maintain the connectivity to the cloud. The default firmware in the device allows you to remotely connect to it and invoke functions, expose variables to the cloud service as well as perform pub/sub between devices. Make sure you check out their website to gain a better understanding of all the capabilities of this small packaged IoT controller.
My goals in this project was to achieve the following:
- know when either garage door is opened or closed.
- remotely close or open the garage door.
- have the door automatically close when I go to bed.
- keep track of how long it takes to open/close the garage door.
- if the door starts to take longer to open and close this might be a sign that it needs maintenance.
- automatically open the garage door when I arrive home.
- automatically close the garage door when I leave my home.
- notify me when the door needs maintenance because it has been opened/closed so many times.
- monitor the temperature and humidity in the garage.
- monitor the garage for motion when the security system is on.
- notify me that I left the door open after a specific time of night.
That is certainly a large number of goals and I don’t intend to complete all of them initially but you kind of get the idea of what the possibilities are.
Initially I intended to do all of this for 2 garage doors with one Spark Core, but after thinking about it a bit it made more sense to use at least two Spark Cores.
One thing I decided to do right off the bat is to make sure I have enough sensors that could determine when the door was opened and when it was closed. I have seen other remote garage door projects that simply have one sensor that detects if the door is closed or not. I wanted more inputs so that I could time how long it took for a door to complete it’s open or close command. I want to keep track of this in order to determine if the door will need maintenance when it starts to take longer to open or close. I can also gather a little more analytics around the timing of the door command and the temperature in the garage. I don’t know if I will use this more detailed information for anything or not but I thought it would be fun to play around with.
So I will have 2 magnetic reed switches that I plan on placing on the door track to determine if the door is closed or opened. The status of the door will be 5 different states: opened, closed, opening, closing and unknown. The unknown state will only be for when neither of the sensors are triggered and the device doesn’t know if the door was previously opened or closed. I have most of the code written to handle the basic door operations and I will be sharing that code in a future post.
So stay tuned on future posts on this topic as I move forward with it. Please feel free to give me feedback or ask questions on items I haven’t clarified very well. I am very interested in anyone’s thoughts on the Spark Core as well as home automation in general.
8. November 2014 10:04
I gave a talk at the Raleigh Code Camp called "What can I do with a Raspberry PI". The slide deck is attached to this post for those of you that attended.
Raspberry PIv2.pptx (6.67 mb)
30. October 2013 21:31
I am presenting two sessions in the Raleigh Code Camp 2013 Builder Faire track on November 9th. The first session is called Building a cloud enabled home security system Part 1 of 2 (the presentation). The second session is Building a cloud enabled home security system Part 2 of 2 (the lab). You really need to come to both sessions as the first session explains what you will be building in the second session. Yes I said that right, if you attend the second session you will be building a Netduino based security system that connects to Windows Azure. Check out the project website for more details at Cloud Home Security.
I hope to see you there!!
3. May 2013 21:39
I am presenting 2 sessions in the Carolina Code Camp 2013 Builder Faire track. The first session is called Building a Home Security System – The Introduction. The second session is Building a Home Security System – The Lab. You really need to come to both sessions as the first session explains what you will be building in the second session. Yes I said that right, if you attend the second session you will be building a Netduino based security system that connects to Windows Azure. Check out the project website for more details at Cloud Home Security.
14. February 2013 23:28
I put together a talk that includes a lab on building a security/home automation system using 11 netduinos communicating over MQTT with a broker located in Windows Azure. The attendees of this talk will walk through the lab and build out various components of a security system.
Here is a video demonstrating the various components of the system.
The source for the project can be found on github:
The Security System website is hosted on a Web Role and it contains all the documentation for the lab.
27. October 2012 00:00
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.
1. June 2012 21:09
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)
- 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.
6. May 2012 14:16
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/
4. September 2011 16:57
This is part 3 of a multipart blog series that shows how commands that control my sprinkler flow through the infrastructure and reach the final destination of the Netduino Plus. This video covers what components are used in the system to connect a Windows Phone 7 to the Netduino based Lawn Sprinkler as well as how a Weather Service can send data to the Netduino. So connecting devices to devices and services to devices all using the Azure AppFabric Service Bus.
Here is the video: