HCS_C Home Page

Zeta Engineering designs and builds the HCS_C Home Control System, which provides home monitoring and remote control of home functions. HCS_C consists of the HCS_C base station ("HCS_C main board") and remote modules (for example, the new HCS_Combo card, along with plugins such as 16 channel relay boards, ADC and DAC boards, etc), which can be placed throughout the house for sensing, viewing, talking, or activating devices or appliances. These are connected via RS485 ("HCS_Net").

Currently HCS_C supports X10 and Insteon powerline control, HCS_NET RS485 networks, ethernet internet connectivity, analog and digital inputs and outputs, and relay switching of devices. Keyboards, LCD displays, touchscreen displays, video (LCD computer monitors) and other devices are supported both at the base station or can be connected to remote modules.

HCS_C operation is managed with a simple but very powerful command language called HCS_C Xpress. It permits easy time or date control of any sensor or any action for any length of time. Random actuation (for example of house lighting while on vacation) is easy to do.

If you want to bring your house safety and management into the 21st century, HCS_C is the only system that brings all home control functions into one integrated system under your control!

Support for the original Circuit Cellar HCS2 is being maintained by William Maton and can be found here: http://www.wfms.org/hcs/ NOTE: If you are using an HCS2, consider adding the HCS Combo card to your setup! It is accessible via network string commands and should also be accessible using the Host network command, but I haven't tried it yet, too busy getting these cards shipped out!

Zeta Engineering HCS_C Status

6/28/2009: Uggh. Getting old sucks, a health issue I've been fighting for a while has taken a turn for the worse. HCS_C has had to take a back seat, although I've had fun at times working on bringing up LDI (LVDS Display Interface for LCDs) on the camera card, bringing up DDR, and working on the robot. Turns out I need IO that has bulletproof protection for H-Bridge motor driving, so I am now looking at an update of the HCS_C main board. Not sure what, yet...

5/9/2009: Well, this latest version looks pretty solid for ethernet and Insteon, what a long effort! I was fooled by having a wrong version of the compiler on the in-service HCS_C, so I was getting bogus Insteon operation. Now I can finally get back to the Insteon input testing and the camera board. The camera board is making slow progress--it's got the new DDR DRAM on it, and that is proving to be a difficult turn-on to get working. It is now reading correctly, but writes are not. Since images are sent from this board, I had to create a packet exchange method for HCSNet, that seems to be working well, but CRC isn't matching--probably a packet count mismatch.

Turns out HCS_C with imaging on the camera board, and in particular, the HCS_Xpress concurrent task language with module independent waits, is absolutely perfect for robotics. I'm building up a main board that will drive a wheeled robot that will patrol the house.

4/27/2009: Making progress. Found a couple of problems, one of which definitely explains one of the Insteon problems. I maintain a variable definitions file and an equivalant external definitions list in the hcs_xpress_int_utils file--but if these get out of sync with mismatched variable definitions, major problems occur--and this was the case for the Insteon UART service firmware. I separated out the definitions list to an hcs_xpress_vars file, hopefully that will make it easier to keep them both in sync. Better yet would be to set up classes for each of the IO devices, but I'm not going there for now. Once I fixed that, now it doesn't lock up when sending Insteon commands, and simple programs now drive Insteon correctly (don't know yet about Insteon receive). But my full in-service program does not drive Insteon correctly, so still some debugging to do. The new analyzer is in place, I'm watching for lockups on ethernet. Cross your fingers.

4/20/2009: Uh oh--nasty interaction bug between Ethernet and either Insteon interrupts or the WAIT capability--happens about once a day or so. I'm going to have to do a deep dive on this one. I brought back in the HCS_C analyzer into the HCS_C FPGA, and made it quite a bit better--you might recall a few years ago I removed the analyzer to make room for the video circuit, which needs RAM to store the character maps and the character array. But--the boot ROM is never used once boot-up happens! So, I get my cake and can eat it too--I kept the video, but used the boot ROM memory for analysis state memory once the HCS_C has booted up. I provided a bit that switches from boot ROM mode to analysis mode. Obviously, if you choose to use the analyzer now, it will wipe out the boot ROM contents, so a power cycle (reload from configuration ROM) will be required rather than pushing the reset button. But none of you should need to use the analyzer unless you encounter a firmware/hardware problem, so hopefully this wont be a problem.

One thing, though--you can't take a trace unless the boot_lock bit is turned off--and I realized that if the HCS_C were to go off in the weeds, the boot_lock bit address precedes the boot ROM content mapping, and thus explains why sometimes after a crash the HCS_C would not come up when pushing the reset button. I fixed this--now boot_lock can only be disabled with a specific register value, making the probability of a boot ROM wipeout substantially less. I'll keep you posted, but version 1.10 will not release until this problem is figured out.

4/13/2009: I've got the Insteon sensing working correctly now. I'm adding read capability into the compiler. The firmware will save away one message at a time (and ignore subsequent ones) until the events program recognizes it and resets the message. You can read the data in the string with the INSTEON(n) operand, where n is the nth byte in the string. In this way, you can get any information transmitted by an Insteon device, such as the transmitter and reciever address, the group number, status, or command 1 and command 2. You then can parse that data any way you like, for example, checking that the sensor sent an ON or OFF state by looking at the cmd1 byte (10th byte). You will have to do a light-switch or sensor All-link set to the Insteon PLM device in order for HCS_C to receive sensor information. I'm testing these bits (version 1.10) and will probably release them by the end of the week.

Something really interesting is coming down the pike for web page display: The ability to parametrize just about anything on an HTML page. The ^/<string>^ escape sequence does nothing! But if the <string> is encountered in a subsequent text string on the current web page, such as img height="20", the following number (the value 20) is used as a variable select, and the value of the selected variable is substituted. This will permit, for example, the web page to display a bar graph whose lengths are given by the value of the variable. I should have a demonstration on my web page shortly.

4/6/2009: I'm working on Insteon sensing. HCS_C supports output of Insteon commands, but receiving Insteon data seems to show a lot of garbage due to all the retransmission stuff that Insteon does. I'm going to work to see if I can filter all the junk.

3/16/2009: I'm back. I've been involved with some other projects for a while but now am back on HCS_C. I made a major improvement to the logging display with a new escape sequence called ^Lx,y^. This uses the current view_ptr and displays the yth log (standard) entry after view_ptr. The x specifies which log entries to show, with 0 indicating all log entries. It displays the standard log entry only, right now--date and time, the log tag, and the log computed value. I also added the capability of giving each log tag a 16 character name with the log(n) "NAME" function. I'll put up new bits shortly. You can see it in action at hcs-morrison.com/logfile.htm (yes, right now there's a whole bunch of DEN STAIR motion entries--a bug in the events code, I think).

1/2/2009: Oops! I just fount a bug in hcs-xpress! The conditional or function ("if (month = 4) or (month = 5) then") is broken. I fixed it and will put up an hcs_xpress update before too long. I'm trying out some ideas for how to implement callbacks--I haven't heard from anybody yet. Feel free to let me know what you need...