Tag Archives: SmartMirror

SmartMirror project part 2: Software

In the first part of this series I looked into how to assemble a two-way mirror so that an Android phone behind it can be used as an information hub. Of course this is only one part of the story, cause we also need some software to display all this useful information on our Android device. Now, obviously there is already such software available, however I decided to write my own version from scratch for the following reasons:

  • to learn more about Android application development
  • it had to support Android Gingerbread (API level 10)
  • have all the modules important to me here in the UK
  • I like coding …

I will not fully describe all the code in this post, you can find the complete git repository here, but instead only pick the parts I think need some more detailed explanation. So lets start …

All about modules

I chose the common software pattern of  separating the final presentation of the data from the task of gathering it. All the data generation is done in modules which are independent of the UI. Most of those modules are using a remote web service for the information retrieval and therefore need to run asynchronous to the application main thread. By using OkHttp asynchronously for the remote access this is basically provided for free. A module is based on the abstract class Module which acts as connection to the UI. Every module will call postData when new data is available and postNoData when there is no data available or the module wants to clear any previous data it had sent. Obviously there are also some simple modules like the ClockModule which don’t use any web service, but also don’t need the complex asynchronies behaviour cause they executing rather quickly. Each module defines it own update rate cause this really depends on the nature of the data itself. Train time updates are rather frequent in contrast to the sunrise/sunset times which only change twice a day. Speaking about those two modules, let’s have a look which modules are available at the time of this writing:

  1. Time/Date: ClockModule
  2. Sunrise/Sunset: SunTimesModule
  3. Weather information from the UK Met Office: ForecastMetOfficeModule
  4. Travel time to work by car: TimeToWorkModule
  5. Next tube trains from a specific station: TflModule
  6. Next national rail trains from a specific station: NationalRailModule
  7. Upcoming calendar events for the next few days (API level >= 23): CalendarModule

Actually there is an eighth module called the TrainJourneyModule. This is a meta module combining the output of the tube and national rail train times modules into one. It sorts them by departure time so both types are shown interleaved.

For the data query part, Met Office, Tfl and Google Maps are using JSON. This is pretty standard nowadays and Java on Android has built-in support for parsing it. I was looking into more advanced JSON parsing libraries like gson and jackson but decided for the really simple task of parsing one static response it is not worth it to pull in those big dependencies. Maybe I will change that it the future, but for now the present code works just fine.

Looking at JSON data in Firefox is much more comfortable by using a JSON document viewer add-on like JSONView.

A completely different beast is the data query task for the National Rail module. National Rail uses the SOAP protocol and compared to JSON the authentication is already complicated. All web services use some type of API access token which is unique to every developer. This exists to prevent misuse of the public API, but in some cases also to limit the number of times an API can be accessed per day. To successfully prove to the National Rail web service that we are who we are we need to add an authentication token to the SOAP envelope header:

Namespace soap = Namespace.getNamespace("soap", "http://schemas.xmlsoap.org/soap/envelope/");
Namespace ldb = Namespace.getNamespace("ldb", "http://thalesgroup.com/RTTI/2014-02-20/ldb/");
Namespace typ = Namespace.getNamespace("typ", "http://thalesgroup.com/RTTI/2010-11-01/ldb/commontypes");
Element env = new Element("Envelope", soap);
/* Header */
env.addContent(new Element("Header", soap).
        addContent(new Element("AccessToken", typ).
            addContent(new Element("TokenValue", typ).

BuildConfig.NATIONALRAIL_API_KEY contains the API key. The rest of the body contains the actual request:

Element dep_request = new Element("GetDepartureBoardRequest", ldb).
    addContent(new Element("crs", ldb).
    addContent(new Element("numRows", ldb).

Now, you may think this is simple enough, but I can assure you I needed quite some time to figure this out, cause the server on the other side is pretty strict on how this structure should look like. And as you can see SOAP uses XML which makes the request creation and the response parsing even harder. Luckily jdom2 exists which greatly simplifies this task. Here you can see the complete xml request:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <typ:AccessToken xmlns:typ="http://thalesgroup.com/RTTI/2010-11-01/ldb/commontypes">
    <ldb:GetDepartureBoardRequest xmlns:ldb="http://thalesgroup.com/RTTI/2014-02-20/ldb/">

For more information on the various formats used by the different providers, have a look to their developer portals:

User interface

The user interface is quite simplistic. There is no way to interact with the application because it is behind a mirror. The only function the application has is to display the output of our modules in a nice and readable way. All the text and icons are white on black background. This ensures for best contrast behind the two-way mirror and makes it possible to see the information even on normal daylight. I tried to make all state changes animated, see for example AnimationSwitcher for the details. One interesting challenge is the code for switching to fullscreen for the different supported API levels. A nice feature of Android is that you can use new functionality of newer Android versions in your application and check at runtime if this new functionality is available. In your build.gradle you define the minimum supported Android version (minSdkVersion) and also the version your application is written against (targetSdkVersion). At runtime you check Build.VERSION.SDK_INT against the Android version when a specific feature was introduced. Only if this is equal or greater you can use this code. Now if you are below the required Android version you either need to fallback to other code providing similar functionality or your application can’t provide support for this particular feature (see e.g. CalendarView).  Main.java contains four different functions for switching into fullscreen. In API level 13 and below the only way to do this was to set the FLAG_FULLSCREEN for the main window. Starting with API level 14setSystemUiVisibility was introduced which allows a more fine grade configuration of the behaviour of the Android system when your application is in the foreground. Over the following Android versions more and more flags have been introduced.


MirrorHub doesn’t come with any runtime configuration. Remember the user is not able to make any changes when the phone/tablet is attached to the mirror. All the configuration is done at compile time by setting the various options in the gradle.properties file. You can use gradle.properties.example as the start for your own experiments. It contains things like the location for the weather forecast or the tube/train station you like to have departure information displayed on your mirror. But most importantly it contains the API keys for the various web services in use as outlined here.

I also added a runDebug/runRelease task to gradle which allows you to start the application without any physical interaction with the device. Together with an app like WiFi ADB you can install and run the application remotely while the device is attached to the mirror. However, please note that WiFi ADB needs a rooted device.

Final thoughts

I think the app has a lot of nice feature already. It runs on my mirror 24/7 and works just fine. I still have some more ideas for modules, like a caldav module to display calendar events from a caldav server, because the Android version that I use has no direct calendar support. I also played around with the proximity sensor to detect some hand waving in front of the mirror. It works fine with just the device, but unfortunately not when the phone is behind the mirror. The code is still there, so if you have some ideas how to make something like this work let me know in the comments.

Finally here are some screenshots while MirrorHub is running:

For some images together with the mirror see the end of the first post.

SmartMirror project part 1: Hardware

A while ago I stumbled over an article about a smart mirror using some old unused Nexus 7 as the driver. I was instantly fascinated by this project because it is low-cost, needs some real world handcraft and of course involves writing some new code. Obviously the last part is my favourite bit so I quickly came up with some new ideas which where not available in the original software. However, I will come to that part later in a separate post. I still had my trusty old HTC Desire in the cupboard and after proofing it still works I decided to give it a go. This first post will guide you through the really simple process of making the base for the mirror. It will not involve any liquid glue … I promise 🙂

Parts you need

The following is a list of items you need for this project. I added links to the items I used:

  1. two-way acrylic mirror (I made it A4 in size, but a little bigger is probably better)
  2. black card sheets (I used size A3; in any case it should be bigger than your mirror)
  3. double-sided clear tape
  4. cardboard
  5. Android phone/tablet
  6. scissors

As you notice this is basically just plastic and cardboard which makes the final mirror reasonably light.

Assembling procedure

First I cut four pieces of cardboard to the size of the mirror. Four of them stacked together matched roughly the thickness of my phone and you may need more or less layers depending on the thickness of your phone/tablet and how thick the cardboard itself is (Pic. 1). I stuck one by one together using the double-sided tape. After deciding that the screen should be in the lower right corner I placed the phone on the cardboard and drew around it (Pic. 2). Make sure there is enough space on all the sides for the tape. The hard part of cutting out the shape of the phone from three layers of cardboard had to be done next (Pic. 3/4). I did the last layer in a separate step and skipped the cut-out of the usb cable shaft. This gives the structure a bit more strength.

The black card sheet will serve two purposes:

  1. shield the light of the phone buttons/battery indicator from being visible through the mirror
  2. make the base looking more … well … nice

I cut one black card sheet 2 cm bigger than the mirror on each side and stuck it on the back of the cardboard. Than I bended the overlapping part to the front and fixed it with tape as well (Pic. 5). Now again you need to cut out the phone shape. A black card sheet the size of the mirror now goes on the front of the cardboard. Next you need to be careful! Just cut out a rectangle the size of your active phone screen, excluding  any buttons and the bezels (Pic. 6). I did this in several steps making sure not to remove too much. Finally stick the plastic mirror on the front of the cardboard.


As you see in picture 7 and 8 this came together quite well. If I would do it again I would probably go for a bigger mirror around the size of A3. Also I would make the base slightly smaller than the actual mirror so that it looks a bit more free-standing.

In the next post I will talk about the software you can see in the pictures, but if you are curious you can have a look at my github repository.