CURRENT ISSUE
Contests
Priority IntErrupt
|
|
Issue #216 July 2008
A Real Rube Goldberg Solution
by Steve Ciarcia
Since we have a large foreign readership, let me start by explaining the title of this editorial. Rube Goldberg was an engineer in the early 1900s who became a Pulitzer Prize-winning cartoonist. He is best known for drawing cartoons depicting “Rube Goldberg Machines.” A “Rube Goldberg” is an extremely complicated apparatus or series of connected devices with the sole purpose of performing a single simple task in an extremely convoluted way. Today, whenever engineers are involved with an overly complicated piece of hardware or tortuous software, they will call it a Rube Goldberg. The bad news, of course, is when you actually need to make one of your own.
After installing the photovoltaic (PV) system last fall (www.circuitcellar.com/archives/viewable/209-Ciarcia/index.html), I decided to add a lot more energy-related sensors and controls this spring ($4.50/gal. heating oil is a lot of incentive). So, I ordered multichannel temperature sensors from two manufacturers and a PV power data logger from a third. My experience with these products is a lot like my opinion of Vista—nobody did their homework before selling it.
The issue isn’t whether these sensors and loggers work—they do. They are a marvel of integration and performance. The problem is that manufacturers need to think beyond making just their single device work on your network. It’s a big electronic world out there and they need to think about more than just the communication needs of their product.
Most webcams and IP-addressable sensors are shipped with default HTTP addresses like 192.168.1.2 and TCP port 80. If you want to access the sensor from outside, you simply address it using your outside IP address like 204.xx.xx.18 and up pops the sensor data. If you have nothing else on your system, then this default address is fine and you go merrily about your life. However, a second sensor of the same type can’t use the same default address for obvious reasons. As a user, the first thing you do is plug the second device into the network by itself and change the address to something like 192.168.1.3. For the most part, this will work fine on the LAN; but if you want to get at the sensor from outside, then you also have to use port forwarding on your router. For example, if we put the second sensor at port 8080, then the LAN address would be 192.168.1.3:8080 and the outside address would be something like 204.xx.xx.18:8080. Simple, right? Sure, until some moron designer thinks he’s making his product super easy to install by fixing the TCP address at port 80 only!
Think about it. Both sensors have IP addresses we can change; but if both are fixed at TCP port 80, their port-forwarded outside address is the same—204.xx.xx.18!
I’m not sure if I was the first person to question this situation, but I may have created a few ripples down in the engineering department at a couple of places. When I e-mailed one of them asking how to address two “fixed port 80” devices, here was the response:
> Inside your network, the data logger is at 192.168.1.3:80. Outside your network, you want the data logger to appear at 204.xx.xx.18:8080. To accomplish this, configure port forwarding on your router to take an incoming packet on port 8080, and map it to 192.168.1.3 on port 80.
In truth, their engineering people were absolutely correct—if you have a router that does PORT ADDRESS TRANSLATION, not just port forwarding. To my knowledge, none of the common Linksys or Netgear routers do this. Obviously, their product was designed by an engineer working in a lab behind an expensive commercial router who was unaware of the differences. But, don’t think that just tossing your Linksys router solves the problem. I recently bought a SonicWALL commercial router just so that I could add 25 more port-forwarding addresses (I presently have 26 IP addressable devices on my network) and perhaps solve the problem with “fixed Port 80” devices. Unfortunately, out of the box, my new “commercial” router doesn’t do PAT (Port Address Translation). It is another $370 software upgrade to add PAT. Over my dead body.
I have 11 different kinds of devices on my network and three of them are made with TCP port 80 fixed (really stupid!). Ordinarily, the easiest kluge-technique to communicate with only one at a time is to power only one at a time. Unfortunately, data loggers and DVRs need to stay powered in order to collect data. The awful solution is to attach each device to a separate Ethernet expander switch (all connected to the main router) and X-10 control the power to them via the home control system (HCS). A controlbyweb.com WebRelay-Quad is attached to a couple of HCS input bits and initiates the control routines. A simple web page flips the web relay switches and designates the communication path—a convoluted path for sure.
Ultimately, I trust that equipment designers will get the message that fixing TCP port 80 to make their product “plug and go” is naïve. Until they do, however, at least I have another output bit on my WebRelay-Quad/Ethernet switch/X-10/HCS Rube Goldberg for their next screwed up product.
Priority Interrupt Archive List
|
