Slashdot Mirror

1) Engineering costs money.
2) Good engineering costs even more money.
3) Your "common off-the-shelf" protocols are both nonstandard and shitty. Try BACNet.

A low-end controller from Trane or JCI won't set you back much. A high-end controller will, but it's also completely unnecessary for your home, which is why it's "commercial" and not "residential" automation.

If you want ultra-low-budget, get a damned RPi and bolt it into a panel with some relays. Parts are easy to come by from, for example, Kele or BAPI. Kele even carries some low-end controllers from the smaller players in the industry.

Programming it is up to you, but it shouldn't be hard. If you want something "easy", then be prepared to pay for something like Automated Logic. Their programming "language" is called Eikon, and it's quite possibly the only graphical programming language I've ever seen work worth a damn. It isn't a general purpose language, but it certainly does what it does very well.

1) Engineering costs money.
2) Good engineering costs even more money.
3) Your "common off-the-shelf" protocols are both nonstandard and shitty. Try BACNet.

A low-end controller from Trane or JCI won't set you back much. A high-end controller will, but it's also completely unnecessary for your home, which is why it's "commercial" and not "residential" automation.

If you want ultra-low-budget, get a damned RPi and bolt it into a panel with some relays. Parts are easy to come by from, for example, Kele or BAPI. Kele even carries some low-end controllers from the smaller players in the industry.

Programming it is up to you, but it shouldn't be hard. If you want something "easy", then be prepared to pay for something like Automated Logic. Their programming "language" is called Eikon, and it's quite possibly the only graphical programming language I've ever seen work worth a damn. It isn't a general purpose language, but it certainly does what it does very well.

BACnet patent licensing costs more than you might imagine. And if you're in Europe, you're even more screwed because everything uses LON. LON is proprietary, so both their patent licensing and their trademark licensing will rape you.

And then you need to build an embedded device that isn't just a Raspberry Pi with some other crap soldered to it.

I used to work for an Automated Logic dealer, pre-United Technologies. Their stuff was simple and consistent, but by no means flashy. It was also hella expensive. A basic single-program controller had a dealer cost of $500-ish. The multi-program boards that powered the big air-handlers and/or complicated lighting and security systems started at $2000. Expansion boards started at $500. And then you needed WebCTRL to deploy the program to the controllers, so there goes another $1500. Dealer cost. And their dealers typically have a 100% markup, so double all of those numbers. (And then tack on 10 years of inflation, because I quit working there in 2005, and I doubt they've lowered their prices any.)

This has been happening in the HVAC industry for 25+ years. They originally called it "Direct Digital Control" (DDC), in contrast to the older pneumatic control systems. I worked with some of this stuff 10 years ago, and it was a well-known field even then. Granted, it wasn't directly on the internet, but it had gateways and bridges that allowed it to be. (The company I worked for sold a particular brand that used MS/TP and Arcnet networking for the actual controllers, and connected them back to an ethernet gateway for integration into an IP-based network.)

No, "IoT" is more than that. It's the consumerization of embedded and automated systems. So instead of having installed systems with well-thought-out logic and segregated networks, we'll all be hip deep in useless, poorly-configured, ad-hoc-installed, incompatible garbage that's taking up all of our IP address space.

For problem-domain-specific programming languages, it's fine.

I worked with an HVAC control system that used a graphical language. Here's the marketing brochure for it. If you look at that brochure, it shows a graphical program, then it shows an equivalent program in pseudo-BASIC. And if you notice, the best part is that everything is a watch variable when the program is running and you're monitoring a live system. That's why each "microblock" has little yellow numbers or words next to it. That's the current value coming out of that part of the program.

It's a very well-thought-out system for the specific problem-domain it's in. And I think that could be true of a great many other problem-domains. This is where graphical programming can really shine.

But general purpose programming is always going to require more rudimentary, low-level tools than that due to its nature. Think of it this way: Somebody had to use a low-level language to program that graphical language. It will always be that way. You can't build a house without digging a hole. Somewhere, someone has to work in the dirt to build a house. Somewhere, someone has to work in machine language to build a software program. Thankfully, we have compiler authors. They're the earthmover operators of the software world. Nothing gets done without them, what they do underlies everything we build, and if they mess up, then everything we build is unstable.

Just for the /.-ers that don't know much about this stuff, LON-anything is patent-encumbered. BACnet is far less so, since it was designed by ASHRAE instead of a corporation. BACnet was designed to be a standard from the get-go, while LON-whatever was developed by Eschelon and met whatever needs they had to sell their gear. That said, it may be one of those US vs. The World things, as Europe picked up LON as their de facto standard, and ASHRAE is the American Society of Heating, Refrigeration, and Air-conditioning Engineers.

As far as Modbus goes, it was a low-cost also-ran that had been mostly left behind by all of the big players in the building automation industry. BACnet vs. LON has been the real turf war for over a decade now.

I used to work for an Automated Logic dealer in the early 2000's, and had to deal with this stuff daily. Making a LON bridge play nice with a BACnet network is not fun. Looking through their product catalog, I see they still have the SE Line controllers. Those were single-program, but had 6 digital outputs, 10 inputs, and 4 analog outputs. They'd be quite nice for some home applications. But the list price on those was right around $1000. And then you needed software, which ran another $8000-ish. And then you needed a network bridge (Ethernet-to-Arcnet), which was another $3000 or so. Then you had to wire up and program the thing, which would be far easier to do than to part with $12,000. Totally not worth it for home use unless you're a millionaire.

Just for the /.-ers that don't know much about this stuff, LON-anything is patent-encumbered. BACnet is far less so, since it was designed by ASHRAE instead of a corporation. BACnet was designed to be a standard from the get-go, while LON-whatever was developed by Eschelon and met whatever needs they had to sell their gear. That said, it may be one of those US vs. The World things, as Europe picked up LON as their de facto standard, and ASHRAE is the American Society of Heating, Refrigeration, and Air-conditioning Engineers.

As far as Modbus goes, it was a low-cost also-ran that had been mostly left behind by all of the big players in the building automation industry. BACnet vs. LON has been the real turf war for over a decade now.

I used to work for an Automated Logic dealer in the early 2000's, and had to deal with this stuff daily. Making a LON bridge play nice with a BACnet network is not fun. Looking through their product catalog, I see they still have the SE Line controllers. Those were single-program, but had 6 digital outputs, 10 inputs, and 4 analog outputs. They'd be quite nice for some home applications. But the list price on those was right around $1000. And then you needed software, which ran another $8000-ish. And then you needed a network bridge (Ethernet-to-Arcnet), which was another $3000 or so. Then you had to wire up and program the thing, which would be far easier to do than to part with $12,000. Totally not worth it for home use unless you're a millionaire.

That's actually not all that unusual. Building Automation is definitely taking MAJOR advantage of Wireless Technologies. So, that WAP you saw in the boiler room is probably associated with the Building Automation System and thus very unlikely to be connected to the internet and DEFINITELY not connected to MIT's Intranet.

Wireless solutions are being deployed much more frequently in newer buildings and also in older facilities in lieu of having to replace devices that are depracated and run new wires (both of which can be impractical/impossible/expensive).

I left the autonomous robotic house minders and the holographic repair people in my other pants.

Really? I didn't know Building Automation Systems would fit into anyone's pants. These systems are all quite capable of monitoring and controlling the temperature in the building, as well as notifying him of catastrophic failures (or warning signs of an impending one). They also all allow remote logins via web interfaces.

Personally, I recommend the Automated Logic one, as I've had experience with it and I know that it's a solid system. Not cheap, though. The hardware necessary (a custom PLC, essentially) will cost you at least $10k, and the software will be another $3-5k. Installation will cost $5-10k.

Target uses Automated Logic HVAC controls. ALC has had a long-standing relationship with Liebert, and *they're* the "specialized" HVAC guys that do server rooms. I know all this crap because I work for an ALC dealer. I do this stuff for a living.

As for the GP's question about outside air: yes. Outside air is very commonly used for "free" cooling. You have to calculate the enthalpy, which is the potential amount of cooling based on the temperature and humidity of the air inside vs. outside. Basically, if you have low outside air humidity, your enthalpy can go sky high. This is especially true if your indoor humidity is high. It's basically just a calculation of how much surface evaporation is going to take place if you mix these two air sources.

Of course, a proper HVAC unit is going to have decent (and hopefully well-maintained) filters. Which means that those server room units are already using as much outside air "free" cooling as they can.

72(all temperatures in this post are Fahrenheit, so get a calculator and simmer down, Euro-boy) is considered the "ideal" indoor temperature. Keeping the temperature higher costs more. Keeping it lower costs WAY more.

I work with commercial HVAC controls all the time (I work for an Automated Logic dealer) and I can tell you with the authority of a fair dose of experience that people don't have a clue what temperature they're comfortable at. No clue at all. Not even when beaten with a clue stick.

77 is hot. 65 is cold. We generally set our systems to keep a zone between 72 and 74. Some customers (especially school districts) like to drop that "standard" differential to 70-73. A wider range uses less energy (turning equipment on and off gets very expensive) and lowering the temperature allows the heat to cycle off for longer periods (thus saving energy). All this energy savings adds up to $$Your-Tax-Dollars-At-Work$$ being used for other things that are more important, like teaching the kids.

Other customers (like building management companies) like to keep rigid rules about the tolerances in certain rooms (like data centers) to keep the room cool. They're usually a set-it-and-forget-it situation, unless something breaks. Then you have to fix it right now.

Still other customers (like office buildings) will just let the workers run them ragged with every breeze that ruffles their hair, changing setpoints constantly. They're the ones we love to hate, since they're always complaining about the decision they made yesterday to lower/raise the temperature and how it made things too cold/hot and now they're uncomfortable again. All too frequently, we find that these people need a good bitchslapping. We also find that frequently, their problems are caused by a poorly designed building and/or their desire to have control of something in their hectic, pointless lives.

I fear all too many /.'ers fit into this last category and would love to escape. Knowledge is power, and now you know. Do something about it. Don't just gripe about "Temperature Facists".

do these systems control the lights

Yes. Speaking strictly about ALC products, you can either turn the lights on and off with control programs in the general purpose "HVAC" controllers (which have various configurations of inputs, along with a fully programmable microprocessor from the PPC family), or you can buy a Triatek (made by ALC) lighting system, which undoubtedly has more features for lighting, but isn't quite as general purpose.

Basically, the system is a set of networked control modules, each able to turn things on or off (Form C contact, 3A max), ramp up and down with a variable output signal (0-10VDC or 0-20mA), and sense inputs of several types (thermistor, dry contact, 0-10VDC, 0-5VDC, 0-20mA). The controller itself can handle timed schedules and network-viewable points (inputs or outputs on other modules, broadcast over the network). A central server hosts the software and user interface, but each module has its program flashed into EEPROM. Reprogramming is a matter of a few seconds, but loss of power doesn't necessarily cause catastrophic failure.

To sum up: you can control damned near anything with a system like this.

I work for a building automation contractor, and I can tell you, this stuff has been around for years. There's even a standard for stuff like this, and it's nothing nearly as lame as a new XML-DTD-that-will-save-the-world.

The standard is called BACnet (Building Automation and Control Network), and it was (and is) developed by ASHRAE, the American Society of Heating, Refrigeration, and Air-conditioning Engineers.

We (at my company) are a dealer for a particular brand of native BACnet controllers and software. It's all web-based. Everyone in the industry has web-based software now. Ours happens to be multi-site, too. And ours can interface easily with several hundred different manufacturers' products, including UPS and generator managers. We also frequently take direct control of chillers, which are huge power hogs. All of this can be programmed to maintain a steady climate, light areas appropriately, and keep equipment from failing prematurely, all while monitoring and controlling power usage.

This is hardly news, and certainly not standards-compliant.

Actually, decoys work.

I work for an HVAC controls contractor selling Automated Logic controls. We routinely install sensors with setpoint adjustment sliders on them, then limit the adjustment to +/-2 degrees. Some customers ask us to limit it to +/-0 degrees, essentially installing a placebo. It works. Even when there's only a placebo in place, the service calls are for actual problems.

People only need to think they're in control to feel better. And any spouse that calls a repairman without consulting their mate is a nympho, just so you know.

Puh-LEASE.

Demand control ventilation has been around since the late 70's, and has been in common usage since the introduction of commercial DDC (direct digital control) systems in the mid 80's.

I work with this stuff all the time, and some of this stuff is getting so old you can't buy parts for it anymore. The Automated Logic controllers I work with every day run an MC68030 or a 65c816 as the main CPU. Those are being phased out in favor of slightly newer stuff right now. Older controllers used 6502's and even a few used nothing more complex than a handful of TTL gates.

As for internet connectivity, we sell a nice $10,000 software package called WebCTRL to go along with our controllers, and even that has been out for about 3 or 4 years now. It's headed for version 3.0 right now. Before that was out, you had the option of dialing in to the system with a modem, which has been an option for no less than 15 years now.

There's only one area where I see a difference between this and what you're describing. You describe it as giving the power company the ability to alter my building's usage rather than me being able to alter my own building's usage. This appears to be a slippery slope, and I'd rather not tread there. Working as an HVAC controls contractor, I know exactly how pissy some customers can get if someone complains about a room that's a degree too warm. I'd wager that power companies don't dare touch this one with a ten foot pole.

Using building automation products from an outfit called Automated Logic. The company I was with sold ALC stuff and wired up many school districts with energy management systems that allowed the main office to dialup remote sites, get a nice graphical display of the floor plan color coded with room temperatures, can schedule heating, cooling, and all aspects of HVAC control, fans, chillers, you name it.

I guess the big 'new' idea here is replacing the dialup phone line with Internet, just like web sites replaced the bbs's of that time.