This page contains information pertaining to the software for communication between Linux and the Creative Control Concepts HCS II (was the Circuit Cellar HCS II) Home Automation Control System. The code here is not in the Public Domain but may be used for non-commercial use. See the Copyright for further details. Future releases may be release under an Open Source agreement (probably the GPL).Software:
Currently I have the following available:
- My base HCS II code - This release works but if you try to send too get too much from the HCS the syslog will fill with !Reply errors. The serial port was easily over runninng the buffers, that was the bad news because I now have ti fixed. The good news is that I fixed the problem and you can issue commands and poll for a single status. That works. Remember this is an Alpha release. I've open up my Linux Home Automation project on Source Forge and I'm hoping that I can get help there to releive the buffer over flows.
- Unix HCS Interface - The original unmodified code (sort of ...). This is a client to view the status of the HCS II. There is also a TCL/X interface to it also. I'll put in bit more work in the future to clean this up.
The goals of this project are currently relatively simple. The first is to create a daemon which will communicate between a client (at minimum, a telnet session to the port) and the HCS II attached to a serial port of the computer. Next, CLI programs to allow shell scripts to interact with the HCS II, followed by an events & status monitor, lastly by a GUI interface program (this includes curses and Perl/Tk based programs).
- I need to add further security, not just tcp wrappers. I also need to add a login/password challenge. The hcsd should still be run as user nobody but when a user logs in at least you can have some kind of trace of who they are.
- Fireball - Initially I wanted to put together a group of packages call X10-Fireball. The name comes from a slight spoof of a 60's British TV show and the fact that my wife thinks my projects will end up in a fireball. The package will consist of my hcsd code, client software, and a status and events program.
- Tkhost - This software will provide Linux with a look a like program that mimics the DOS based host program.
Better progress has been made! I dropped back to the last release of hcsd without the pthreads and analyzed why the drops occured. I've made the changes and no more drops. Also the CPU utilization has dropped into the 12-16% range for a couple of connections. I'll need to double check the code to see if everything is still in there.
Progress has returned, I'm now able to receive all the characters from the serial port, translate them and send them out to all the TCP/IP connections. Now it's time to put everything in place and really make this thing work. I've worked a bit on processor utilization and managed to get hcsd down from 50% to 25%. Which is about all I can do, when it's released hopefully people will help me clean up the code that part of the code. Currently the code is a real mess and I need to re-add the log dump and XPRESS file load. Both of these shouldn't be too bad to handle, a couple of locks and the unbuffer routine is all theirs.
I'm still working on the program, though the progress is at a minimum. I'm half way through reading the book "Programming with POSIX Threads". A bit heavy reading but I'm absorbing it so far. I'm also attempting to figure out the locking, I'll need to do some so that everything works properly. I've added a few bits and pieces of code here and there. Nothing substantial, I've also spent a bit of time building up the init scripts for X10d, HomeDaemon, Wx200d and hcsd. There is a lot of code in this program which is not needed, I'll clean it up some day. I may even profile it to see if I can speed things up a bit. One of my goals is to have this program run properly on my 386sx/16 MHz machine (w/16450 interface chips yet). I'm really starting to understand just how complex programming can be. I a little over 3700 lines of code and comment and I need to worry about algorithms, support programs, permissions, file dependencies, etc. It is enough to give a person quite a headache.
Oh-Oh, now I've gone and done it. I broke the code. Turns out my HCS II didn't have a valid events.bin file loaded. So today I wrote the code which took the file stored on the server and wrote it to the HCS II. It worked properly the first time (yeah!) but when it finished rebooting I had to turn off the display for all the devices. The output overloaded my code (boo!). So I am now in the process of re-writing the read/write routines. This will allow me to remove Dan's coding and make the entire package Open Source.
I should warn everyone right up front that this code is currently Alpha (untested) code. I've been using a lot of hard coded arrays (which is not a good idea). I have no real error checking in place. I've finally downloaded a "real" XPRESS program to the HCS II (although in a round about way). For now I'm just coding it up in my spare time (about an hour a night). Still I am proud of most of the code (and the rest I can't remember programming :-). The Beta release will have the code cleaned up and should have the selects properly working, along with threading (another set of algorithms to work on).
The basis for this code is Dan Lanciani's x10d code. I've modified it pretty extensively so it is my code but most of the TCP/IP setup is his (always give credit where credit is due). I also hope that my modifications bring the code closer to being POSIX compliant so it should compile under other Unix's. I'm currently working on removing Dan's code and replacing it with pthread'd code. This is because of coding problems I've caused, not Dan's code. This will also allow me to release this code under the Open Source GPL.
Mike Baptiste (Creative Control Concepts) has offered to host the code and provide CVS access to the code. I'm not sure what exactly that entails but I do know that it's a good idea.
The current code is a work in progress but it may be of interest to others.
So here is the count:
- General house keeping is in place, uucp style locking has been added. We can drop into the background, bind to the service, open the device, prep/receive/terminate the connections, open syslog and write to syslog (this is how I debug the code, I also use a sniffer to debug the communications).
- Users can telnet to the hcsd and it checks, via tcp wrappers, whether to let them connect (this can be disabled, it's a compile time options). The help command is in place now (when telnet'd in, the CLI help message is not yet available). The user is able to type in a command string, the hcsd interprets it and the command gets forwarded to the HCS II. Currently I have no error checking on the commands so if you send the wrong command, a badly formatted command or a short command, the damage is done. This is especially true of the "load XPRESS" command.
- Need to work on the documentation, login/password section, the pthread code to alleviate serial port buffer overflows, the switching over to nobody.uucp (uid/gid), command level permissions, malloc instead of stack memory, login/password (this is more difficult than it seems).
- I've created the user program to load XPRESS (but I may modify it further). I now need to create the user program get log, a user program to issue commands and poll status, and maybe even a host program. Currently I have a few quick Unix shell scripts written. I don't have to have the source to the host.exe program because it's explained well enough to write my own. The load XPRESS is written. I've chosen Perl to provide at least one example of how to do it. It requires at least Perl 5.005_03 and Tk 8.00. Expect.pm is out because I can not create a portable program using it (portability is the point of the program). I really like Perl, it may be slow but it does permit one to quickly put together code and it is very flexible.
- I've created a /etc/rc.d/init file called hcsd.sh. It's written for use under RedHat 6.0 (but it should work with 5.2 and 6.1 also). Currently it is Alpha as I haven't tested it.
- Need to upgrade to 3.62 (or whatever is the latest), get an Answer man board, the TV board and a few other boards for testing (playing). My current setup is just the PL-LINK and the SC (w/BUF-Term).
12/27/99 - FINALLY, SUCCESS! While running various code to see why was overrunning the buffers I noticed that the drops seemed to occur at the exact same spots every time. Did some fiddling and notice it started back up after a Control Z (Unix Suspend). Check the setting on the serial port with stty -a </dev/hcs and found that various control characters where still defined. So I undefined them and I haven't dropped anything since.
12/9/99 - Work continues but I am slowed by the serial buffer overflow problem. I'm reading a book on pthreads and I am half way through it. I've also put in a little bit of coding on the init scripts for RedHat, worked on switching the uid/gid at startup and begun investigations for the login/password code.
11/25/99 - I've put the code under RCS (V1.6 alpha). I'm still working on the overrun problem. I've added uucp locking and I'm working on the login (Linux has several 'crypting choices which makes coding interesting). I've added a bunch of scripts (which means you can start to play with the program). I need to update the README to explain the permissions and id/group configuration.
11/24/99 - I've fixed up many of my problems with the HCS II. The PL-Link now works correctly (had a flip cable on it) and the log RAM was jumpered wrong and one pin was bent. I'm still looking over the code trying to resolve how I'm going to repair buffer over flow problem (dropped chars on the serial port). The first thing I'd better fix is all the r/w handling. I'm also moving all the current code under RCS and calling it V1.6 alpha. I've included a script to shut off all the status messages so we don't overrun the buffers. A few other scripts are included that all you to do sets and gets.
I've removed the history from the page as it was meant as an update.
9/99 - hcsd is started. There are several files in the hcs.tgz file. There is the old HCS code. There is the code that will compile under Linux. And then there is my hcsd code. I'm really only working on the hcsd code right now. But if you have questions about the other code I will try to answer them.
Note this is the way things are supposed to work. This may be modified by the time the software goes beta. The response format may change a little but the general idea will remain the same.
This is a user request for info on the X10 module D1. When the HCS responds back it may respond back like this:
Which means the D1 is on.
The user will not be able to download a new XPRESS program without some help so I will have an external program written to handle this. I will also have a program written which will interface to the get log program. A user will be able to capture the log but it will still need to be translated.
The Send string to network and Send string to voice board will have slightly different format. It will be as such:
!30This is a string to be send to the network
This sends the string "This is a string to be send to the network" to the network. It will be automatically null terminated. I will also try to support the standard C convention \t, \n, \r, \b. \xxx (where xxx is an octal number) etc. This should cover most of the escape sequences.
In the final version of the hcsd, I should have a CLI program to turn on and off various I/O, a program to query a devices status, a program to load a new XPRESS program and a program to pull back the log, store it, and decipher it. I may also attempt to create a TCL program to interface to the hcsd. I'm not sure about the CGI program, I'm still working on the design for that one. These programs will be written in shell, Perl, TCL, and C. This should provide a pretty good example of how to interface to the hcsd in a variety of ways. It may also be possible to write the entire hcsd in Perl to allow it to work on both the Microsoft products and the Unix family. I'm not really up to the challenge but it is possible.
There will be more added here as I further think this through.
A login would probably be a good idea. This would provide another level of security. This appears to be more difficult than it sounds. This is because some of the RedHat releases use MD5 instead of crypt (DES) to encrypt their passwords. I do not of a library call to compare passwords on a machine using MD5.
I would like to provide an SSL interface to the hcsd. I currently have no idea how to do this. I would need coding examples and a freely available SSL library. I would also need to create the client software so a user could properly connect. In this instance i think I've been lucky. I've found OpenSSL for Linux and a SSLeay module for Perl. I haven't looked at them too closely yet.
Heck this may be an idea for an article in Circuit Cellar Ink.
I would love to recreate the DOS software "host.exe" for the HCS II. Maybe when I have a bit more time.
- 2 9600 baud Serial Ports (1 RS-232 & 1 RS-485)
- Up to 256 digital inputs and 232 digital outputs (local and networked)
- 32K of Program Memory - battery backed
- 32K of Datalog/Event Memory (4096 event capacity)
- On Screen TV Display (with PIC-TV)
- Telephone Access (with HCS-DTMF)
- Text to Speech Voice Synthesizer (with HCS-Voice)
- 2 Way X10 (with HCS-PLIX)
- 2 Way Learning IR (with MCIR-Link)
- Dallas iButton input, Keypad Input, Pulse Width Modulation, Pulse Counter (with AMAN-Link)
- Local & Remote Analog Inputs, both 8-bit and 12-bit (Remote Analog requires AMAN-Link)
- 12-bit Digital to Analog outputs (with AMAN-Link)
- Battery Backed Real Time Clock/Calendar (Y2K Complient!)
- Caller ID capable (when connected to Caller ID modem)
- 128 Variables
- 128 Timers (64 second timers, 64 minute timers)
- Random Number Generator
- AC Power Monitoring (with HCS-PLIX)
- Event Logging (up to 255 unique event IDs)
- Send text/data to a parallel printer (with PIC-DIO)
- Edge sensing of digital inputs
- Signed 16-bit integer math (add, subtract, multiply, divide)
- 512 32-character labels (can be assigned to inputs, outputs, etc.)
- Can send ASCII strings directly to the RS-485 network
- IF statements can be evaluated always or only after a state change
- Remote Access to system via connected modem