Date: Sat, 21 Aug 1999 11:59:48 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Steve Passe <smp@csn.net> Cc: Michael Searle <searle@longacre.demon.co.uk>, freebsd-hardware@FreeBSD.ORG Subject: Re: home automation hardware Message-ID: <199908211559.LAA35122@whizzo.transsys.com> In-Reply-To: Your message of "Tue, 17 Aug 1999 21:43:03 MDT." <199908180343.VAA58390@Ilsa.StevesCafe.com> References: <199908180343.VAA58390@Ilsa.StevesCafe.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> x10d: > The serplix controller (my funky design) is definately outdated. > Although I am still using mine 24/7, I wouldn't recommend that anyone attempt > to build one today. The lynx10 might be feasable. The parallel port tw523 > would also work. But the proper action would be to use the newer x10 > computer interface: cm11a. Its available alone or as part of the x10 > activehome kit. IBM also makes a branded version of this kit. The hardware > specific module of the x10daemon would have to be ported to support this > hardware, but that shouldn't be too hard if you understand c++. I'm using the CM11A in my home automation system, with a modified daemon, originally done by Dan Lanciani. It's a TCP server that multiple clients connect to to send or receive X10 powerline events. I think the general concensus is that all X10 power line interfaces suck (at least the 2-way ones). They suck in different ways, sometimes depending on the particular version of the device (e.g., the CM11A). But, it's sorta a crock overall. But very useful, nevertheless. > ird: > The ir hardware is also antique, besides being hard to use. I would > suggest starting with the crystal semiconductor CDB8130 evaluation kit. This > kit include 2 assembled prototype boards built around the CS8130 multi-standard > infrared transceiver part. It has a standard serial interface for the > computer, > and should be MUCH better suited to the job. Down side is that not only will > the hardware specific module of the irdaemon need to redone, but the code > for "learning" ir data will have to be re-rolled to deal with this new part. > On the plus side, this board might also talk with the ir port of your > laptops... (no guarantee, I havn't researched it well enough). I'd dearly love to add something like this to my home automation system, if only to make the home theatre system usable by my wife in other than the "default" configuration.. > mld (ie temp monitor): > The dongle described on the pages is a home brew from a cci article. > Dallas now makes a part that provides a standard serial interface that > uses byte (nibble?) wide data instead of bit-banging. The dallas part # is > DS9097U-09. Again, a port of the hardware module for the mld, but this should > be fairly straigh-forward. I'm using a couple of the Hot Little Therms (http://www.spiderplant.com) which also use the Dallas Semiconductor DS1820 "one-wire" temperature sensors on a multidropped bus. These have the advantage of doing the icky serial line protocol, but are not very flexible. I've started playing with the DS9097U device, but haven't made very much progress due to the HLT solution working OK. There's one other issue with the DS9097U based solution - you really want the device driving the bus to have a "strong pull-up" while doing the conversion, especially if you're commanding all the sensors on the bus to convert simultaneously. The DS9097U is convieniently powered from the serial port, and may not be able to supply as much power to the bus as an externally powered device. This may only be important if you have multiple sensors and hundreds of feet of wire (and associated capacitive load) you're trying to drive. In my system, I gather temperature readings every 4 minutes, and insert them into a MySQL database. This application is a tcl script. Other applications query the database (e.g., web interfaces, and a Tk application running on the console display connected to an VGA/NTSC scan converter and modulator onto channel 16 of the video distribution. ) I also have a X10 macro processor daemon that connects to the X10 daemon and "translates" X10 events. So, a A1-ON from a keypad might be translated to multiple ON commands to turn on multiple lights. Similarlly, the dusk/dawn sensors on the X10 floodlamps are used to turn the porch lights on and off). This daemon is also a tcl script. There's another daemon which listens for caller-id and collects call detail data from a small PBX in our home. It also inserts the data into a MySQL database which various web applications and the aformentioned Tk console application query. This daemon also acts as a network server which other processes can connect to over a TCP connection to get "real time" feeds of the data is it happens. This daemon is all written in tcl too. There's a daemon which is an adaptation of an X10-remote daemon done by Randall Hopper. I wrote a general network-server framework in tcl which can run another process, and distribute it's standard output to multiple TCP connections that it serves up. This same framework is also included in the other tcl based daemons that are network servers. Nothing quite uses this yet, though I'm reworking the Tk console application in [incr tcl] and [incr widgets] to have multiple "pages", and the wireless X10 remote control will likely be used to control that. > final thoughts: > > most of the code you encounter for these projects is very rough. It started > out as a "proof of concept" for the idea of connecting a series of control > daemons together. As each daemon was first made to work, we went on to the > next. As each was done, things were learned that changed the overall design, > but seldom were those lessons ported back to earlier daemons. As a result > the overall package is crude and hard to install. But once working it is > pretty slick as it gives you integrated control of power, audio/video, > temperature, alarm systems, etc. We got a http web version working at one > point, a vmrl driver would be most cool! > > If I had the time I would rewrite this whole thing from scratch, using the > knowledge gained on the first version, but who has the time.... My thoughts exactly! I learned quite a bit during the process of doing all this stuff. The central concepts that I've been building around now are: - do as much as possible in a scripting language (tcl and tk are my preferences) since this isn't a performance limited application. I found I was much more productive in being able to add features and testing with this approach. - build this as a distributed system. Each of the functions in the home automation system put data into a (network accessable) database, and/or communicate with other applications over the network. This lets me trivially run the web interface on a different platform than the home automation controller, and makes testing easy. In general, you can "tap into" the event stream by just connecting to the daemon in question to see what it's doing. I've been trying to convert stuff over to use some libraries and [incr tcl] classes rather than a bunch of unique code in each daemon. I've been surprised at how much rude and ugly serial line stuff I'm able to easily do in tcl, too. What's really missing for me are alternate human interface terminals; I'm hoping the Tk console application on channel 16 and the X10 remote will help some here. But you'd like something simpler than having to turn on the TV to control lights; currently I've got two X10 "mini-controllers" doing that. But I found that I want to avoid using X10 as much as possible because it's very slow and some some degree, unreliable. I'd love to have some small panel on the walls, wired, that look like alarm consoles to do this function. I also want voice mail integrated into this system as well. There may be some changes in the PBX part of the system that will help this along in the future. I want to add more video; in particular, cameras with external and internal views. Coupled with a Bt848 digitizer, you could capture frames on demand or during "interesting" events. I'd like to have some integration with the security system. Currently, this is deliberately isolated. But I think that having an "ARMED/UNARMED" status available would enable some new applications. I also want to suck in all my CDs and MP3 encode them for a jukebox application. I think that 20GB of cheap IDE disk or so would go quite a long way. When the Tcl 8.2 is out and stable, I want to convert all of the TCP server infrastructure to use (probably SSL) encrypted and authenticated TCP connections. Right now, I have to filter those ports at my router so that folks don't turn my lights on and off for me remotely. I want to secure the daemons themselves than rely on external security measures like that. I'm planning on releasing snapshots of this software from time to time. So far, only one other person with some similar hardware has been playing with it and giving me feedback on how to remove configuration information specific to my house from the code. Most all of that stuff is supposed to be isolated in one place. I'm in the middle of breaking some of it right now, and once it's all stable again, I'll tar it up an put it some place. FYI, the main home automation stuff is running what was -current as of last February or so; probably pretty close to 3.2-RELEASE now. Up time is of course limited by external events.. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908211559.LAA35122>