My Controlled Home

The MCU hardware is finished. It uses below components:

• Chenbro 19″ 2HE RM22300 casing
• Asus AT4NM10T motherboard
• 4GB of SO-DIM DDR3 -1066 RAM
• 2 Seagate 500GB harddisks
• A Sweex PS011 300W power supply
• Aerocool Coolpanel III 3 fan controller
• MS Windows 7 Professional 32bit

It looks funny, a fanless motherboard in a casing were 4 fans are running to keep it cool…

For that reason I placed the Coolpanel and have the 3 case fans controlled by sticking the temperature sensors on the CPU heatsink, the top harddisk and the power supply casing. The RPM’s of the fans reduced significantly and so the noise.

I will build a second set exactly like this to act as a storage device. That was the main reason for selecting this motherboard, it has 4 SATA connectors compared to 2 on most boards.

It is time to start building the network architecture since parts of my house will be finished soon. As mentioned, I have a single computer called the Master Control Unit (MCU) that does nothing else than monitor all attached devices and executes assigned actions based on triggers send by the attached devices.

The MCU is a computer placed in a 19″ rack that is located in the installation room of my house. In case maintenance is needed it is simple, I use Windows Remote Desktop to access the MCU or I go upstairs to the installation room, hookup a monitor, keyboard and mouse and work in that room. When I want to open the front gate this will not work, so I need a Remote Control Unit (RCU) that provides a nice User Interface and than tells the MCU what it needs to do. Any feedback from the MCU can than be displayed on the RCU. I guess there will be more than one RCU, I can imagine that I will have a larger display in my living room, a tablet when walking around in my house and a smart phone when I’m working outside. The MCU should therefor support multiple RCU’s, even at the same time.

The communication between a BCU and the MCU uses a very simple data structure as explained before. I already developed the code for the MCU using an UDP Socket, it might be an idea (or even wise) to develop the RCU’s as if they were a BCU with repect to communication. The risk might be that the data structure is not power or large enough for this, but it can be an option to enlarge the data size for RCU’s only and keep it smaller for BCU’s.

The first RCU is a TouchSmart 7320 All-in-One PC from HP, I will develop a simple remote control app based on above result and see how that works including the processing of logfile results.

We are making good progress in building our house. We are installing a lot of pipes and network cable so that in the future I can automate alomost everything you can dream of. The first items to work on is the heating and the doorbell. The basic driving electronics for the heating is ready, later I will add all kind of logic to it. Now the doorbell needs the basic works to make sure I can extend the functionallity in the future.

The problem we have is that we have 2 front doors and a front gate. So when a button is pressed we need to know at what location it was pressed. My basic idea is to have a doorbell that can play multiple tunes, each front door will have a doorbell installed and potentially we will place a doorbell in the horsebarn later. If somebody presses the button the local Door Bell Control Unit (DBCU) can play it’s assigned tune and inform the MCU that the button was pressed. The MCU can than instruct the other DBCU’s to play the same tune as the original door bell. The persons that hear the tune should than be teached which tune matches with which door.

There are some other tasks the DBCU should do as well:

• Drive the light that is placed over the front door
• Monitor a switch that indicated if the door is open or closed
• Interface with an IP camera

Instead of playing a tune it might be an option to speak out the location of the switch that was used to activate the bell. For example, speak out ‘front gate’. Than the persons do not need to match a tune to a location. The door bell that matches the door could very well play a tune which is perhaps nicer for the person standing in front of the door. To keep this option open the solution looks to be a small audio file player that can play various pre-recorded tunes or audio recordings.

A typical 5 second WAV-audio file uses approx 10kByte of memory. I would like to store 3 at least, but I guess I will use the audio function more when it is available. For example to indicate system warnings throughout the house. So 30kB of memory will not do. A solution might be to use a small SD-card, the benifit is that a PC can than be used to store the files on the card.

As a result, the micro controller must be able to understand a FAT16 format and the WAV audio format. Filenames can be kept simple, for example ‘Sound1.wav, Sound2.wav, Sound3.wav’. This idea is not new (as most idea’s…), the SOMO-14D Embedded Audio Module as supplied by 4D Systems does exactly what I’m looking for. A second alternative is the MOL-AU5121, it is a lot cheaper but not well documented like the SOMO-14D. Since this function is not a key function to the overall design of my home electronics I better save my time and buy a SOMO-14D and see how it works.

In order to get some volume with a relatively good sound an external amplifier will need to be used. The manual of the SOMO module gives a very simple setup using a LM386 amplifier, however I need two amplifiers. The second one is to support the two way audio function of the Panasonic BB-HCM531 IP camera that I will place next to the doorbell button. In this case it makes more sense to use a stereo amplifier like the TPA6021. In that case the left channel can be used for the SOMO-14D and the right channel for the IP camera.

Using above setup I have a lot of functionallity and flexability. When a visitor arrives, he/she pushes the ‘bell’ button. This triggers the DBCU which send a message to the MCU that somebody pushed the button. It also plays the audio file that is set by default and it switches on the light (if needed) while the MCU sends a play command to the other installed DBCU using the same audio file ID that matches to triggering DBCU. The MCU also sends messages to a or any of the available remote control units (RCU), the RCU can than open a dialog that connect to the camera and open the two way audio support allowing me to see and talk to the visitor.

The camera offers two inputs and one output. It makes sense to connect all of them to the DBCU using opto-couplers. It seems these controls can be used as a motion detector and auto-record mode, I’m not sure if I will use them but I can only decide that in the future when the interfaces are available.

In a big house climat control is a bit more complex than in a small house. In a typical situation there is a single heating unit which is switched on or off using a thermostat that is placed in the main living room. All other heaters in (for example) bedrooms are switched on as welle when the living room is getting colder. A possible solution is to apply thermostatic valves on each heater, but they only cut off the warm water supply when it get’s to hot, when it is too cold, it can not request war water from the central heating unit.

I plan to have a thermostat in each room that are connected in parallel to the central heating unit, when one  (or more) rooms need warm water they can all request this from the central heater. To cut off the warm water supply when a room reaches it’s temperature, an electrical valve is placed in the supply line so that each room can control it’s own supply.

If a door or window is opened, the room is connected to an area which can either have a lower temperature setting or were the temperature is actually a lot colder (outside). In that case the thermostat should automaticly change it’s temperature setting to the lowest value of the two rooms or even decide to cut off the warm water supply at all. In order to detect open doors and windows each door or window will be equiped with a magnetic read switch.

Secondly, if a room is not occupied in ‘x’ minutes, the temperature can also be reduced. Using motion sensors that are placed all over the house the MCU can reduce the temperature setting of the thermostat that controls that area.

Both the switches and the motion sensors allow me to build a very easy alarm system as well, but that is for later implementation.

There are 8 area’s which will have it’s own thermostat:

• Main living room one and two
• Kitchen
• Bedroom one, two and three
• Bathroom one and two

The connecting area is a hallway and stairway, this area is controlled by thermostatic valves and a seperate temperature sensor that can activate the central heater as well.

Each of the 8 area’s have an electrical valve, 5 of them close to the central heater and 3 of them in a seperate area. The valve itself is operated by a 230V magnetic coil, since the distance between the valve and the thermostat can be up to 20 m it is not wise to switch this signal in the thermostat. It might be an option to build a BCU that controls these 5 valves (or 3) and have the MCU request the temperature from all 8 thermostats BCU’s and than tell the valve BCU what to do. However, when the MCU is off-line you still want heating… A better solution is to use two low voltage signal wires that are routed between the BCU and the central heating unit like any normal solution. In this case this means there are 8 signal pairs were each signal pair should drive a relay that activates the coil and at the same time starts the central heater.

The MCU can always request the status and temperature from the various thermostats BCU, it can combine this with the status of doors and windows and than give a command to each thermostats to change it’s reference temperature. In theory it can also give a command to acivate or de-active the valve connect to the thermostat. This migh come in handy during maintenance are to cycle the valve every day to prevent it from sticking when not used for a long time during the summer.

Target is to keep the valve-logic as simple as possible, so not implemented as a BCU with netwerk access. Initially I will use standard thermostats and they must be able to drive the hardware, when I have more time I will design a new thermostat that holds a BCU and monitors the door to which it is closely mounted. Than more logic can be applied. Also on the central heater side, the valve logic should short a signal like a normal thermostat. The heater I selected is a Remeha Quinta Pro 45, this heater has some 0-10V IO’s that I would like to control, for example, it can output the usage percentage of the burner. I will add a BCU to the central heater which can than send info to the main MCU to add more logic, for example delay heating of an area before a new one get’s warm water to optimize burner performance. But this is for later, cold evenings to design, for now, it should simply work.

Below a simple overview of the valve logic. As mentioned, there are two of them which need to be connected in series.

The relay can be driven using a C94301 relay I used many times before. This 5V relay uses a 30mA switching current and has two poles that switch between two contacts. The first switch can be used to drive the relay and the second switch to drive the central heater keeping the driving electronics very simple. The total power consumption would than be 5*30mA=150mA at 5V or 0.75W allowing me to use a very simple 230VAC/5VDC power supply that can be soldered directly on the PCB, something like the TMLM04105 leaving enough power to drive an LED next to the relay indicating the current state for each valve. As input electronics a simple transistor setup using the BC547B will do just fine.

As for housing, there will 5 installation tubes coming from the thermostats, 5 power cords going to the valves, a signal wire to the central heater, an installation tube from the 3-valve control box and a power cord for the power supply. So many connections taking up a lot of space, the board itself will be very small compared to the box. Using a clear lid prevents the need of making holes for the LED’s and it looks more high-tech… The TK-PS 2518 box will do just fine.

The idea is to re-use the Gate BCU and leave some components like the wireless receiver of the board. I bought two Sea Half Tank hydrolic swing gate openers that offer a serious amount of pushing force. The controller board that is supplied with it can drive two of these openers, the connections are very simulair to those of the Genius motor drivers using for the gate.

• Open-close: This is a normally open connection between pin 5 and 2. When closed for a short period, the gate opens or closes depending the current state.
• Stop: This is a normally closed connection between pin 3 and 2. When opened it stops the current open or close action.
• FSW-OP: This is a normally closed connection between pin 6 and 2. IR sensors can be connected to this input, for this pin 10 (24V) and pin 2 (Ground) can be used to power the sensors. 
• FSW-CL: The same as FSW-OP but than for closing between pin 7 and 2. Since I will not be using detection during closing this can be hard wired closed.

The controller does not support a opened- and closed- switch. Instead it uses timers to drive the hydrolic pumps and assumes the doors are mechanically stopped. They advice to keep the pumps running for a little while longer when the doors are closed so that the maximum ‘holding’ pressure is reached to keep the doors closed. It can also drive an electric lock if the holding pressure is not enough.

I would like to know when the doors are closed, this can easily be made using two magnetic alarm switches that are mounted on the top side of the doors. Open is not needed, or actually fully open is not needed, when the close sensors report open it is good enough. All I want to know is when I start a close cycle during a storm the doors are closed within a specific time. If not, I want to be notified by the MCU.

So, the conclusion is very possitive, I can use two times the same hardware for the BCU, the software of course will be different.

The gates and the engines for the gate arrived.

Each section of the gate will be driven by a seperate engine, I selected the Genius Falcon 8C for this. This engine has an integrated control unit, this makes driving the gate a lot easier than my previously defined block diagram. The whole detection of sensors and engine driving is taken care of by this unit, all the BCU needs to do is trigger the open/close input. Well, I do want access to the IR- and limit- and safety-switches so I can add some logic to the gate but this makes it more of an interface issue than of a driving issue.

The Falcon has a couple of connection using a 12 pins terminal block:

• Open-close: This is a normally open connection between pin 1 and 7/8. When closed for a short period, the gate opens or closes depending the current state.
• Stop: This is a normally closed connection between pin 5 and 7/8. When opened it stops the current open or close action.
• Edge: This is a normally closed connection between pin 6 and 7/8. All edge safety switches need to be connected in series between these two pins. If one (or more) edge switch opens, the current action is stopped and reversed for 2 seconds.
• FSW-OP: This is a current sensing input between pin 11 (current source) and pin 3. IR sensors can be connected to this input, for this pin 9/10 (24V) and pin 7/8 (Ground) can be used to power the sensors. The connection between pin 11 and 3 should normally be closed and must be opened when an object is detected. Since I will not be using detection during opening this can be hard wired closed.
• FSW-CL: The same as FSW-OP but than for closing between pin 11 and 4. I will have two IR sensors between the pillars, they must be placed in series so that the closing motion is stopped when an object is detected.

A second 3 pin connector is available which holds two limit switches. These are normally closed and opened when the gate is fully open or fully closed. These signals are not to be used ‘external’, but I want access to them so the BCU can take action based on it status.

When a sensor is IR sensor or an edge switch is triggered, the Falcon does not take any action when the object is removed. For this reason the BCU needs access to these sensors as well so it can take the correct action by opening or closing the gate. Also, when an edge switch is detected, it is a good option that the MCU sends an allert message to me to check what the rootcause was.

The relays used in the IR- sensors and the edge switches can not be connected in parallel to my BCU and the Falcon, this would  result in signal loops between the two systems which are electrically not connected. If the relays were double switch types it would be OK, but for the edge switches this will not work. So a small board needs to be placed in between the sensors and the Falcon which basicly ‘doubles’ all the signals. This could also be integrated on the BCU board, but there is an advantage to use a seperate board. The BCU for the garage doors  will need the same BCU but it might need a different interface board between the sensors and the control logic (which is also integrated) of those engines. By using two seperate interface boards I can keep the BCU (which is more complex) the same.

The interface board can be powered by the engine itself, there is a 24V power supply available. The spec does not state how much current it can supply, but it can drive a 3W flash light to indicate gate movement. Since I will not be using a flash light I can safely assume I can use the 3W for my interface board, so 125mA at 24V.

The IR-sensors use a relay that is normally open. When the power supply is switched on, the relay activates so it is closed indicating to the Falcon board no object is detected. Below the simplified schematic of how the two IR sensors are connected to the Falcon.

The relays of the IR-sensors can be used to drive a new relay that has two switches. In that case one switch can be used for the Falcon and the second one for the BCU. This results in below simplified schematic:

The same principle can be used for the edge switches:

For the limit switches it is a bit different since they are integrated in the housing of the Falcon and not to be connected externally. Luckily the switches are connected to the board using a 3 pin Molex connector. When measuring the signals on the board it seems the two switches are connected to eachother and tied to ground while the two other contacts connect a pull-up resistor to ground. Since I do not know what the current rating is of the switches used and I’m not sure they can handle the current spikes of relays being activated the best option is to drive transistors with them as indicated in below schematic:

All sensors are now available to the BCU as well, since this will be placed on an additional board it might make sense to add an extra relay that does nothing else that switch on when the power is available in the Falcon. In that case the BCU can detect if the Falcon is powered on and the add-on board is functional.

The rest of the functions for the gate are:

• The wireless receiver
• 4 keypads
• 1 relay to control the lighting around the gate
• 2 IR-switches to detect if objects are in front of/behind the gate

And finally, the BCU should be re-usable for the garage doors, so I will first need to do a study on what is needed for the garage as well before drafting the schematic.

The keypad hardware is fully functional, the next step is to develop the AVR code so it can be connected to the frontgate and garage door.

The keypad will act as an IIC slave allowing me to connect 4 of them to the BCU of the main gate and 1 to the BCU of the garare doors. As a base slave address I will use 0b11000xx0 which is used for some sort of TV chip so not lickely to be used in the same design as my keypad. The sub-address is selected by the two jumpers on the board, these jumpers must be hard-wired using a piece of wire, if a headerstrip would be used the RJ45 plug can not be inserted in the connector anymore.

The keypad scans the key in an endless loop by calling the function ScanKeyPad, this function drives the rows low in the correct order and reads the columns to detect if a key is pressed. It basicly maps all the keys as a 16-bit pattern and than compares this pattern with defined patterns that have 1 key pressed. If the pattern matches, the key is returned as an usigned char that ranges between 0 and 11. The 0..9 of course correspond with keys 0..9, 10 is for the * and 11 is for the # key. If no or more than one key is pressed, the value 0xFF is returned.

When a key is detected, the code waits for 40ms usign the Wait function, this function first sets a counter called Timer and than waits until the value of Timer is 0. The part that decreases the value of Timer is an ISR coupled to a hardware timer 0 that is set to trigger every 10ms. So, as an example, in order to wait 40ms, the call Wait (4) is made and after 40ms the value of Timer is 0 again. After the 40ms the keypad is scanned again, if the same key is found as before than it is considered to be stable. The key is than stored in a buffer called KeyBuffer that can hold upto 5 keys. The first 4 keys are the pincode, the 5th key is optional and can be used by the MCU to (for example) indiccate if the gate must remain open until further notice.

When the key is stored, the Beep function is called. This function enables the PWM outputs on OC1A and OC1B which are set to a frequency of 4Khz. OC1B is set to be the inverse of OC1A which results in an AC driving of the buzzer using a peek-peek voltage of 2*3.3V. When the PWM outputs are enabled, the function Wait is called before the PWM outputs are disabled again and all keys are relased again.

The system than sets the value of Time to 1.5sec (150 units of 10ms) using the SetTimer function before waiting until the next key is pressed. This is done to check if keys are pressed quickly after eachother, if not, than any previous key entry should be erased from the KeyBuffer before the new key is stored. When a next key is detected and the value of Timer is larger than 0 the key is pressed within 1.5 seconds, if the value of Timer is 0 than the key is pressed at least 1.5 seconds after the previous key and (as a result) this key must be seen as the first key of a new code.

After 4 keys are detected, the system scans the keypad for 1.5 seconds (so until the value of Timer is 0). If a key is detected in this period it is stored in the 5th location of the KeyBuffer, if no key is detected in this period the 5th location is set to 0xFF before reporting the entry of a valid code to the BCU by pulling the /INT line to ground. A bit is set in the SystemStatus variable to indicate a code has been entered and further scanning of the keypad is blocked until the code has been read by the BCU.

The BCU can read the code by reading a byte from the keypad using IIC. This will trigger the ISR linked to the TWI module of the keypad, in this ISR the correct action is taken based on the value of the TWSR register. The keypad always return the value of SystemStatus as the first byte when a start condition for read is found. The BCU can than stop reading but this will not clear the keypad for scanning for new key. Only when 6 bytes (so SystemStatus and 5 keys) are read, the keypad clears the bit in the SystemStatus, releases the /INT signal and a new code can be entered.

The BCU can also write data to the keypad, for example to switch the backlight on and off. For this a command and a value are packed in a single byte, the high nibble is the command and the low nibble contains the data. At this moment only one command is defined for controlling the backlight but further commands can easily be added.

The latest version of the software can be downloaded here.

The hardware design of the keypad is finished, you can download the design here.

The connection to the BCU is done using the RJ45 connector, most wires will be used for power. The keypad is a I2C slave, the SDA and SCL signals are used for communication and jumpers JP1 and JP2 can be used for selecting up to 4 keypads connected to a single BCU. J3 connects to the keypad S.12150.241, there are 4 columns with a 10k pull-up resistor and 4 rows that can be driven by the ATmega32. The LED’s that are placed in the keys are all conencted together and can be driving using an PWM output in combination with the FET Q1. This will allow me to adjust the brightness of the backlight, not sure if I will do so, but at least I’m prepared.

There is a small piezo buzzer EFM-250D placed on the board that is driven using two PWM outputs. Since the controller runs at 3.3V the amount of noise it can make might be limited, by driving it using two PWM’s that are inverted compared to eachother the piezo can be driven in an AC mode, so it thinks it is driven by a 6.6V making a lot more noise.

The connector J4 is there to connect a big ‘call’ button that is only used in one keypad outside the gate. The LED that is inside this button is driven by the PNP transistor Q2, using this construction reduces the amount of wires to the button from 4 to 3.

The board is a round board of 65mm in diameter so it can fit into a standard installation box. The layout is send to PCB Pool for production, I expect them to arrive on my desk in two weeks from now.

I’m strugeling a bit with the design for the numeric keypad that will be used for the garage doros and for the gate. Not so much from how it should work but more from a chip selection. In the past (pre-microcontrollers) there were keypad encoder chips like the 74C922 or 74C923 from FairChild which encode 16 or 20 keys, take care of the debouncing and generate an interrupt when a valid key has been detected. These chips are no longer commonly available, when you can still buy them they cost more than a small micro.

With respect to the micro, I will use the ATMEGA32L-8AU as the ‘standard’ controller which costs 3.84 EUR and offers many IO pins and interfaces. I admit, using this micro for encoding a keyboard is an overkill. I can safe 1 EUR by selecting a smaller one, but from a logistic point of view I will loose money since I only need 3 keypads.

From an interconnection point of view, I will probably use network cable since the connectors are cheap, I have lots of cable available and installation is easy. That means I have 8 wires available. The wires can each have a current of 600mA, so 2 can be used for the power lines, 2 for the backlighting, 1 for generating a keypressed interrupt and 1 for the serial data leaving 2 wires free allowing 2 wires for the positive power supply and 2 for the ground.

If we than have a relatively large micro available, than it might make sense to add some more logic in the keyboard. For example, instead of reporting every keypress only report a valid entry which exists out of 4 keys pressed within a certain time. In that case the BCU is only interrupted when it actually needs to do something, it has to read the string packed into two bytes and send this to the MCU so it gets instructions what to do based on that string. Since I2C is used, the BCU can also write data to the keyboard and, for example, enable the backlight. Than the 2 backlight wires can be used for power supply again making it more robust.

When writing this down, I realized that it might be a good idea to extend the 4 key pincode with an optional 5th key. Sometimes it would be nice to keep the gate or garage doors open, for example when we are loading or unloading materials. When you than enter a pincode and within ‘x’ ms press the * or # key this could be used for that functionallity. If you do not press the 5th key, that means open and close when passed. The MCU can still override the ‘always open’ function, after a specific time, If the front gate is left open by accident, it is nice that the MCU closes it when there is no activity detected for 30 minutes (for example).

Since we work with horses it might make sense to have two extra keypads at the front gate. When you sit in a car the typical height for the keypad is approx 70cm from the ground. When you sit on a hore this can quickly go up to 170cm making it impossible to open the gate since the keypad is mounted to low. Since I2C is used they can all be connected in parallel (4 of them) for the frontgate and assign different adresses for each of them. The interrupt can be shared but that would require polling which keypad has reported the interrupt, if IO pins are available on the BCU than using seperate interrupt lines make the software more easy.

Next to scanning the numeric keypad it must also be possible to connect a single ‘call’ button to the controller. This will only be used for the lower keypad on the outside of the gate so that visitors can press this button to indicate they want to get in.

The garage doors will use electric motors to open and close the doors. The remote control that is part of the gate is used to remotely trigger the garage doors as well. As mentioned there will be three buttons on the remote control. Pressing A will only activate the gate, pressing B will only activate the garage, pressing C will activate both. Not directly since the remote control is part of the gate BCU, so when button B or C is pressed, the MCU will respond by sending commands to the garage BCU as well.

The garage doors are very large: 1.6m wide per door and 3.2m high. The doors swing inwards to open the garage, not the most optimal direction but cosmeticly the most beautifull. Since the garage is 10x8m there is some room to spare for the doors. Below a schematic overview.

In order to manually open the doors there will be a button on the inside and a numeric keypad on the outside. The IR beams provide ‘some’ level op protection the stops closing the doors when they are triggered. These sensors will be connected to the motor control that is supplied together wiht the motors, they will also be connected tp the BCU so it can report the interrupt to the MCU.

The motors are hydrolic half tank pistons from Sea that deliver an impressive 6400N pressure. Reason for selecting these motors is that the doors face the direction of the wind, when there is a storm the motors need to keep the doors closed or must be able to close the doors pushing into the wind with a large surface.

The BCU of the gate and the garage will look very simular. Main difference is the wireless receiver on the gate, this uses a serial port for communication. Since the keypad is located at a distance from the bCU (several meters) the optimal architecture is to place the smallest AVR controller on the keypad and when it detects a keypress send this using a serial interface to the BCU. The UART is used by the wireless receiver, the SPI by the network controller so this leaves the I2C interface. In theory also the SPI can be used, but I want to prevent connecting long wires to the which might interfear with the network communication.

First step is to select and build the keypad. It must be waterproof and backlighted, possible candidates are the S.12150.241 from EAO or the MCAK207NSSLWPMM. The first one can be build on top of a surface, the second one is placed though a hole in the housing. The first one feels more waterproof and cosmeticly nicer, so that’s the one I will use. The keys are placed in a matric, so it requires a clasic ‘drive a row and read the columns’ approach.