The Universal Remote

Hello, world. I know it's been a long time. Partly, I've been doing non-MSM related things, and partly I got sucked in to a huge project.

My thinking was this: I'm getting impatient to start building things. My landlord's probably going to be annoyed if I start drilling holes in the bottom of my kitchen cupboards, so I should hold off on the hardware for now, but there's nothing stopping me from getting some of the software in place. Remember that universal remote that controls everything? I could get to work on that, right? There's no hardware for it to actually control, of course, but I could get the software infrastructure set up.

All I needed to do was learn to write Android apps, figure out how to get data from the app to my computer (and vice versa), parse the data, and run a program either now or later, depending on the command. How hard could it be?

Let's start with that "learn to write Android apps" part. This was non-trivial. I've never written apps before and my Java is rusty. Honestly, I've never been a huge fan of Java. The "absolutely everything is a class" paradigm is a little counter-intuitive to me. My first language was C and I like the flexibility of C++. Things that make sense to put in classes can be classes. Things that don't make sense to be classes don't have to be. The Java static class does help a bit, but, really, if you're never going to instantiate the class, why make it a class in the first place?

But, at the same time, everyone has different philosophies about how to organize code and intensely class-based is not a bad option for a user interface, so I can live with it.

Unfortunately, remembering Java did not mean I knew how to write Android apps. Figuring out all the APIs was almost like learning an entirely new programming language in itself. However, the Internet is actually a wonderful teacher and once I resolved to actually work through the tutorials instead of taking shortcuts to "just the things I need," I was able to pick it up all right.

Having done that, I was equipped to write the front end. User interfaces have never been my strong suit and I'm downright lousy at graphic design, so it's mostly just lists of buttons that open up more lists of buttons, but it gets the job done.

The interesting stuff is the back end. The universal remote needs to send commands to the computer, for example "Cook oatmeal at 9:00am" or "Start the laundry." I used the sockets functions in Java and C to get the computer and phone talking, and, I'll be honest, I copied most of that code from the Internet. (It's a good thing Google knows everything.) I learned a lot about networking in the mean time, but, ultimately, I didn't really need to be doing anything too fancy here.

Where I did want to get slightly fancy was with the data I was sending. As I was thinking about the right way to organize this, it occurred to me that I was basically developing a simple machine language and that the entire Mad Scientist Mansion could be considered the world's most unconventional processor.

So, with that organization in mind, I came up with the following command packet:

hour minute tag repeat command task params

where
hour is the hour to start (-1 for immediately)
minute is the minute to start (-1 for immediately)
repeat is how often to repeat the process (never, daily, or weekly)
tag associates this process with a specific program so that programs can be turned off or on together.
command is the basic command. I should probably have come up with a better name for this. It refers to essentially which part of the house this process deals with. For example, kitchen, laundry room, or lights.
task is the task to do in the given command region. For example, get status or cook.
params are any other parameters the task requires. For example, the recipe to cook.

I'm fairly happy with this structure. It's sufficiently general to meet all my foreseeable needs and so far it's been tolerably easy for the receiving C code to parse. (Obviously, I wrote the receiver in C.) Except. Except that the sender and the receiver must agree precisely on where everything is in the packet and what all the constants mean.

And this is where things almost got a little wacky. See, the sender is in Java and the receiver is in C, so it's not like they can share code in any sort of straightforward way. Java doesn't even have a notion of a preprocessor. For a moment, I was tempted to write a bash script that would take my C header files and use that data to go edit the constants in my Java files so that everything would match up automatically.

I didn't do it. I concluded that the probability of errors from the script was at least as great as the probability of errors doing it by hand and that writing the script would take longer than doing it by hand since these things are not likely to change a whole lot once they're initially defined.

The problem remained that I had to figure out what to do about the constants in Java. See, not only does Java not have a preprocessor, Java hates the idea of sharing constants across classes. All the Java forums I went to trying to figure out what a Java equivalent of #define was said that if you're using constants in more than one class, you're violating the whole point of modularized class-based design.

To be fair, after thinking about it, I concluded that argument did have some merit. On the other hand, if I need to define constant commands kitchen=0, laundry=1, lights=2, etc, and to be sure that the same two numbers were not used twice, does it really make sense to define the kitchen constant in the kitchen class, the laundry constant in the laundry class, the lights constant in the lights class, and so forth, so that I have to look through every single class to be sure there are no collisions? So I went ahead and violated good style and made a constants class. What can I say? I'm trying to turn my future house into a processor. I'm going to have to do some unconventional things.

So the hour, minute, tag, repeat, and command constants all went into a common class. I did somewhat localize the task and parameters constants, though they are still in separate constants classes accessible by any of the code. The problem is, in my attempt to create a good user interface, there's a bit of redundancy. For example, there's a kitchen screen where you can do things related to the kitchen (including read its status), and there's also a status screen where you can get the status of everything in the house (including the kitchen). Since different screens are different classes in the Android organization scheme, these two need to share constants. Maybe I could have created some sort of intermediate class that both the kitchen screen and the status screen use, but...at some point good enough is good enough.

That was the sender side. Now for the receiver, which had its own issues. The main difficulty is that I want to be able to run things at preset times. It is entirely reasonable that I will want to say something like, "Make oatmeal at 8:30 every morning." Linux has a nice way to do this in the form on cron, which can run a program at a specified time. I did not know about cron when I started this adventure, so there was a bit of a learning curve to figure that out. Also, cron is really meant to be used from the command line. In fact, you use command line tools to get you to a file that you edit. The problem is that I want to automatically create a cron entry based on the data from the command packet the computer receives from the phone.

Once again, I think I'm doing something a little unconventional here. The Internet is full of ideas about how to run a program from cron. That is, after all, the purpose of cron. It is considerably less helpful when trying to figure out how to run cron from a program. I ended up splitting my receiver code into two programs: One to receive a packet and schedule it and one to parse and execute the instruction. The "receive a packet" program uses system() and some command line acrobatics to communicate with cron, and cron then runs the "parse and execute" program.

In retrospect, the "receive a packet" program could probably have been a bash script, but I was initially thinking the whole thing would be one program and it was easier to just separate the code than to knock the rust of my bash scripting.

The parser/executor, fortunately, has not, so far, been too bad. Just lots of switch statements. It will get a lot more interesting once there's hardware.

So, to recap:

I have a user interface on my phone which sends network packets to my computer which are received by a program that interfaces with the operating system via cron to schedule a call to another program that can parse the packet and then print, "This function is not yet implemented." Nothing to it!

The big TODO at this point is getting status data back from the computer to the phone, but I am exhausted and will deal with that later.

Finally, about the code. My original intention was to post my code as I went, both to make it available to the universe and so I would have a back up copy, but it turns out there are an enormous number of files involved, and I'm too lazy. So, until it's a final draft (ha ha, like this is ever going to be a final draft) I'm not going to worry about it.

Blinky LEDs

I got an Arduino board for Christmas and I've finally had a chance to play with it some, so this is my new Arduino saying "Hello, World!"

The obvious question here is: Why, why, why did you use orange wire for ground, Mad Scientist?? And the answer is...well, because I'm lazy and it's what I had on hand. I promise I won't always be so sloppy.

The other obvious question is: Where to from here? I see two directions I need to go. I need to get the Arduino talking to my phone, possibly with my computer as a middle-man. (I did decide to use a phone as the universal remote. Still learning how to program it, but I think it should be doable.) I also need to get the hardware setup to have the Arduino turn a motor that will open the blinds.

I don't have a motor just now (the one from the mixer can't be removed from the mixer, so it doesn't count), and it's a little late at night for a Radio Shack run, so I think I'll work on getting the Arduino and the phone talking. I'll keep you posted.

Mixer Guts

Sorry it's been a while since I've posted anything. Unfortunately, we don't live in the alternate universe where replicators exist and we can all blog full-time. Also, I've been taking apart a mixer.

See, I've been thinking about the circuitry to control the blinds, and it occurred to me that there's no good reason I can't have that in my current residence.

My window is one that has a chain that you pull one direction or the other to make it go up or down. Whatever design I ultimately come up with will have to involve a motor, and that motor will have to lift something that weighs about eight pounds.

And this is where I got very seriously side-tracked. The thing is, I have an old mixer lying around (long story), and mixers have motors in them, and I hate to let anything go to waste if I can help it. Therefore, I concluded it was necessary to take the mixer apart and see if there was anything useful inside.

The problem is that the people who make mixers apparently hate mad scientists, because it was ridiculously difficult to get that thing open. The screws that held it together were hidden under expanding plastic pins, which at first I didn't even notice were not part of the main casing, and which were next to impossible to remove. However, after trying a huge variety of tools, up to but not quite including a blowtorch (not saying I wasn't tempted, but something dangerously close to common sense won out at the last minute), I came off conqueror and opened the casing.

Here's what was inside, because if you are reading this blog, you are probably the kind of person who is wondering about that right now. (Or, more likely, you are a member of my immediate family.)

And here's a video of what it looks like running, because common sense doesn't always win:

Unfortunately it doesn't look nearly as impressive as it smelled.

I think it would not be impossible to remove the motor and use it--the wiring doesn't look too bad (famous last words), but, at the same time, I also don't know if I actually want anything that goes that fast. (I may or may not have just been looking for an excuse to take my mixer apart.) Another option is to put the mixer back together (minus those #%!@$* plastic pins!) and use the motor from within the mixer.

If I did use it, I would probably need to rig up some kind of pulley system, and the whole idea has this wonderfully Rube-Goldberg feel to it. On the other hand, I might be better off just starting with the kind of motor I want in the first place.

Bottom line: I'm not sure I've really made any progress here, but it's cool to see what's inside a mixer!

The Universal Remote

As I have mentioned before, I would like to control the MSM remotely through a phone or tablet. I had been envisioning an app to do this, but the more I look into it, the more I'm thinking "app" is basically a fancy word for "program" and my life will be a lot easier if I just use a tablet as a computer and not worry about all this official "app" business. Here are the pros and cons as I see them:

Pros: I am more comfortable programming in Linux than in any other operating system, and, all other things being equal, would prefer to do that. A tablet would let me. I wouldn't necessarily have to learn any new tools or environments, and I could program in C, which is also my preference. (Initial explorations into this say Android apps are easiest programmed in Java, which I learned once, but is not my native language. Not sure about other operating systems.)

Cons: It would mean another device to carry around, since, as far as I know, you can't get phone calls on a tablet running Linux. (And, to be honest, I don't know if I'd even want to.) I also wouldn't end up learning any new tools or environments.

I need to keep exploring this, but I think dropping the app idea would make things easier. I think I'm going to start writing some preliminary programs on my Linux box and see how it goes.

Wiring

As I was working on the plans for the laundry room and found myself descending into the Arduino/Raspberry Pi/Bluetooth/Internet wormhole, I realized I needed to step back and think some about the general architecture of the house. And when I say architecture, I mean something much closer to "computer architecture" than "building architecture."

First, the main brains of the place will be in the study. There, I will have a computer (I'm thinking a desktop running Linux) that will be in charge of everything and will run the program that sends signals to all the other controllers throughout the house to tell them what they need to do. This program will communicate with the Universal Remote probably over the internet (though I haven't completely ruled out Bluetooth) to get its instructions, and it will probably be wired to an microcontroller with lots of GPIO, and that microcontroller is what will tell the other controllers what to do.

Then, I will need to find an electrician who's as mad as I am who will run wires through my house from the Brain to the peripherals. (Obviously, this will be done when the other wiring is done while the house is still under construction.) I am thinking this should only need to be one wire per peripheral, since everything in the house should be on the same ground, and I can use serial communication. I did a preliminary search of wire resistances, and I don't think I'll run into any problems there. I don't remember my transmission lines class very well (except that it's hard) but I'm pretty sure it only applies to AC, and all of this will be DC, so I'm happy with using wired communications.

Next, I have to decide what I want in each room. I think I will want the following four things in every room (with the possible exceptions of bathrooms and closets):

1. A motion sensor. I want to know if someone's in the room.

2. Automatic light switches. I want a manual override here, but I also want them to be able to be controlled by the computer, which will make decisions based on what setting it's in--either lights always on/off or responding the the motion sensor.

3. Speakers. Ideally, I'd like speakers in every room so that Pandora can just follow me around. This may be kind of tricky, and I might just decide to play Pandora on the Universal Remote (remember, it's a tablet or a phone) instead. I like music, but I'm not so much of an audiophile to really appreciate high quality versus okay quality speakers. But it would be cool if the must just automatically turned off when I left a room and turned on when I entered another.

4. Blinds. The Brain really should be able to automatically open the blinds in the morning and close them at night.

In addition to these basic things, the laundry room microcontroller and the kitchen microcontroller need to be able to communicate with the Brain. Also, it would be nice if the security system (presumably I will have one...I haven't thought about that yet...) could, as well.

Bottom line: The only thing that will need wireless communication is the Brain. Everything else will be wired. That probably makes life a lot easier...once I find an electrician...

Floor Plans

The Mad Scientist Mansion, as I currently envision it, has two stories. Honestly, I'm a little surprised by this. When I set out to design it, I had ideas for all different sorts of rooms and I figured it was going to be a sprawling, ridiculous mess, but it turns out that it all fits into a semi-reasonable floor plan rather nicely. I mean, what's inside the house is somewhat less reasonable, but it was only after drawing these floor plans that I began to think this is actually an achievable dream.

Therefore, without further ado, let me present to you floor one:

You enter the house through a set of double doors that lead to a somewhat significant hallway. Obviously, the hallway will be decorated, but I'm not sure how. Right now, I'm leaning towards suits of armor, but that may change.

Coming out of the hallway, you enter the great room. This will be furnished with couches and chairs and will contain the largest fireplace in the house. (There are three, because I'm a pyro.) The great room will also have a vaulted ceiling, and, if I end up owning one, the piano. Whether or not I have a piano is an open question right now. I learned to play when I was growing up, but my skills have since gotten rusty. In theory, I like the idea of being able to play, but I don't know how much I'll actually practice, in practice. In any event, the great room is designed to be a very comfortable space where lots of people can sit and talk.

The great room opens onto the deck, and from there, the backyard. My ideas about the backyard are vague at this point. Currently, I'm going through a hedge maze, fountains, and torches phase, but this changes pretty regularly. I think the only thing we can all be reasonably sure of is some sort of fire pit. I mean, if there are three fireplaces inside the house, there's really got to be at least one in the backyard.

Anyway, the area you see cut out from the top right corner of the great room is the kitchen counters. The kitchen is a sufficiently substantial part of the house that it has its own blog, so I'll let you read about it there. Suffice to say here that it will be fully automated and do all the cooking for me.

The kitchen opens into a dining room, which will be pretty much what you'd expect from a dining room, and from the dining room, you can enter the library, which will also have its own blog soon. I will say here only that I am very happy with this library. It's in a tower, it has its own fireplace, and you get from one floor to the other via a spiral staircase leading to a trap door.

On the other side of the great room, we have a bathroom and a closet--nothing special there--as well as the study and the laundry room. The study is where I'll do all my technical work. It will house a fairly powerful computer that will control all the automation in the mansion. It also opens to the three car garage. Two of those three spots will probably be for cars, but the third will be a small machine shop, and this is why it must be connected to the study. I'll do the design work in the study and then go build everything in the garage.

The laundry room will have its own blog. It also will be fully automated.

If you go up the stairs, you find floor two (hopefully, unless there's been some terrible warping of the space-time continuum on the stairs. I'm working on a contingency plan for that.) :

Nothing terribly interesting about the closet or the guest bedrooms, except that the only external entrance to the second story of the library is from within guest room number two. I don't love this configuration, but it was the best way to make everything fit. It will probably change when I take these plans to an actual architect, but that's what it is for now.

 Like I said, the library will soon have its own blog, so I'm not going to talk about that here.

The theater room is basically what it sounds like. There will be a nice big TV and lots of very comfortable recliners. The theater room is the only room in the house that will have a TV. I'm one of those people who gets easily distracted by screens, so I want to the TV to be off and out of sight except when I'm deliberately using it, and when I am deliberately using it, I want it to be the only thing that's going on. The TV room will also have its own blog at some point.

Again, nothing terribly interesting about the bathroom, which takes us, finally, to the master bedroom. A couple of important points here: First, the alcove. I really like the idea of having a little area with a fireplace (here, the fireplace is right above the great room fireplace, but not oriented at the same angle. I'm hoping they can share a chimney), a desk, and a recliner, where I can spend some time unwinding before bed. I have mixed feelings about entering the bedroom through the alcove, but, again, that's how things fit, so for now it's the plan.

Also, the master bedroom is directly above the laundry room. This is very important for the automation of the laundry room: There's a laundry shoot I can drop my clothes down when I'm getting ready for bed and the laundry room will just take care of it, but, again, that's its own blog (or will be soon).

Finally, the master bathroom must have a really nice shower. I want the water pressure to be pretty high, and I want the water to get pretty hot. This is how I wake up in the morning. And then, as I'm enjoying my nice warm shower, I will smell the bacon the kitchen is cooking for me, and I will know it's going to be a very good day.

Hello, World!

If you're reading this, the odds are about even that you're a programmer, and so you get the reference in the title of this post. If you aren't a programmer, it probably seems pretty self-explanatory to make the title of the first post of a blog "Hello, World!"

Nevertheless, the explanation of the "Hello, World!" post in blogs by programmers meant to be accessible to non-programmers is, at this point, almost as obligatory as the "Hello, World!" post itself, so here goes:

Whenever programmers get new tools up and running, they write a basic program that just prints the phrase, "Hello, World!" to the screen to make sure everything is set up right. Personally, I don't usually write the "Hello, World!" program. Instead, I write the "Greetings, master." program. The principle is the same, but I think it gets my relationship with the computer off on the right foot. That didn't seem to be quite applicable here, so I say again:

Hello, World.

Now that we've got that out of the way, let me explain what this blog is all about. I have a dream of a dream house. I call this dream house the Mad Scientist Mansion, for reasons that will become very clear as we go along. This dream house will be the work of a lifetime, and I thought it would be useful to keep a log of the progress, and a blog seemed as good a way of doing that as any.

I haven't started building the house yet--I'm still several years away from doing that, but it's a big project that might benefit from a few years' planning, so I'm starting the blog now. Also, as you will see, not everything in the blog is directly related to the house, per se.

The organization of the blog should be pretty obvious. I'm going to use this tab to talk about the whole house and whatever other things seem generally relevant. The tabs at the top (well, there will be tabs at the top when I get around to adding them) will discuss what is being done to and in each room.

All right, I think that's all for now, because, unfortunately, the Mad Scientist Mansion has not yet been built, which means the automatic laundry system is not yet functional, which means I've got to go take care of that or else I won't have any clean socks tomorrow, which would be a shame. I'll upload some rough sketches of floor plans next time. Until then, Goodbye, World!