Garage Door Opener Project: Part 1

So a few weekends ago I decided that I’d like to embark on a fun project of making a network enabled garage door opener.  A few weeks ago I was walking home from a neighbors, and found myself wishing I could open the garage from my phone, or ideally from my Band.  This seemed like enough of a pretense to embark on a new project, and after a few weeks of tinkering I’ve emerged with the following working home accessory:

The Plan

When I started this project, I laid out a few key requirements:

  1. Build an application targeting an existing Wi-Fi enabled Raspberry Pi I had laying around.
  2. Build and debug the application on the Pi, and write it in modern C++.
  3. Setup Git on the Pi, and keep the code up in GitHub.
  4. Breadboard the hardware required to switch the garage light and door.
  5. Integrate a temperature/humidity sensor to allow me to play with garage cooling options over the upcoming summer months.
  6. Add a garage door closure sensor so the device can tell when the door is open or closed, so the app can provide open/closed status back to network clients.
  7. Integrate my X10 Firecracker dongle, to allow me to control my existing X10 outlets/lights

The C++ requirement came partly from a desire to tackle a ‘real’ project with the language using modern language features like smart pointers, and to try out some of the Boost library’s programming constructs for asynchronous networking.  I’ve also been playing around with building basic electronic circuits, and making some necessary hardware for the Pi seemed like a fun time.

The Hardware

It took a while to get the electronics working, and I learned a decent amount along the way (even though there really isn’t much to this).  I started trying to trigger my 3.3v relays directly using the GPIO pins on the Pi, and when that didn’t work I had to go back and figure out that GPIO pins can’t drive the level of current required.  I was also using a shift register initially to reduce the number of pins coming off of the Pi, but it ended up being unnecessary and was eventually removed.

Testing first iteration using shift registers

 

The second iteration two introduced some diodes and transistors, and then I was up and running.  I added a couple momentary contact switches to provide local light and door control, and picked up some DHT11 to do my temperature/humidity sensing.

I put everything together on a breadboard, with a plan to solder everything together and put it into a clean enclosure with my couple of surface mounted switches, but I quickly fell in love with the idea of just putting an acrylic top over it, and mounting the Pi and breadboard together on another sheet of acrylic (spray painted black on the back), as-is.  It has a fun look to it, and that might be what I like about the whole project most.

Second iteration of electronics using transistors, diodes, and opto-couplers

Second iteration of electronics using transistors, diodes, and opto-couplers

The one part that sadly hasn’t made the cut yet is the X10 firecracker.  This is a control device I used to have connected to my PC (back when I had a serial port), which works in conjunction with a wireless receiver to send On/Off power commands to outlets and switches throughout my house.  I found and installed an RS-232 shield on the Pi, but later found out that it doesn’t connect the RTS/CTS lines used to power and signal the Firecracker.  Oh well, I’ll think of something in the future…

The Software

I chose CodeBlocks as my IDE of choice on the Pi, after seeing a few recommendations online for people coding in C++ on the Pi.  I was able to target C++ 11 features, and although it took a while to figure out how to get the Boost libraries to link up to my project, the process wasn’t too bad.  In general, however, I wouldn’t recommend that people try to write code directly on the Gen 1 Raspberry Pi, at least when you’re trying to do it using an IDE on top of x-windows.  It’s really slow, not only when trying to compile (which takes a long time even for trivial programs), but even typing code into the editor is noticeably delayed.  I eventually started writing and testing as much as I could in Visual Studio, and then bringing the code files over to the Pi for final testing and implementation.  For final debugging/testing I eventually ended up editing files using VI over SSH to skip the UI overhead on the PI, and that seemed much more usable.

Running CodeBlocks on the Pi

Running CodeBlocks on the Pi

I have the project checked into GitHub, and you can check it out here.  With any luck I’ll actually come back and check in some schematics for the hardware portion of the application, but for now at least the software is up there in case the Pi dies in the extreme heat of my garage over the summer.

Trying it Out

I was pretty excited the first time I was able to trigger the door and light manually using the new Pi-based controller, and even more so when triggering it from my desk.  The design has two LEDs, one that blinks on/off at roughly a one second interval, and one that lights red when the door is open.

Talking to the garage door using Putty

What’s Next?

In the next post, I’ll cover writing Windows Phone and hopefully a  Microsoft Band apps to talk to our garage door.

Open Source release of C# Spyder control library

The software library used for the Spyder Client for the Windows Store is now available for use as a nuget package (for .Net developers), and the source has been made available up on GitHub.  This library provides an implementation of the documented UDP control protocol, and additionally provides some of the ‘secret sauce’ used by richer control clients.  From the GitHub readme:

Key Features

  • Full implementation of the published Spyder UDP control protocol
  • System Config File parsing – provides full Spyder data object model to clients
  • Drawing Data (live view) data stream deserialization (Supports 2.10.8 – 4.0.4)
  • Spyder quick file transfer procotol (QFT) implementation. List, get, and set files
  • Thumbnail Manager – provides background downloading, multi-resolution scaling, and memory lifetime management of system thumbnail images

Consuming the Nuget Package (.Net Developers)

The Nuget package is the easiest way for .Net developers to consume the Spyder client library, and can be used to target Windows Phone 8.1 or later, Windows RT / Store apps, or .Net 4.5 or later desktop applications.  Get it from Visual Studio using the Nuget package manager (see screenshot below).

Nuget Package Info Page:  https://www.nuget.org/packages/SpyderClientLibrary/

Getting the Spyder Nuget Package

Getting the Source

GitHub Project Link:  https://github.com/dsmithson/SpyderClientLibrary

If you want to build the library yourself, peruse the source, or even port it to another platform, head over to GitHub to get access to the source code (link above).  This source uses the Apache 2.0 license, so you can do whatever you want with it.  Please do use the issue tracker or submit pull requests if you have anything you’d like to add or fix, and have fun!

What’s Next?

In future posts, we’ll explore some sample applications that use the library to do common things like control command keys, perform file backup/restore, and possibly even create a display simulator control that works from the Spyder server’s real-time data stream.  I’ll also be working on some general documentation that I’ll post on the GitHub site, so keep an eye on the project’s GitHub page.

Spyder Client for Windows 8.1 – Live Control

One of my favorite areas working on in the Spyder Client for Windows 8.1 was the live view, which not only shows a real-time visualization of the Spyder server’s PixelSpaces, but allows for live interaction and command key creation. While it’s not necessarily new, I thought it would be fun to create a Camtasia video showcasing the live control available from the Spyder Client.  I certainly enjoyed making it, and I hope you enjoy watching it (and using it).

Under the Hood – Leveraging Spyder’s External Control

Internally, the Spyder Client uses the Spyder server’s publicly accessible external control protocol for all control actions performed by the application.  This is for a few reasons, one of the more notable of which is that Windows Store applications do not support .Net Remoting (which is how the Vista Advanced client communicates to Spyder).   If your curious how the Spyder Client is doing something you can simply check out the Spyder server’s logs to see what commands are being executed (see screenshot below).  Just make sure to set the server tracing level to information or success so that the command logs actually appear.  Of course, if you have a specific question, feel free to leave a comment under this blog post.  I’m always happy to help out a fellow coder.

Viewing remote server logs in Vista Advanced

Viewing remote server logs in Vista Advanced

Just in case you don’t already know, the external control protocol documentation is included with the installation of the Vista Advanced client software. If you have Advanced installed, then the external control protocol PDF document is already available from your start menu.

Spyder Client Command Key Visualization

My favorite feature in the Spyder Client for Windows 8.1 is the command key thumbnails it displays.  These thumbnails are smart, in that they combine the live look on screen with the expected execution plan for the command key, resulting in a true thumbnail preview of what the screen(s) can be expected to look like after the command key has executed.  In the video below, I give you a quick overview of this feature in action.

First App in the Windows Store (Yes it’s another Spyder Client)

Historically, when I’m taking a new platform or development tool out for a spin, I end up creating a control client for Spyder.  It’s nice to be able to work against a well-known and well-understood platform, so you can focus on the new and exciting stuff.  In this case, which is no exception, I fired up a Windows Store application targeting the Windows 8.1 platform.  In all truth, I think I started this about 5 months ago, however the project didn’t make real traction until the week of Christmas this year (which I took off from work).  I put forth a hard goal of getting the application into the store by the end of that week, in hopes that I wouldn’t aimlessly squander away my week at home.  At the end of the week, a new application had indeed been introduced to the store, and while it’s pretty ‘fresh’ I’m proud of the results so far.

Check out the app’s official page on this site here

Check out the app and download it from the Windows Store here

Feature Set on Day One (What’s there and what isn’t)

Getting something into the store on a compressed timeline is tricky, and there are always a lot of features that get dropped.  I’ve been reading The Lean Startup, and one of the concepts reiterated regularly is the concept of getting something out there early to collect feedback to iterate against.  Waiting too long for something to be perfect (which isn’t a real thing) means that you can spend an inordinate amount of time working on features that people don’t care about.  This is pure waste, and in a project like this where all development is happening in my free time, there simply isn’t time for waste.  All that being said, here are the features as they exist on day one, and my current view of where they could go in the future.

Note that this is my list, and I’m providing it to you in hopes of hearing some of your feedback.  Tell me what is and isn’t important to you, and together we’ll be able to make this app better.

Main Screen

 

Home Screen

The main screen is the landing page for the application when opened, and displays all servers available on the network, each with a thumbnail sized live view and launch buttons to command keys, function keys, and still image pages.  The functionality is pretty straight forward, so I won’t list out what is there in more detail here, but there are a few things that I would really like to see go into a near future version of the application:

Planned Main Screen / General App Features

  • View of system health / user diagnostics (with launch button to a health screen)
  • Ability to select any of the buttons and open their associated pages in a new window, allowing multiple views to be displayed simultaneously.  This could be a big deal for multi-monitor users, and opens up more complex control and monitoring scenarios for even single monitor users.
  • Sources view / list, showing thumbnails and tally status.  Used in combination with the previous feature bullet, this could allow for drag-drop support onto the live view

Live View

Spyder Client - Live View

This is effectively a display simulator view, designed to give a real-time view of the system’s PixelSpaces and layers using thumbnails pre-configured in Spyder.  Creating a full-featured simulator brings a number of complexities, and this control is very primitive by the standards of the simulator in Vista Advanced.  The live view control will undoubtedly be the benefactor or the majority of near future development work as a result, and to get the most bang for the buck I’ve re-used this same control to provide thumbnail visualizations for command keys and the thumbnail view on the main page.

Live View Features on Day One

  • Preview / Program PixelSpaces
  • Solid Color Borders with bezel luminance offsets
  • Thumbnails for PixelSpaces and Layers
  • Smooth motion views of layers and background transitions

Planned Live View Features

  • Full bitmap borders and shadows
  • PixelSpace Stackups (different view configurations for PixelSpaces)
  • Layer number indicators
  • Interactive control (layer pinch resize, reposition support)
  • Drag/Drop support for sources / stills

Command Keys View

Command Keys

The live thumbnail view within the command keys page is (in my humble opinion) the most interesting feature within the application.  This works extremely well at showing what-if scenarios for recalling relative command keys, but is very limited today by the general render capabilities of the live view control used to generate thumbnails.  I don’t think I can understate this; the renderer is pretty feature light and falls down quickly when showing more than the most basic of looks.  As stated previously though, this will gain all the development benefit of work applied to the live view, and so I think it’s only a matter of time for this to get flushed out.

Command Key Features on Day One

  • Displays user defined register colors for command keys
  • Groups buttons by existing user defined pages
  • Live generated preview of ‘Program’ (Cue 1) look for command key
  • Absolute / Relative Indicator
  • Preview / Program tally indicators

Planned Command Keys Features

  • PixelSpace stackup switching
  • Ability to turn off live view integration with thumbnail previews.  Not sure if anyone would actually want this feature – seems to me like once you have a feature like this you would never want to turn it off (would love your feedback)
  • Option for different button sizes to condense more command keys onto the screen
  • Pinch zoom support to jump between pages quickly
  • 320 pixel wide snap view support
  • Link to a full script grid view showing all command key cues with individual thumbnail previews.  I have a lot of thought into this, and will probably need a blog post all it’s own to describe further.

Stills View

Stills Viewer

The stills view came about early on as a side effect of needing to validate the image file processor / transport software, but was handy enough to keep around.  The Advanced client has the ability to obtain thumbnails from the server in a round about way (once you’ve seen them in the simulator they are cached locally in the ‘C:\Spyder\Images’ folder on your PC).

Stills View Features on Day One

  • View all Still images defined in the Still registers list on the Spyder server in thumbnail form
  • View a full screen view of all images by clicking a thumbnail
  • Ability to save image files locally via the app bar
  • Ability to share one or more selected images using the ‘Share’ charm in windows

Planned Stills View Features

  • Native shape file viewer (custom bitmap border shapes)
  • Native shape file creator, with the ability to simply draw a shape on screen and have it saved onto the Spyder server as a shape file.  This would have the ability to load an image into the background to be used as a stencil, and additionally preview the resulting shape at a number of different source aspect ratios.
  • Different thumbnail sizes to show more thumbnails on the screen at once

Function Keys View

Function Keys

I think the Function Keys view is off to a good start; it works (which helps), and it’s approach of showing a very brief text description of it’s execution action makes it easy to see what the button will do before you actually press it.  An interesting note about function keys:  the Spyder data model actually has support for custom register colors for function keys, but this is not brought forward into the Vista Advanced interface.  The Spyder client has support for displaying custom register colors as it does in the command keys view, and so this will auto-magically start working if this becomes implemented in Advanced in the future.

Function Key View Features on Day One

  • Display of Function key names
  • Display of the type of command key
  • Short text describing the action which will be performed when the key is executed (limited to one line of text, may be clipped depending on things like the number of layers affected)

Planned Function Key View Features

  • A pseudo-tally feature which would evaluate the state of the system and show a red tally indicator if the function key appeared to be in it’s executed state.  An assign source function key, for example, would show a program tally indicator if it’s associated source was already assigned to it’s target layer(s)
  • Relative layer recall support.  Function keys with relative layer/device assignments require the layer/device IDs to be specified at the time of recall, and currently there is no way to provide these when executing a relative function key from the Spyder client.
  • Option for a more compact view of buttons to display more function keys on the screen at once
  • Pinch zoom to quickly navigate between pages

Again, the planned features are on my wish list based on what I think would be great additions.  It’s entirely possible that I’m missing the boat on functionality that I’m just not thinking about, and if you think that’s the case then I’d like to hear from you.  Please leave your comments on this post, and in general let me know what you think of the app.

In a future post I’ll talk about the back-end development, project management, and source control technologies, and possible future directions for the platform.