My son is a Minecraft addict. If fact four of my five kids might qualify for that description. I think there is probably more redeeming value learning how to engineer things in that world then in most video games, but I would like him to learn some skills for the real world. When the new Netduino 3 Wi-Fi came out I was inspired do a project with it that could cut the cord from previous wired Ethernet or USB boards. Now we could put a web server anywhere and connect it to real hardware of our choosing. I had just gotten a set of security cameras and a NVR(Network Video Recorder) it was cool using remote desktop to get to the app, or the FLIR cloud and see what was going on at home when I was miles away. A few times I realized that one of us had left the garage door wide open when no one was at home. I wished at that moment that I had a long range remote to fix the problem. Calling the kids to make them shut it is a rather effective remote unless they are not home either!
So with this problem in mind I got on Amazon and ordered a few parts and started talking thru the problem with my son who is 14 this august and seeing where he would take this. He loved automating everything in Minecraft and makes all sorts of cool stuff connected with switches. I told him this would let him try that in real life. We talked about what we would need to come up with a solution. First we discussed the high level functionality we wanted. An app with buttons that would open and close the doors as well as display the current door status and maybe even a picture to confirm the door state visually. Once the functional concept was there I had him identify ways we could implement this. We could hack apart a remote control and wire relays to the buttons so when we closed the relays, it would signal the doors. We could connect into the hard wired switch on the wall and signal that with a relay. We looked at other off-the shelf internet garage door openers. They were expensive and did not seem very adaptable, and assumed one unit per door. We had three doors to deal with so cost was prohibitive to buy anything else.
We experimented with each of the wiring designs. We decided on the hard-wired version and worked to that end. We mocked up the code for a simple web server and had a set of commands to read status, and then a command to toggle the door state. We tested the relays and finally got a reliable 250ms delay time to hold the door to make sure it toggled each time. We also realized we would have no idea where the door was at any time so we needed positive feedback of the doors state. My son Hal (subtract 14 from 2015 and you get 2001, no coincidence!) suggested we use burglar alarm magnets and reed sensors. He had helped me wire up the alarm system that I had revived after years of being off-line and we had to replace a few of the sensors. I had walked thru with him how to wire and test each of the sensors to make sure they worked. He decided if we put a single magnet on the top of the door, we could place the sensor an inch away at the top and bottom limits of the garage door range and then we could tell if it were open, closed, or moving. He also suggested that since we knew where the garage *had* been we could know if the moving was opening or closing.
He is not up to the C# code yet, but I walked thru line by line what was going on so he understood. We also wired all of the sensors and pulled and stapled all the wired going to and fro. We found we could run two wires from the relay to the garage door unit to trigger the open/close toggle. We then wired the magnetic sensors to data in lines and activated the internal pull down resistors so we had a clean zero level when the sensor was open. We used a 4 channel relay board and made sure that we initialized the state in such a way that when we power cycled the unit that the door would not accidentally toggle.
One we had all the functionality bench tested we deployed the release binary to the Netduino. There are a few tricks here. You have to set the WIFI SSID and password settings thru a utility on the Netduino. The other important thing I learned is to set aside a IP/MAC address lease on your Wi-Fi router to make sure you always know the IP address of the board. I could have exposed the board directly to the internet by enabling a port pass-thru on the router, but since I had my own server already on the net, I could tunnel thru it and abstract out the access to the device. That also meant I could have it run security and map other aggregate services together thru one interface. There are services like If This Then That that could have done some of this for me, as well as a number of home hubs that given the right plugin could have integrated into their applications. Since half the fun of a project like this is building the whole stack we did.
We created some ASPX web pages on my server to manage communications with the opener and this allowed us to add more logic without having to deploy new code to the Netduino on the roof of the garage. It turns out while Wi-Fi makes it easy to move it out there, pushing code there is a different matter altogether. We wired in all the sensors and the control lines and tested it out for real using the web browser in my phone over the Wi-Fi and It all worked just as we wanted so we moved on to the app.
Since we all have Windows Phones in our house, I started out with a data bound panorama like app framework and wired up the data provider to the functions that processed the status bits from the web calls. The web calls would run async on a timer, with the timer events firing more rapidly when the UI was triggered by button taps or launching the app, then the timer rate would slow down so as to not use lots of traffic, but still keep the UI up to date. I could have done long polls or Windows Phone Push notifications but this was effective and quick to write and debug. I had to implement a INotifyPropertyChange interface to have the UI bound to my data model update when the status changed in the background. With this quick hack I had the buttons and status feedback in an app on my phone in less that 30 minutes! Since I could slide from page to page I asked Hal what he would add to the pages. He wanted the security camera images. Video was cost prohibited, so I looked at taking snapshots of the current video frame from the IP based full HD network cameras and then scaling them to phone sized images. I used a ASPX page on the home webserver to proxy the thumbnails. This was not as easy as I hoped it would be. I had to capture traffic from the web app on the NVR and reverse engineer the API from that. It turned out it had a way of doing a frame grab with a URL, but only if you had a valid session ID. So I implemented a Digest protocol login with a WebClient and logged in to the NVR, got a session ID, then pulled frames from each camera, then scaled them to phone size.
Now I had a page with garage control, camera feedback, then another swipe to move to a set of thumbnails of the security camera, and a tap to show a larger version of each of those. The next page I wired up to my burglar alarm status and added buttons to arm and disarm the alarm remotely.
After we were done I realized that open/close was not all the information we could want. It would also be nice to know if a card is parked in the spot or not. So Hal and I got back to it and tried out a ultrasonic range sensor and tested it out with the spare Netduino. We were able to tell if the bay was empty or not by mapping the ping time on the sensor to Speed of sound and getting the approximate distance. It the floor was the closest object the distance would be above a threshold, if a card was there it would be below. This could give us status on when a car was done. It also could give us triggers such as "Ring an alarm when mom gets home" or if all the cards are gone turn off the air conditioner or heater. We have not yet wired of the distance sensors, but we know it will work now and it opens up some cool options.
It was fun working with my kid on a project like this. He is learning the basics of reading input, sensing state and acting on changes. He is also seeing how you can layer a system and link small sets of functionality together break a large project down into a set of simple services.
Jonathan (with Hal)
The Netduino 3 Wi-Fi http://www.netduino.com/netduino3wifi/specs.htm
The Relay Shield http://www.amazon.com/gp/product/B00BOZ7V02
Magnetic Proximity Switch http://www.amazon.com/gp/product/B0011W4YNK