Friday, October 24, 2014

Rewriting a Legacy App - Part 1: Looking for the MVP

Okay, so I've been meaning to re-write an application that has been running in my house for 10 years. The original was written in Delphi (which I haven't used for new projects since 2005, so it's been a while), and it's been serving it's purpose. But there are some features that I'd like to add, and some that I don't really need. So, it's time to analyze the existing application, come up with a minimum viable product (MVP), and move forward with a re-write.

[Update: Code download and links to the entire series of articles: Rewriting a Legacy App]

Home Automation Hardware
The application is to control home automation hardware that uses X10 technology. This is based on a starter kit that my brother gave me for Christmas one year. It came with a serial dongle, and he thought I would have fun programming for it.

The technology uses power line communication. Here's the basic hardware:

This shows the Transceiver Module (the one on the left with the antenna). This receives RF transmission from a physical remote (not pictured) or from a serial dongle (lower center). When it receives the command, it transmits to the other modules through the power lines in the house. On the right is a Lamp Module -- this has a built-in dimmer. There are also Appliance Modules that have on/off (but no dimming), and I have a special module for my wall-unit air conditioner.

The last piece in the picture is the serial adapter cable (from DB-9 to USB). This is so that we can hook up the dongle to a modern computer -- when was the last time you saw a serial port on a computer?

And if you're curious about how you program against the dongle, you enable/disable RTS and DTR in a particular order. I'll go into the details of this in a future article.

Original Intent
The primary reason I was interested in this technology is because I live in an apartment with a wall-unit air conditioner, and I wanted to be able to schedule the air conditioner to go on and off during hot days (when I wasn't home) to keep the place a reasonable temperature.

Here's the main screen of the current application:

This shows the various modules in my apartment (yeah, it's not a huge apartment, but it's the right size for me and the cats). This has buttons to manually turn things on and off. And the sliders are there for the dimmable items.

But the important part is the schedule:

This lets me set up a schedule to turn items on and off throughout the day. I can set the time, the function (on/off), the level (which is the dimming level), and the days of the week that this applies. On top of that, I have labeled Schedule Sets that let me enable/disable groups of commands.

For example, there is a schedule set called "Summer" that I can enable when it's hot. This turns the air conditioner on an off throughout the day -- currently set to alternating between 30 minutes on and 60 minutes off throughout the afternoon. I've found that this is enough to keep things a reasonable temperature. (And I'm sure the cats appreciate it.)

The user interface for the application isn't great, but this was created during the "battleship gray" era, so it's actually pretty impressive taken in that context.

Stuff That I Don't Need
The X10 system has the concept of a "House Code". This is the letter setting that you see on the modules. Each letter can accommodate up to 16 devices (the number on the Lamp Module). This lets you either segment devices if you have a lot of devices, or use a different setting if there is power line interference.

When I coded up the application, I coded for all of the House Codes. I made this configurable in the settings screen:

In reality, I've only ever needed House Code "A". So, I can eliminate the other settings (at least for now -- I can always add them in if I find that I need them in the future).

The other thing is that I coded for 16 devices. I have a total of 8 modules, and since X10 technology has gone out of style, I probably won't be acquiring any more (plus, I don't even use all the ones I have most of the year -- Christmas lights get put onto the system in December).

In addition, I don't really use the manual buttons in the UI. This application runs on the entertainment center computer. This computer is on all the time and plays music through the stereo (in addition to controlling the lights). The monitor for this computer is the television, and the only time I really use the application is to enable/disable the schedule sets. The rest of the time, I use the physical remote for manual operations.

Features I'd Like
There are a couple of features that I'd like to add. The first is being able to interact with the system over a network. The current application has a little bit of this -- it opens up and listens on a TCP port, and an application on the same network can communicate with it using a proprietary message format (nothing makes it outside of the local network).

Something else I'd like to add is temperature-aware operation. So, I'd like to be able to have the air conditioner cycle based on temperature rather than simply based on a schedule. For real-time operation, I would need some additional hardware (a temperature sensor), but I've also thought about hooking it up to a weather service. This way I would not have to manually enable/disable the schedule; I could have it automatically enable if the temperature is forecasted to be over 90F.

Finding the MVP
In order to replace the current system, I need to figure out the minimum set of features that I actually need.

  1. Send commands through the serial dongle
    This is the purpose of the system.
  2. Send commands for 8 devices on House Code "A"
    These are the only devices that are actively used.
  3. Fire on/off/dim events on a schedule
    To maintain the air conditioner functionality (and current lighting schedule).
Not Needed:
  1. Manual control buttons/sliders
  2. Map of the apartment
  3. Scheduling UI
  4. Configuration UI
  5. TCP listener
So, what I'm saying is that in order to produce a minimum viable product that I can put into production, I don't need any of the current UI or networking elements. Now I'm sure that I'll want to add these later, but they aren't required to get started.

Not Much Needed
What we find is that when we analyze the current application and look at how it is *actually* being used, we really don't have very many features that we need to code up. As I've mentioned, I do have other features in mind, so I want to make sure that I don't code myself into a corner along the way. But let's start simply and work our way up from there.

I've already done some tests to confirm that I can communicate with the serial dongle through .NET (that's the environment we'll use for this application). So, it shouldn't take very long to implement these initial features.

The main reason that I'm writing about this is to motivate myself to actually do this project that I've been thinking about for a long time. I don't expect that the specific technologies will be of much interest, but the process of building the application will be interesting.

Next time, we'll take a look at the basic operation of sending codes through the serial dongle. Then we'll look at how we can use this to move toward the minimum viable product.

Happy Coding!

No comments:

Post a Comment