All About H.A.L.

What is H.A.L.?

H.A.L. is my first attempt at home automation. It's a system of hardware and software I designed that lets me monitor and/or control parts of my house from the Web.

What does H.A.L. stand for?

I wasn't sure what to name my Home Automation project. I knew it should probably start it with H.A., but wasn't sure how to end it. It shortly occurred to me that it should, naturally, be called HAL (after the computer in 2001). Now, I just needed to figure out what the 'L' should stand for. I soon decided that it didn't matter what the L stood for, since I was going to call it HAL anyway, so I decided that HAL stood for Home Automation Lollipop.

How does it work?

H.A.L. is made up of three major parts: One Master Pod, several Slave Pods, and the Logging Software.

I'll start with the easiest part of the system, the Slave Pods. The slave pods are small electronic boards which are sprinkled around my house, each about the size of a pack of cards. The pod's main function is to measure something (temperature, etc), and relay that information (via radio) to whomever asks for it. Each pod has sensors, a microprocessor, and a radio transceiver. The pods are flexible, in that I can attach any kind of sensor I want. Right now, I've got sensors to measure temperature, pressure, humidity, etc. But I could also add a sensor to monitor the floor in my basement for water leaks, another to check if my front door is opened, etc. The microprocessor is the brain of the pod.  Its job is to measure the readings from the sensors and store them.  Finally, there's the radio transceiver. It allows the pod to communicate with the Master Pod...

The Master Pod (shown at the top of the page) is the heart of the system. This pod's job is to query the slave pods to get their readings. For example, it could periodically ask Pod #74 (located in the basement) to see if there's water on the floor. It could ask #22 if anyone opened the garage door, etc. Simply put, its job is to gather data from all the slave pods, making it available for the Logging Software.

The Logging Software runs on my Linux Server. It talks directly to the Master Pod, asking it for information from all of the sensors. It saves this data to the hard drive, and also updates the Web pages, charts, etc.

Can you control stuff too?

Almost. Right now, I only have sensors connected to the pods, so I can't really control stuff. However, I can send data to and from the pods, so there's no reason I can't send "action" commands to them. My plan is to set up a Web interface to allow me to control parts of my house remotely. I could, for example, turn up my thermostat before I leave from work.

Can you give me more technical details?

Sure. Here you go:

• Master Pod
  • Processor: Microchip PIC18F452.
    • ROM: 32KB
    • RAM: 1.5KB
    • Clock Speed: 40MHz max.  (Currently running at 20MHz.)
    • I/O Pins: 34
  • Transceiver: Linx Technologies TR-916-SC
    • Frequency: 916.48 MHz
    • Data Rate: 19.2 Kbps
    • Range: Approximately 100'
  • Power Source
    • 7-12V DC
    • ~300 mA
• Slave Pods
  • Processor: Microchip PIC16F877A.
    • ROM: 8K x 14
    • RAM: 368 Bytes
    • Clock Speed: 20MHz
    • I/O Pins: 33
  • Power Source
    • 7-12V DC
    • ~50 mA
• Protocol
  • Since all pods share the same RF channel, only one pod can talk at a time.
  • All messages are initiated by the Master Pod, and must be acknowledged by the appropriate slave pod.
  • Because radio signals can be unreliable, all messages include a checksum to make sure that none of the data was corrupted. If the checksum doesn't match, the receiver will drop (ignore) the message.
  • If the Master Pod doesn't receive a valid response to a message, it will retransmit the original message. (i.e., it will try again.)
  • All messages are 16 bytes long, in the following format:

    Byte Num	Name	Description
    0	Synch Byte	Alternating pattern of 0's and 1's (0xaa), used to get the RF transceivers synchronized.
    1	Start Of Message	The letter 's' (0x73). The receivers look for this byte so they know where messages begin (and end).
    2-3	Destination Id	The ID of the pod receiving the message. Up to 65,000 pods can be supported. (Naturally, there's little chance that I'll ever need anywhere near this many pods, but I like expandable systems. It's easy to add room for growth in the beginning, rather than having to hack it in later. Besides, if you don't plan for the future, you may live to regret it. Bill Gates, for example, once said, "640K ought to be enough for anybody". )
    4-5	Source Id	The ID of the pod sending the message.
    6-7	Action Code	The command type, i.e., "Read a sensor", "Turn on the switch", etc.
    8-9	Address	This specifies which sensor (within that pod) to read / write.
    10-11	Data	The sensor's reading is stored here. (First 16 bits.)
    12-13	DataAux	I added this in case a reading needs to be longer than 16 bits.
    14	Reserved	Reserved for future use
    15	Checksum	Used to make sure the message was properly received. It's the sum of all bytes, modulo 256.

• Sensors
  • Temperature: National LM34 Precision Faherenheit Temperature Sensor
  • Pressure: Motorola MPX4115AP
  • Relative Humidity: Honeywell HIH-3610

Will H.A.L. ever go berzerk and sieze control of the entire house?

Quite possibly.

Does H.A.L. have a voice?

Not yet. But when he does, he will sound like Pierce Brosnan, at the request of my fiancee.

Any more questions, comments, or thoughts? Feel free to ask me a question.

Back