I created this blog to have a place to capture my thoughts, ideas and progress in the creation of a system of integrating different devices and systems together in meaningful and mutually beneficial ways. What I hope to accomplish is to keep a record of the things I create, the challenges that I face and the projects that encompass the Venturii project.

 

What Is Venturii?

Like many things, Venturii started out as an idea. Several years ago, I bought a house. Working in the security industry, one of the first things I considered installing (after an Underground Sprinkler System) was a security system. One of my colleagues, Kim Husted, highly recommended the DSC Maxsys system as it could not only do security but also had add-on modules for access control, voice-menu driven telephone control (so you could call your house and arm your system or water your plants) – it also had an X10 interface for controlling X10 devices such as lights or other appliances. More to the point of security, it allowed up to 128 zones and had LCD keypads (those LED or Icon-based LCD ones always drove me nuts.) Last but not least, it had a serial interface so you could connect it to a computer. It sounded like everything I could ever want, so I bought one.

Getting the security portion of it installed was a breeze. I had the doors and windows secured and a number of motion sensors set up within hours and all was well. I had purchased the X10 interface with it and already had a number of X10 switches installed, however very quickly I discovered that the X10 module required a third party interface device to actually connect the alarm system to the power line so that the X10 commands could be sent.

Patiently waiting for eBay items to ship was a talent learned in time, but eventually my interface arrived and I was very excited. I had set everything up and plugged it all in, and in no time had discovered that there were some very hard limitations on what exactly the X10 module could do.

Originally what I had wanted was that the Maxsys would turn off all the lights in the house when the system was armed. That way, on my way out the door I could arm the alarm at the keypad and leave, knowing that all my lights (should) be off. The system however only allowed you to control one X10 device in this fashion. Someone suggested setting all of my switches to the same address, which would have accomplished the global turn-off, however now I could not individually control any of them either. Not an ideal solution. I wondered about the possibility of using the serial interface to watch for the “arm” signal from the Maxsys, and then issuing the multiple commands necessary to accomplish the device control I desired. Therein lay the seed that planted the tree that became Venturii.

It wasn’t long into the coding process that I realized I wanted something that would be flexible and expandable down the road. A strictly purpose-built piece of software may have solved this immediate problem, but the wheels within my brain were already turning and seeing other opportunities as it became apparent all the data that was available from the Maxsys panel. Every time a zone went off normal, a code appeared on the serial port. Every time the system was armed or disarmed, or went into trouble I got a status code. Pretty soon I started to imagine other applications to put such information to. “What if, whenever the front door was opened, the PTZ camera at the corner zoomed into the front porch and got a good look at the person entering or exiting the door?” My friend Kris from Shaw also put a Maxsys in his house, but wanted to get an email whenever the system was armed or disarmed, and particularly whenever it went into alarm. Integration ideas began to extend to other systems too, and I started to see a structure in my head that would become the basis for what is now known as Venturii.

 

Chickens and Eggs

I don’t remember now which actually came first of the three modules, and in reality they were probably all developed about the same time since they all worked together. The first system struggled through the naming process, originally starting out as openhouse. I wanted to start an open-source project, and so reflecting that in the title made it fundamental to the nature of what was being created. It sounded too much like a real estate project though, and I renamed it to autohouse. That sounded a bit German, and I soon discovered that there was already an automation system called Mr. House. I remember studying the service manual of my Seadoo, a 2000 GTX-DI, and looking at the pump section it talks about the venturi portion of the pump. That word, venturi caught my attention and the more I thought about the Seadoo and the pump and my newly forming automation system the more I liked the name. I actually toyed with the idea of calling it VenturIO, since it was basically dealing with various inputs and outputs but dropped the O and replaced it with a second I and the name stuck.

That first rendition of Venturii was comprised of three modules: The heart or brain of the operation was called Decider – It had a set of conditions and actions and basically was glorified IF-THEN engine. There were two device drivers, one to talk to the DSC Maxsys panel which I called dsSEE which – when pronounced sounded like “DSC.” Lastly, there was a module called ecksten which, again, when pronounced sounded like “X10.” The drivers connected to the panel and the power line interface, respectively, and each connected over a TCP socket to Decider, which derived it’s operating parameters from a MySQL database. The whole thing was written in C and ran on Fedora Linux, and I now had the original desired functionality of being able to turn off all the lights in the house whenever I armed the system. I also had it set up to turn on several lights if certain motion sensors were actuated. IE: When I went down the stairs into the basement, the motion sensor at the bottom would turn on the landing lights. If I got up in the middle of the night, the motion sensor in the living room would turn on a lamp – and then off again after a period of motion sensor inactivity. I now had the automation bug; I was hooked.

 

Digital Versus Analog

It was at this point that I began to get interested in the measurement of analog signals. Temperature sensors, in particular, peaked my interest and so after some research I ended up purchasing a simple 12-bit, 16-channel analog to digital converter which spoke an ASCII-based protocol out an RS-232 port. At the time, I had a surplus of Lantronix MSS-100 Serial-to-IP converters, and so RS-232 was my interface medium of choice. I bought the device from www.controlanything.com and it was called an AD1216 ProXR board, and they have (what appears to be a subsequent generation of the board still for sale on their web site (http://www.controlanything.com/Relay/Relay/ANALOG_TO_DIGITAL)) still for sale. I bought one of these and struggled through a design flaw in the board with one of their technical support guys who ultimately found that they had missed a trace on the board, which – under certain operating conditions, such as when connecting it to a Lantronix MSS-100 – it would give very erradic readings. He repaired my board and returned it to me, and I fought with UPS over brokerage and customs fees despite having all the correct paperwork indicating that it was being sent back to me after warranty repairs had been completed… that’s a rant topic waiting to happen, one which I believe I wrote about on my personal blog complete with pie chart and everything. I digress. With a properly working Analog to Digital converter now at my disposal, I wrote a fourth Venturii module, calling this one XRAD.

Next I needed analog sensors; something to measure. Temperature came first to mind, and I purchased a number of LM34 sensors and an interesting little temperature and humidity-combo board and mounted these all around the house. Pretty soon a web based user interface was formed, written in PHP, and using the JPGraph Graphing Library, I began to chart the temperature noted at different locations throughout my living space. Pretty soon outside air temperature was also being recorded, and I started collecting heaps of fascinating information about the patterns of heat addition, loss, and movement throughout the house. The user interface portion of Venturii that I still use today is still basically that original, simple code, expanded and updated a little bit.

Now I had a second source of information to work with in Decider, and so modified it to include the ability to  execute commands only if certain conditions were met. “If the temperature in this room is below 18 degrees AND the security system is disarmed, turn on this lamp (via X10.)” Ok, so proof of concept works, but turning on a lamp when it’s cold is not all that useful; turning on the furnace would be. So that’s just what I did.

 

Controlling Devices Without X10

At this point I had been tinkering with the control protocol for some access control hardware I had at my disposal. A board would come from a job site with a failed relay or a blown input, but would still be largely functional. These items began to add up and so also built up my desire to make them useful again. After many hours of tinkering, I figured out how they talked to each other and created another module, code named MYSC at the time – more recently renamed to Mercurii after the Mercury Mines in the old DOS game Duke Nukem II. This module allowed me to use these very well built input and output boards with my growing home automation system. I re-wired the furnace in the house to one of the relay outputs and connected a relay in its place to the thermostat, in turn attaching the Normally Open contact of the relay to an input on the access control board. Thus, I could interrupt and/or control the furnace through Venturii. Pretty soon I got the idea of installing electrically actuated dampers throughout the house. I purchased 14 Honeywell ARD-5 dampers and tied them into the system, with Decider directing their operation based on the armed state of the alarm system, the temperature in various parts of the house and the activation of motion sensors throughout the house. The web interface got some development time and pretty soon had an interactive map of the property with real-time icons depicting the status of doors, windows, motion sensors, lights, the furnace, the state of the ducts (or dampers supplying the ducts) – it was, if I do say so myself, pretty slick. The underground sprinklers were added to relays on one of the output boards and put on timers programmed within Decider, and pretty soon I had the greenest lawn on the block. It was fantastic. The house was more comfortable, the furnace ran less heating only areas that were cool and occupied instead of the whole house every time the upstairs hallway got too cold, and I could check on the place from anywhere there was Internet access…

 

… And Then I Moved

I like to think of that first house as a rough draft. Not that my [current] house is a final copy – by no means – but I learned a lot, and have done many things different this second go round. For starters, I moved away from X10 as a control protocol for lights and appliances in favor of Smarthome’s Insteon device family. Not only is it faster and more reliable, but their protocol allows two-way communication between the devices. Insteon has solved many problems I never knew I had such as three and four-way dimming – all with indication at each switch! Naturally, this lead to the development of a new Venturii Module, this one simply named ION. The Insteon protocol was by far the most technically challenging to wrap my head around; one example is that result codes have different meanings depending on the device category and model that sent them. Therefore, you have to know and keep track of what each device is when you interpret data from the powerline. The Insteon module has been very stable over the years, but I’ve been savoring the thought of re-writing ION. I’ve been working out new ideas in Decider, the Venturii libraries and the Mercurii module to have them finalized before revisiting ION.

“Working new features into Venturii really gets me excited.”

I think it’s all the potential that really makes my eyes sparkle as I think about it. It’s being able to do things that just haven’t been done before. It’s about having an idea for something, and then going and making that idea reality. I’ve always had a passion for connecting things together. From the time I first went on a Bulletin Board System (BBS) with my Commodore 64 and 1670 modem, the time I picked up a 3Com 24-Port 10 Mbps hub and played Rise of the Triad against my brother on another PC, or first had my underground sprinklers turn on by making a phone call – I’ve always had a keen interest in integration.

As time permits and things continue to move forward, I hope to flesh out this journal with the various aspects of the Venturii Project and all that it encompasses. Some things on the horizon include the development of purpose-built circuit boards, custom sensors and smart HVAC dampers. I thank you for your interest in this project and for taking the time to read my rambling thoughts.

– John