I got the OWI-535 “Robot Arm Edge” 5-Axis robot arm and USB Controller add-on for Christmas:

The robot arm comes as a kit that you assemble yourself, and my 3 year old and I had lots of fun putting it together (it helped to have some tiny fingers around, honestly). It comes with a manual controller that allows you to rotate all 4 joints, plus the gripper. It’s fun to play around with, but let’s be honest, everyone wants to hook it up to their computer.

Unfortunately the software that comes with the USB controller works on Windows 7, but “32-bit only”. That was a little annoying, but hey, I didn’t really want to stick with their canned software anyway. I figured I would see if I could get it to work from C#. I was surprised to find a great site by Dr. Andrew Davison in Thailand who wrote some Java code as part of his site for his book Killer Game Programming in Java (chapter NUI-6 Controlling a Robot Arm, which doesn’t appear in the book). Surprisingly he went as far as to do the inverse kinematic equations so you can give the arm a set of X,Y,Z co-ordinates (in mm) in “world frame” and it will calculate all the join angles to get to that location, and then used timed moves to get the arm into that position.

His Java library uses libusb-win32, and that library has a .NET equivalent called LibUsbDotNet. The API’s don’t appear to be the same, but thankfully I managed to find a thread on SourceForge about controlling the OWI-535 using LibUsbDotNet. So, over the course of a couple of nights, after the kids went to bed, I ported Dr. Davison’s Java code over to C# (quite easy actually) and replaced the libusb-win32 calls with LibUsbDotNet API calls. It worked!

Here is the .NET solution that I wrote called TestOwi535. I used Visual C# 2010 Express Edition to write it, so that’s free. Also, you must download and install LibUsbDotNet first and run the USB InfWizard first to generate a .inf file (you have to do this with the robot arm plugged in and turned on), and then use that .inf file to install LibUsbDotNet as the driver (technically you’re installing libusb-win32 as the driver and LibUsbDotNet is just the C# wrapper).

If you right click on the C# project in the solution explorer, you’ll find 3 options for startup object: MainClass is the original code I found in the SourceForge thread, but it’s just proof of concept code and only moves one joint in one direction for a second. The ArmCommunicator class is an interactive console application that allows you to move all joints (and control the gripper and light) by typing in keyboard commands. Finally the RobotArm class is the full inverse kinematics thing. In the last case, make sure you start with the arm at the zero position (base pointing away from the battery compartment, and all joints in-line straight up in the air, gripper pointing directly up, and gripper open). It will do a move to the table, to the front right of the arm, close the gripper, and then move back to zero and open the gripper.

Unfortunately that’s where you start to see the obvious deficiency of the arm: it has no position feedback. That means even though it tracks its position in the code, the physical position eventually drifts away from the internal position tracking, and the arm eventually doesn’t know where it is (it’s just using timed moves). One of the biggest areas where you could improve it is to change the joint rates so that it knows that the joints move faster when going down than when going up.

Still, it’s a neat little toy for the price. I’m going to start hunting around for a way to add joint position feedback, as that would really improve the performance. I also want to rewrite a new module from the ground up that allows concurrent joint moves (this one only moves one joint at a time). Ideally you want to control this thing in “gripper frame” instead of “world frame”.

Happy hacking!

c# · libusbdotnet · owi-535 · robot-arm

A little while ago I told you about an ongoing project to automate my parents’ G-Scale outdoor model railroad. Today I’m going to add a bit more detail about the solution: specifically, how do you sense the location of the trains?

Layout

The layout is broken into 3 lines: a “Figure 8″ line, a “Point-to-Point” line, and a “Main Line”, which has various track switches, sidings, etc. The interesting thing about the Figure 8 and Point-to-Point lines is that they cross, and one of the goals is to prevent trains from colliding.

Some other goals include:

• The point-to-point should start at one station, move to the other station, stopping out of site for a while. It should stop at each end-station for an adjustable period of time, and return.
• The Point-to-Point and Figure 8 lines have uphill and downhill sections, so the speed needs to be varied in these sections.
• The Figure 8 line has two programmable stops, but the train shouldn’t necessarily stop at both stops every time.
• We want to run multiple trains on the main line. Some will be stopped on a siding while others are running, and then they will switch.
• All tracks need the ability to be manually operated.

The Figure 8 Line from behind "Stan's Speed Shop"

Power

All existing locomotives in the system use “track power” (DC voltage applied across the two rails of the track). The voltage applied to the track is applied to the motors in the locomotives, and this controls the speed.

There are some advantages to this: it allows you to run “stock” (unmodified) engines, and it’s compatible if someone wants to bring over a “guest” engine (either a track powered or battery powered model). It’s also compatible with “DCC” controlled locomotives which, as I understand it, are backwards compatible with track powered systems.

Control?

Whether you use a PLC or a PC for control, being able to control the voltage to a track (to control a motor speed) is pretty much a solved problem, so let’s assume we can do that for now. The main problem is location sensing. In order to tell the locomotives to stop, wait, start, etc., you need to know where they are.

Your first thought, as a controls engineer, is some kind of proximity sensor. Unfortunately there are some significant problems with this:

• Metal-sensing proxes are expensive, and the locomotives are mostly plastic. We’re trying to avoid retrofitting all locomotives here. You might be able to sense the wheels.
• Photo-sensitive (infrared) detectors, either retro-reflective or thru-beam type, are popular on indoor layouts, but they apparently don’t work well outdoors because sunlight floods them with infrared.
• Reed switches are popular, but you need to fit all your engines with magnets, and they are a bit flaky. Magnets and reed switches actually work well if you have the magnet on the track, and the reed switch mounted to the engine, in order to trigger whistles, etc., but even then they’re not 100% reliable, in our experience.
• All proximity detection strategies require you to run two wires to every sensor, which is a lot of extra wiring. Remember, there are lots of little critters running around these layouts, and they tend to gnaw on wires. Fewer wires is better.
• Having sensors out in the layout itself means you’re exposing electrical equipment to an outdoor environment. At least you can take the locomotives in at night, but the sensors have to live out there year-long. I’m a bit concerned by that thought.

Solution: Block Occupancy Detection

The solution we found was a technique called “block occupancy detection.” This is a fairly common method of detection in some layouts. A couple of years ago, I built a simple controller that solved the crossing detection problem between the Figure 8 and Point-to-Point lines using block detection to know where the trains were. It worked great, so we decided to use it for the entire system.

Here’s how it works: you divide up your track layout into “blocks”. Blocks can be any size, but they are typically anywhere from about 4 feet long, up to the length of a train, or a bit more. One rail on the line is “common” and isn’t broken up. The other rail is the one you cut into electrically isolated sections.

So, the wire from the common side of your speed controller goes directly to the common rail, as it did before. However, you have to split the “hot” side of your speed controller into as many circuits as you have blocks. Each block is fed from a separate circuit, which means you have to run a “home run” wire from each block back to your power supply.

Then, the “block occupancy detection” circuit is wired in series with each block circuit (between the speed controller and the block). Here’s what one block detection circuit looks like:

This is an interesting circuit. On the left you can see a bridge rectifier, with the + and – terminals curiously shorted out. This is a hacked use of the device. All we really care about is that we want to create a voltage drop across the device when current is flowing through the wire to that block. One diode creates a voltage drop of 0.6 to 0.7 V, and the way we’ve wired it, whether the speed controller is in forward or reverse, the current always has to take a path through two forward-biased diodes. That means, when current is flowing to the block (i.e. there’s an engine in that block) then we get a voltage drop of 1.2 to 1.4 V across this device (or -1.2 to -1.4 V if it’s in reverse). A standard bridge rectifier is just a handy component to use because it’s readily available in high current ratings for a couple of dollars each.

We’re using that constant voltage to drive the input side of an LTV-824 opto-isolator chip. Notice that it’s a bi-directional opto-isolator, so it works in forward or reverse too. On the output side of the opto-isolator, we can run that directly into a PLC input (the input we’re working with here is sourcing and has a pull-up resistor built-in).

If you’re using a regular straight-DC analog controller, that’s all you need, but in this case we’re using a pulse-width-modulated (PWM) speed controller. That means the PLC input is actually pulsing on and off many times a second, and if you’re at a slow speed (low duty cycle), then the PLC may not pick up the signal during it’s I/O scan. For that reason, I found that sticking a 1 uF capacitor across the output will hold the PLC input voltage low long enough for it to be detected quite reliably. This, of course, depends on your pull-up resistor, so a little bigger capacitor might work better too.

Filtering in the PLC

This worked quite well, but needed a bit of filtering of the signal in the PLC. The input isn’t always on 100% while the locomotive is in the block, so once a block is latched as “occupied”, I use a 1-second timer of not seeing the input on before I decide that the block is clear.

I also have to see an adjacent block occupied before I clear a block. That solves the problem of “remembering” where an engine is when it stops on the track and there’s no longer any current flowing to that block.

Of course, this means you can end up with “ghosts” (occupied blocks that are no longer truly occupied because someone picked up a locomotive and physically moved it). I provided some “ghost-buster” screens where you can go in and manually clear occupied blocks in that case.

Pros and Cons

I like this solution for several reasons: all the electronics are at the control panel, not out in the field (except the wires to each block, and the track itself). Also, the components for one block detector are relatively inexpensive, and we’re working on a bit of a budget here (it is a hobby, after all). I think reliability and simplicity also fall into the Pro column. As long as you can get a locomotive to move on a segment of track (the track needs cleaning from time to time), then the PLC should be able to detect it. You don’t need to deal with dirty photo-detectors or extra sensor wires. The same wire that carries the current to the block carries the signal that the block is occupied.

On the other hand, there are some negatives. This system, as designed, has 21 different blocks, which means 21 home-run wires, buried in the ground, in addition to the commons (plus the track switch wires, but that’s a story for another post). Also on the negative side, you don’t get 100% accurate position sensing. Actually, you get pretty accurate sensing at the edges of the blocks (you’re pretty sure you know where the locomotive is the moment is crosses from one block to the next), but you’re not sure where it is in the middle of the block.

You do have to make other compromises in the track system. There are some accessories (like lighted end-stops) that draw power from the track. This current draw makes that particular block show up as occupied all the time. You either have to modify the accessory to use battery power, or you have to run extra wires to that accessory.

You also have to take the length of train into account. You know which blocks are occupied by current-drawing locomotives and cars (like lighted observation cars and caboose’s), but not every car draws power. Your design and control system needs to take into account whether or not your train will occupy more than one block at once, and whether the end of the train will be detected. This is most important when trying to run multiple trains on one track, where you want the back train to avoid running into the end of the first train.

Next

I hope that’s been educational. I’m still not done programming the PLC, and I’m waiting for a component to arrive for the throttle controller right now. I’ll post more information over the next few weeks.

block-occupancy-detector · g-scale · garden-railroad

Several years ago my parents decided they were going to build a Garden Railroad in their back yard. It’s been an ongoing hobby project since then, and it’s been growing substantially every year:

West Station on the Point to Point Line

This is “G Scale” (around 1:22.5 scale) outdoor model railroading. It’s really a combination of three things: model railroading, building miniatures, and gardening. This recent weekend was the local club’s open-house day, and I was invited along to see many of the layouts. Each layout kind of emphasizes its own focus: some are more focused on gardening, others on the miniatures, etc.

Anyone who does anything remotely related to computers knows that every relative you have thinks you know everything there is to know about computers, and you’re destined to spend the rest of your family holidays removing spyware and running ccleaner on their computers, not to mention reassuring them that it’s OK to reboot the computer to see if the problem goes away.

Being in industrial automation, though, you never get people asking you to automate something; it’s just a little bit too abstract for most people to grasp. However, when your parents get themselves a model train set, they may not know exactly what you do for a living, but they certainly know that if you can program conveyors, robots, and cranes, you should be able to figure out how to make their trains do what they want them to do. Automatically.

Of course, as a control systems guy, you can’t look at your parents’ 24V model train set and not think about how you’d hook up a PLC to it. Especially when they offer to finance the project.

I’m happy to report that we’re progressing well. The goal is to have it running in fully automatic mode before the end of the month. I’ll post some pictures, hopefully some videos, and some technical information about how it was accomplished. Stay tuned.

g-scale · garden-railroad

I’ve been playing with my new Smarthome 2413U PowerLinc Modem plus some Smarthome 2456S3 ApplianceLinc modules and two old X10 modules I had sitting around.

Insteon is a vast improvement over the X10 technology for home automation. X10 always had problems with messages getting “lost”, and it was really slow, sometimes taking up to a second for the light to actually turn on. Insteon really seems to live up to its name; the signals seem to get there immediately (to a human, anyway). Insteon also offers “dual-band” technology, meaning the signals are sent both over the electrical wiring of the house, and over a wireless network. On top of this, Insteon implements “mesh networking”, acknowledgements, and retries. The mesh networking means that even if two devices can’t directly communicate, if an intermediate device can see both, it will relay the signal.

Now, where Insteon seems to have improved leaps and bounds on the hardware, the software support is abysmal. That’s not because there’s anything wrong with the API, but because they’ve put the Software Development Kit (SDK) behind a hefty license fee, not to mention a rather evil license agreement. Basically it would preclude you from using any of their examples or source code in an open source project. Plus, they only offer support if you’ve purchased their SDK.

So, I’ve decided to offer free technical support to anyone using a 2413U for non-commercial purposes. If you want help with this thing, by all means, email me, post comments at the end of this post, whatever. I’ll be glad to help you.

Let’s start by linking to all the useful information about Insteon that they haven’t completely wiped off the internet (yet):

• Insteon Modem Developer’s Guide – this is for the 2412S, which is the chip at the heart of the 2413U, so it’s the bible for this device
• Insteon Command Tables – vital info about the actual inter-device commands that get passed back and forth
• Insteon Developers’ Guide – note it’s hosted at a university, not the manufacturer
• Insteon Device Categories and Product Keys – a couple years out of date, but full of great information
• Another great Insteon Device List

Now how did I find all this information? Google. SmartHome (the Insteon people) don’t seem to provide links to any of this information from their home or (non-walled) support pages, but they either let Google crawl them, or other companies or organizations have posted them on their sites (I first found the modem developer’s guide on Aartech’s site, for instance). Once you get one document, they tend to make references to the titles of other documents, so you could start to Google for the other ones by title. Basically, it was a pain, but that’s how it was done.

Now, whether you buy the 2413S (serial) or 2413U (USB), they’re both using the 2412S internally, which is an RS232 device. The 2413U just includes an FTDI USB-to-Serial converter, and you can get the drivers for this for free (you want the VCP driver). It just ends up making the 2413U look like another COM port on your PC (in my case, COM4).

So, assuming you know how to open a serial port from .NET, and you got done reading all that documentation, you’d realize that if you wanted to turn on a light (say you had a switched lamp module at Insteon address “AA.BB.CC”), you’d want to send it this sequence of bytes (where 0x means hex):

• 0×02 – start of message to PLM
• 0×62 – send Insteon message over the network
• 0xAA – high byte of Insteon ID
• 0xBB – middle byte
• 0xCC – low byte of Insteon ID
• 0x0F – Flags (meaning: direct message, max hops)
• 0×12 – Command byte 1 – means “turn on lighting device”
• 0xFF – Command byte 2 – intensity level – full on

… after which the 2413U should respond with:

0×02, 0×62, 0xAA, 0xBB, 0xCC, 0x0F, 0×12, 0xFF, 0×06

… which is essentially just echoing back what it received, and adding a 0×06, which means “acknowledge”.

At that point, the 2413U has started transmitting the message over the Insteon network, so now you have to wait for the device itself to reply (if it does… someone might have unplugged it, after all). If you do get a response, it will look like this:

• 0×02 – start of message from 2413U
• 0×50 – means received Insteon message
• 0xAA – high byte of peer Insteon ID
• 0xBB – middle byte
• 0xCC – low byte of peer Insteon ID
• 0x?? – high byte of your 2413U Insteon ID
• 0x?? – middle byte of your 2413U Insteon ID
• 0x?? – low byte of your 2413U Insteon ID
• 0×20 – Flags – means Direct Message Acknowledgement
• 0×12 – Command 1 echo’d back
• 0xFF – Command 2 echo’d back

If you get all that back, you have one successful transaction. Your light show now be on! Whew, that’s a lot of overhead though, and that’s just the code to turn on a light! There are dozens of other commands you can send and receive. I didn’t want to be bit-twiddling for hours on end, so I created a little helper library called FluentDwelling so now you can write code like this:

[csharp]
var plm = new Plm("COM4"); // manages the 2413U
DeviceBase device;
if(plm.TryConnectToDevice("AA.BB.CC", out device))
{
// The library will return an instance of a
// SwitchedLightingControl because it connects
// to it and asks it what it is
var light = device as SwitchedLightingControl;
light.TurnOn();
}
[/csharp]

I think that’s a little simpler. FluentDwelling is free to download, open-sourced under the GPLv3, and includes a full unit test suite.

It also supports the older X10 protocol, in case you have some of those lying around:

[csharp]
plm.Network.X10
.House("A")
.Unit(2)
.Command(X10Command.On);
[/csharp]

There are quite a few Insteon-compatible devices out there. In addition to lighting controls, there is a Sprinkler Controller, Discrete I/O Modules, a Rain Sensor, and even a Pool and Spa Controller. That’s just getting started!

.net · fluentdwelling · insteon · x10

I cruised through January in a kind of sleep deprived stupor (we just had our second child this December). Things are finally swinging back to normal, and I’m getting my geek back on.

I’ve been looking for a less expensive way to do discrete (or analog) I/O over WiFi for homebrew projects. I want something that can be compatible with SoapBox Snap (the open source ladder logic editor/runtime I’ve been working on), so I’ll need to be able to write a communication driver in C#. I’ve been rather frustrated by the options:

• National Control Devices WiFi Relay Boards – but they start at $250 and go up from there.
• Insteon – perfect for home automation and more reliable than X10, but their software license agreement for their development kit is extremely unfriendly to open source.
• Belkin and other manufacturers have created some wireless USB hubs, but I can’t seem to find anyone who has them in stock, most have been discontinued, and the cost is still prohibitive ($100+) especially when you figure you still have to buy some Phidgets boards on top of that.

Then I finally decided this was my best choice: the YellowJacket WiFi Arduino. Arduino is a family of open-source hardware designs for microcontroller boards. You can buy add-on cards for them (called shields), but you can also purchase custom designs with specific features, like this one with built-in 802.11b WiFi.

The price is right ($55), it’s very open source friendly, and since I get to program the microcontroller end, I should have no problem writing a driver for it in C#. Unfortunately it’s on back order, but I expect to get it in a couple of weeks. I’ll post more after I’ve played with it a bit.

I must admit there’s one other honourable mention, though it was a bit too much of a hack for me. There are these cheap routers you can get called La Fonera (made by FON). It turns out that they have 3 or 4 unused general purpose TTL level I/O on the circuit board, and if you install a copy of the open source DD-WRT firmware on it, it lets you control those I/O using the command line prompt if you telnet or SSH into the router. Perfect, and you can pick these things up really cheap on eBay. Unfortunately I wanted something just a little more off-the-shelf than that. (I do have a copy of DD-WRT running on my old Linksys router and I’m using it as a wireless bridge to extend the range of the wireless in my house, so I did give it some serious consideration.)

i/o · snap · wireless

At long last, I’ve finally released a first version of SoapBox Snap, a free and open source ladder logic editor and runtime for your PC:

After all this time, it’s finally ready? Yes. I’m admittedly a perfectionist, and yet I admit this software isn’t perfect. Software never is, really. But in the world of open source software, the question is, “is it useful?” I believe SoapBox Snap is already useful, even in this early form. You can write logic that controls your outputs, which is the entire point of this software. More features will come over time.

One really cool feature, that I’m glad made it into the first release, is a driver for Twitter. You can easily configure SoapBox Snap to watch your own Twitter feed for status updates. The driver exposes a “Last Status” signal that has the text of your last status and a signal that pulses any time your status changes. You can compare the status text to certain key phrases, like “turn on light”, and use it to drive outputs. I think it would be neat to tie it to your garage door opener, and if you forget your keys you can just pull out your phone and tweet some key phrase like, “darn it I forgot my keys!” and the garage door could open!

Please check it out, download it, and play with it. If you have any neat ideas of things you could do, please drop me a line. Have fun!

snap

I was a little surprised when I read about Industrial PC Technology in High End Kitchens in Beckhoff’s PC Control magazine. The entire kitchen is integrated together using industrial PC technology:

SieMatic’s self-developed software for the selection menu and the control functions forms the heart of the SieMatic Grid. The basis is a
modularly structured Beckhoff Embedded PC equipped with a Windows XP Embedded operating system as well as a .Net framework. Via RS232, the Beckhoff PC controls the T+A components as well as managing all functions that they do not take care of. Above all, these naturally include all the typical PC tasks, such as Internet access, e-mail access and data services (such as weather forecast or newsfeeds), but also entertainment programs, such as slide shows. All Miele@home appliances are also integrated via the Ethernet interface of the Embedded system.

The most important functions, however, run invisibly in the background, because the Beckhoff PC works almost like a mediator between different worlds: for example, a television broadcast can be interrupted for messages from the Miele system – that the dishwasher program has finished, for instance – if the user so desires. The integration of other systems – for example, the picture from an IP monitoring camera – is easy to accomplish using Beckhoff hardware. It was clear from the outset to SieMatic project manager Thorsten Pawelczyk that the SieMatic Grid would be a constantly growing and changing system: “The fact that the Beckhoff automation system hardly sets any limits regarding the integration of other systems comes just at the right time.”

I question the logic of putting industrial technology in a consumer kitchen, but I must admit I’m impressed and envious. I think the real question is, does it have the “hackability” we’ve come to expect from industrial control systems? Can I connect to it with TwinCAT PLC and modify the functions, extend it, or tie in new systems? Somehow I doubt it. The article mentions it runs a .NET application, so in this case they’re probably only using the hardware, not the Beckhoff control software.

beckhoff

What makes the masses adopt a new technology? I don’t think it’s because it saves them time.

When I was at StackOverflow Dev Days last year, Joel Spolsky gave a keynote that touched on the topics of why people use technology. Specifically he talked about why the masses use it. I think as geeks we sometimes can’t see how “normal people” see technology. Back in the 90′s I couldn’t understand why anyone would buy a Mac over a PC. As a 30-something father with different priorities, I’m starting to “get it”.

Joel referred to a book by Richard Dawkins called The Selfish Gene. It says that genes aren’t the method by which we reproduce, but rather: we are the method by which genes reproduce. They created us because it’s a workable method to make more copies of themselves.

Joel asks us to imagine a 20 year old college student sitting in her dorm room, trying to install Firefox. Why is she installing Firefox? So that she can use Facebook. Why does she want to use Facebook? So she can communicate with her friends and know where they’re going to be, possibly when they’ll be going to the bar. And why does she want to go to the bar? Most likely there’s a strong primal urge to “hook up” with someone.

People buy iPhones for the sexiness. Business people want a BlackBerry for business, but why are they in business? Why do business people want to be successful?

It doesn’t really matter how you try to spin this. Once you get outside the early adopters of technology who are doing it because they’re “not normal”, the “normal” people use technology for much more fundamental reasons. The most powerful force that drives everything, including technology, is replication, and thus reproduction. Do you want proof?

Did you notice how replication was its own reward? Makes sense. Things that just replicate themselves will make more things that replicate themselves. Things that don’t replicate themselves will get eaten by those that do.

Now ask yourself, why hasn’t home automation taken off? Lights? Vacuums? They’re gadgets for a geeky minority. They really don’t help with the fundamental drive of the home, which is family. How does home automation help you raise better kids? How does it help you make them smarter, better, more successful? Does this home automation system appeal to the vast majority of “normal” people? I don’t think so. (I’ll give it some geek cred, though.)

If we answered those questions, we’d know how to make home automation for the masses.

deep-thoughts

Here’s one for you home automation and gadget enthusiasts. Can’t afford a penthouse with a view overlooking your favorite scenery? Well, you can now bring the scenery to you, courtesy of two flat screen TVs on edge, and a wiimote hack. They even have instructions on how to build one yourself!

wiimote · winscape

I have to say that this newspaper article from 1992 predicted our future right on the money. I’m an “automation enthusiast”, so I’m all about the time saving device. Just for fun I entered “time saving device” into Google and clicked “I’m Feeling Lucky”. I was directed to this question:

If every year time saving devices are invented (i.e. computers, cell phones, email, etc…) then why do we still need a 40 hour work week?

As I’ve said before, this is another manifestation of the Jevons Paradox. If I wanted to hire someone to paint a building and I had to choose between someone with a bucket of paint and a paintbrush, or a guy with a power sprayer, the latter is undoubtedly more expensive per hour, but cheaper per square foot of wall. He’ll also have the job done faster. That means the demand for the guy with the sprayer is higher. His time saving device gives him more work and less time.

Saving Time is the Myth of Home Automation

In Industrial Automation, we never really talk about saving time. We talk about saving labor and saving money. We talk about increased productivity, efficiency, throughput and uptime. Time is a constant.

Yet at home we talk about time like it’s a variable. As if you could have more of it. What an odd concept when you think about it…

I’ve recently spent some time trying to think of a good time saving home automation device to create, and I’m convinced it’s a pointless activity. Would an automatic pet feeder save me time? Possibly, but you still have to refill it, the parts are likely to wear out, and it has to be cleaned regularly. It takes one of us less than 30 seconds to feed the dog every day. That’s about 3 hours per year. But if you spent 10 minutes a month cleaning it, that’s 2 hours a year right there, and how long are you going to spend fiddling with it when it finally breaks down? Even if there was no extra time, would you spend $100 to save 3 hours? It’s marginal, but doubtful.

Now where that pet feeder really shines is if you have a dog with a special need. It can feed your animal up to 8 times a day, so if your dog was diabetic, then you can start to see that it solves a difficult problem really effectively.

Would a robot vacuum save me time? I think you’ll find that it fails in the same way that the pet feeder fails: you have to clean out the vacuum bucket every time it cycles, and you have to take it apart to clean the brushes regularly. The batteries need replacing, and most reviews I’ve seen indicate that you still need to vacuum once every couple of weeks. It doesn’t save you time. It gives you the ability to vacuum more often.

Look at the three successful categories of home automation: HVAC, lighting, and audio/video. None of those are about saving you time. They’re all about improving the (perceived) quality of life. A new robot that folded your laundry for you wouldn’t be as successful as a closet that color co-ordinates your outfits for you. Everyone can fold laundry but not everyone can pick an outfit. There’s a market for the latter.

deep-thoughts · time