Smart Home Automation Part I - C-Bus [LINUX]

Although there are several well-known protocols for appliance control, X10 is the best known by a long shot with members of the general public being aware of it, primarily because of its low barrier to entry. Within the HA community, however, it is the ownership of a Clipsal C-Bus system, which becomes the goal.

Smart Home Automation Part I - C-Bus [LINUX]

About C-Bus

The C-Bus system was developed by an Australian company, Clipsal, as a means of controlling various light systems remotely. Clipsal’s original intention wasn’t in the field of HA but in stadium lighting rigs and commercial arena and conference centers. This meant the system had to support much longer cable runs than would be utilized in a home setup and a larger address space. It succeeded on both counts, with cable lengths of 1km being possible with 100 appliances on a subnet—with each subnet being capable of connections to another six through basic bridges or considerably more through the now available Ethernet bridges.

Differences Between X10 and C-Bus

C-Bus’s primary difference is with its installation. Although X10 transmits its data along existing power cables, C-Bus devices are controlled by utilizing a proprietary protocol that travels along a separate Cat- 5 cable. Consequently, such installations can be carried out only by qualified Clipsal-approved staff, pushing up the initial cost. However, once all the cables have been laid, one achieves the benefit of a near-zero level of maintenance since the interconnects will always exist and remain future-proof. It also provides two-way communication between the switch and a computer, making it trivial to query the state of the light dimmer or appliance. Furthermore, since the signal speed is not limited by the zerocrossings in the power line, all light changes happen instantaneously—a benefit that only those with many years of experience with X10 systems can truly appreciate.

To lower this initial overhead, Clipsal has recently introduced a wireless version of C-Bus, which eliminates the need for costly installations, so it is this subset of devices on which I’ll concentrate. This optionally supports 128-bit encryption of its data stream, making it more secure than an (unfiltered) X10 wireless solution, although it’s still hackable by the determined. Its wireless range is no better than the RF-X10 combinations covered previously, with a 5 to 20 meter range according to material.

Unfortunately, there is a maximum of 30 devices on a C-Bus wireless subnet, making it less capable than an X10 system using two house codes. The generally adopted approach to C-Bus installations is that a wired version is used for the initial house configuration, with wireless being added later as a cheap upgrade path.

For the geek, the primary difference is in the software because the protocol is closed, making Linux tools impossible. To reclaim this market, Clipsal has released an RPM containing a binary-only driver that is available for zero cost on its website.

Note 

A Red Hat package manager (RPM) can be utilized on non–Red Hat platforms such as SUSE or converted using tools such as Alien. The biggest problem with drivers packaged in this way, however, is its level of compatibility with the Linux kernel. Any change in the driver API, or similar breakage between kernel version numbers, will render the driver (and therefore your C-Bus system) useless. In these situations, when there is no more open solution available, it is always best to keep a low-level legacy system available and be prepared to migrate other software away from the box when necessary.

Unlike X10, each C-Bus device contains a microprocessor that makes it possible to control other devices remotely, without a computer. This is provided by switching the device into one of its five modes, which break down roughly as follows:

• Normal, stand-alone, switch
• Basic peer-to-peer switch control
• Networked switch control
• Networked switch control, with remote
• Interfacing with a wired C-Bus install

The adscititious computer is of benefit to smaller HA installations and those concerned about complex lighting UI. But for those of us intending to control other devices, the inclusion of a PC is not an issue.

Devices

Like X10 devices, C-Bus has the ability to dim lights and control appliances that are attached to it. Where they differ is the ability of a C-Bus light switch to control one or more other devices straight out of the box and with minimal on-device configuration.

Note 

I’ll consider only the wireless devices here, for the reasons given previously.

Controlling Lights

There are two designs of light switch, Neo and Saturn, which fall in the 5850 and 5880 product ranges, respectively, and differ by their decorative styles only, although within each group you have the choice of two-, four-, six-, and eight-button versions. They are always paired, with the first two buttons controlling the dim function of the connected lightbulb. Each subsequent pair is required to transmit the button press information (wireless) to another device, or devices. Because of the built-in microcontroller, these switches can be configured as a dimmer switch, an on/off pair, a remote trigger, or a scene trigger (the latter being the C-Bus term for macro programming, where several state changes can occur on several devices at the same time). Scene programming can also occur through the C-Bus Toolkit Software, although this is currently available only for Microsoft Windows.

There are several devices in each family, capable of various support loads and characteristics, but generally speaking a C-Bus dimmer will support incandescent and halogen lamps between 25W to 500W (up to 2A), along with fan motors (up to 2A).

These two series also provide basic switch units. These appear the same as their lamp-controlling counterparts, except that they lack the dim functionality. By way of compensation, they can support a much greater range of devices (up to 2KW, and 8A in places) including fluorescent lights.

Note

There appear to be no in-wall units for sale, meaning you cannot use wireless C-Bus electronics with your own style of face plate.

Controlling Appliances

Like X10, C-Bus provides an appliance module that plugs into the wall and controls the flow of current to its corresponding socket. These are known as the 5812 series plug adapters and look like their X10 counterparts, with the exception that they too support dimming and switch versions.

Since every C-Bus device includes a microcontroller and the C-Bus protocol supports the remote programming of other devices, any of the light switches mentioned earlier can also be used to control an appliance switch by programming an “association” on the switch, equivalent to a Linux symbolic link.

Controllers

The Series Wireless remote control 5888 is the main device here. It is an RF transmitter (operating at 433.92MHz) supporting ten devices up to 70 meters away (although 25 is more likely inside a building).

Because of the unified design of all C-Bus modules, it is technically possible to control more than the allotted ten devices by using the remote to control one switch, which in turn controls another two through the use of a scene. Furthermore, no RF gateway is required to use this remote, since the C-Bus wireless network is already operating on RF. This also means that multiple remotes can control any individual device, and any individual button can control multiple devices. Like X10, it also supports an “all off” message.

Gateways

With so much emphasis on the wireless network, it is sometimes necessary to revert to wires. This is where the Wireless Gateway C-Bus 5800 Series comes in. This is a necessary feature and the only way that the wired and wireless versions of C-Bus can be connected together. Also, through the use of software such as C-Bus Toolkit, it can be connected to a computer for remote, sequenced, and intelligent control. Consequently, this device is also necessary for a wireless-only network that needs to feature PC control since the 802.11 wireless protocol used by commercial routers is not suitable as a C-Bus wireless gateway.

Networked Devices

Although X10 and C-Bus both provide a good means of sending simple controls to simple devices, more complex communication requires something better. More specifically, it requires something with more bandwidth. When the command is “play this song,” it needs significantly more bandwidth. The most accessible way of supplying this is through a local Ethernet network, because it can send commands and data at high speeds without the distance limitations of USB, RS-232, or parallel cables. And unlike X10, two-way communication is provided for free as part of the specification.

Ethernet Devices

There are many devices that support communication through Ethernet, either to control it or to supply it with data. Some can work on their own without additional hardware, such as personal video recorders (PVRs) and media enclosures. Both consist of a method of storing the media and the technology for playback. Others require a server to supply it with data. The functionality of the device, and its use within an automated home, is always improved by utilizing networked capabilities. This means you will need a server, of some kind, for most future appliances. This elicits the distinction of two necessary parts—a front end and a back end—connected by a local area network, be it wired or wireless.

The front end, or head unit, will generally consist of a device connected to a nearby HiFi or TV in order to play media located on a physically remote machine. Because such a unit is placed in the living room or bedroom, it should be small, silent, and attractive. Preferably, it should also be fairly cheap, because one front-end unit is needed for every room in the house that wants to participate in streamed media.

The back end, by contrast, is stored away from the main living areas (since it’s generally a big PC with a noisy fan) but able to supply media streams to all the head units within the house via the network.

I’ll cover various media-oriented head units in Chapter 3, although most of those shown could be re-created with a Linux machine running the appropriate software. However, the power usage, noise, and cost will generally be larger than a custom-built embedded device, even though many of those devices may be running Linux themselves! To connect the units, however, you need to know how to set up a network.

Networking Primer

To best utilize the devices here, you will need to configure a Linux machine as a suitable server. Most computer science books will begin their networking section by describing the OSI seven-layer model of networking...I won’t! Instead, you’ll learn only the necessary, practical steps of providing and configuring a suitable home network for automation.

Note

Each Linux example here, and throughout the book, is based around Debian and the packages within it. This is not advocacy on my part, merely practicality, because it’s what I use. Some distributions may place the files in slightly different places or have slightly different names, but the principles are always the same, and the equivalents are easy to find.

Concepts

A home network is a way for each computer in the house to share a set of common resources such as printers, scanners, and storage space. In this sense, it’s very much like an office network. Where the home differs is in the level of technology and, consequently, the expertise needed to run it. One of the main bugbears in office IT systems is the issue of security. With a home network, the relationships between the people using it are very much different, and social mores are brought to bear.

The standard network configuration has two parts—internal and external. The internal part is a network that connects all the house computers together, along with their peripherals, and makes them invisible to the outside world. These devices may be networked together through cables or wireless.

The external network is everything else! The big, wide Internet is generally unavailable the computers at home; it is available only by connecting to an ISP through a modem, broadband connection, 3G card, or similar device.

To connect these two sides of the network together, you need a router. Sometimes the router is a small box that comes as part of your DSL/cable/broadband package and automatically separates the internal and external traffic. Sometimes you’ll need to buy one. They have one RJ-45 socket carrying the external network traffic, into which you plug the network cable from the broadband modem, and one or more outputs to the internal network.

Alternatively, you can use a PC with two network cards—one configured to talk to the external network and one for the internal. If you have a 3G card, then this acts like your externally configured network card.

With the router existing in both internal and external networks, it is able to automatically keep both sets of traffic separate and block any data or software you don’t want moving between the two. Most routers are configured, by default, to allow all outgoing traffic but block all incoming traffic, except those on specific ports. The port is the route by which traffic protocols flow and is dereferenced by a number.

All web pages, for example, are requested on port 80. So if your router is blocking incoming traffic on port 80, you won’t be able to access your internal web server from outside your home’s internal network.

Depending on the number of machines on your network, you might also need a switch that provides additional network sockets, into which you can plug more computers. Although it is unlikely that many people will fill eight sockets with computers, it is not uncommon to have noncomputer devices that also use Ethernet to transmit data, thereby exhausting the available sockets.

Addressing

Every device on the network must have a unique address. There are two current forms of addressing, IPv4 and IPv6. IPv4 was the original form of describing addresses by means of a dotted quad, such as 89.16.172.66, and is used by virtually every machine and home device on the planet. IPv6 was introduced in 1998 by the Internet Engineering Task Force to overcome the various problems with IPv4, such as address exhaustion. However, its adoption is less than widespread, and many of the small, homeoriented devices do not use it, so I’ll be concentrating on IPv4.

For a machine to have an address, it must be given one, either by a human or by a suitably configured computer. It cannot randomly generate one in case the address conflicts with another machine on the network or is one of the reserved addresses, such as 127.0.0.1. All the networked machines in the home should exist within a specific range of addresses, known as a subnet, and should be assigned to one of the private address ranges provided by the IPv4 specification. This not only stops conflicts with other existing sites on the Internet but also ensures the data within these networks is secure and invisible to machines outside the network, because all routers, switches, and gateways do not recommunicate any traffic with a private address range outside the local network. These private address ranges are 10.x.x.x,8 172.16-31.x.x, and 192.168.x.x, where x can mean any value between 0 and 255. For the purposes of demonstration, I will assign my subnet to the 192.168.1.x range, giving me 2549 possible devices on the network. Most people use this for private networks because nearly all the routers sold for the home allocate addresses within this range. Also, most questions found on the various Internet forums will probably have answers detailed using the same addresses as you have.

Now knowing the address range of your network, you have to consider the individual addresses. The first one to assign is the router, which usually earns the 192.168.1.1 designation,10 followed by the Linux server, which I will assign 192.168.1.2.

Caution

Configuring properties such as IP addresses requires you to be logged in as root, so tread carefully!

You can provide a Linux machine a static address either by using the tools in your desktop GUI or by configuring the /etc/network/interfaces file directly:

• auto eth1
• iface eth1 inet static
• address 192.168.1.2
• netmask 255.255.0.0
• broadcast 192.168.1.255
• network 192.168.1.0

This tells the system to use the network card assigned as eth111 for the static IPv4 address 192.168.1.2, with all the standard parameters.

You might also see this listed as 10.0.0.0/8, with the 8 detailing how many of the binary digits within the address are

fixed. Similarly, you might also see 172.16.0.0/12 and 192.168.0.0/16 used, respectively.

There are two addresses reserved for the subnet (0) and broadcast (255), thus reducing the total number from 256 to 254.

Some routers can not be configured away from 192.168.1.1, so it’s best to avoid using this number for anything else.

Determine whether this is eth0 or eth1 by either checking the output of dmesg | grep eth or adding the alias eth1 mynetcarddevice to /etc/modules.

You can use this approach to assign static IPv4 addresses to every machine on your network— simply make note of which machine is given which number. However, this can become tiresome after a while, and many embedded devices don’t allow such control over the configuration. Either case requires you to upgrade to DHCP.

DHCP stands for Dynamic Host Configuration Protocol and is a way of configuring the networking facilities of each client machine on the network. The software comes in two parts, a client and a server.

The client says simply, “I’m a machine; where is the network?” by transmitting a message onto the cable for all machines to hear. The server listens for any and all of these messages and responds by returning all the configuration data that the sender should use for networking, such as its IPv4 address, domain name, and so on.

Configuring a DHCP client in Linux is easy and involves replacing the earlier section of the /etc/network/interfaces file with the following:

auto eth1

iface eth1 inet dhcp

Creating a DHCP server takes a little more work but can often be avoided since many network routers include one, although it’s sometimes disabled by default.

To prepare one in Linux, you should first install the DHCP server software with a command such as this:

apt-get install dhcp3-server

You can then edit the /etc/dhcpd.conf file to assign addresses to each machine. Prior to editing, you may need to run this:

ln -s /etc/dhcp3/dhcpd.conf /etc/dhcpd.conf

ln -s /usr/sbin/dhcpd3 /usr/sbin/dhcpd

The addresses of each machine can be assigned by following these steps:

1. Giving it the next free number in a series, say 100–254. These are pooled addresses.
2. Looking at the MAC address of the network card that sent the message (all MACs are unique) and giving it a specific address based on that number.
3. Doing any combination of 1 and 2.

Since these pooled addresses are finite in number, they are never given to a machine. Instead, they are leased, and the DHCP client of each machine must rerequest the address if it’s still using it after a certain amount of time. The software does this automatically behind the scenes. If you have a lot of visitors to your home (who’d rather use the Internet than talk with you!), then leasing addresses is the simplest way to go because each friend wouldn’t need to have a static address that would require configuration.

Pooled addresses are configured like this:

subnet 192.168.1.0 netmask 255.255.255.0 {

option routers 192.168.1.1;

range 192.168.1.5 192.168.1.115;

}

Otherwise, the number of machines in your house is probably limited, so static addresses add very little work and make it quicker to troubleshoot since you know in advance what IP each computer should have. A typical configuration would appear like this:

host teddyspc {

hardware ethernet 00:A1:68:8E:9E:AA;

fixed-address 192.168.1.4;

}

This host section can be included within the subnet section shown previously to create exceptions in the pooling rule. You can determine which leases have been granted by typing the following:

more /var/lib/dhcp3/dhcpd.leases

Many other options are available in the DHCP server, but these provide enough to get everything working. I’ll cover the specific extra cases as appropriate.

Computer Names

My name is Steven, often shortened to Steev. My computer’s name is 192.168.1.110, which is less easy to remember for nongeeks. Chances are there will be more nongeeks in your house than geeks who will want to refer to each computer by a name such as “Holly’s computer” or “Angela’s laptop.” There are two strains of problem here: getting the computers in the house to have usable names and getting them to know the names of each computer outside the house on the Internet.

Computer names are usually distributed automatically around the local network, so they are not a problem, although it can sometimes take 30 seconds for the information to propagate to all machines. In case of problems, you can force-feed a mapping between IP addresses and computer names by adding a line like this:

192.168.1.110 mediapc

to the file located at /etc/hosts or C:\WINDOWS\SYSTEM32\DRIVERS\etc\hosts depending on whether you’re working on Linux or Windows, respectively.

Converting Internet domain names into numbers is done through a type of server known as Domain Name System (DNS). This is a simple client/server process whereby a client provides a domain name, such as google.com, and the server returns the globally accessible IPv4 address of the computer. There are many of these servers throughout the world, arranged in a hierarchy. So, if your local DNS server doesn’t know about a particular domain, it will ask its parent DNS server, and so on, all the way up to the master root zone server. All you need to do is configure your home machines to use the first DNS server in this chain, and the searches will happen automatically. If your ISP has provided you with a DNS server address, you can use this directly. Alternatively, if you are using a router, then this will often configure itself automatically by looking for a DNS server on the external part of the network (which only it can see) and then act as a DNS relay whereby it pretends to be a DNS server for internal network but instead passes all requests the ISP’s DNS, before returning the results to you.

Having got an IP address of the DNS server (you’ll use the 192.168.1.1 of the router in this example), you can use the DHCP server to distribute this information to each machine when it also requests an IP address of its own. Since the same DNS server is used for all local machines, this can be done by setting the global option at the top of the /etc/dhcpd.conf file: 

option domain-name-servers 192.168.1.1;

Alternatively, if you are not using DHCP to provide the networking credentials, then you must revert to the same /etc/network/interfaces file in which you specified its static address and add the following:

dns-nameservers 192.168.1.1

Network Services

Having a machine on a working network is not enough to make one machine do something with another machine. Communication needs to take place. You’ve already seen two services in action (DHCP and DNS), and you’re probably aware of others such as HTTP to access web sites and FTP to transfer files.

For your machine to work like this, you need to install a server of some kind. The trick is to know what kind of server is needed for any particular task. I will introduce these servers as needed. The first I’ll show how to set up is a file-sharing server with the ability to provide files across the local network, allowing a music collection to be situated on one machine but playable by any other on the subnet.

Note

It is possible to make files from the internal network available externally, but I’ll cover that later.

The service that makes files available is called Samba, which allows files (and printers) to be shared between machines. Because it operates on a well-understood protocol (called SMB/CIFS), it can share these resources between different operating systems including Linux, Windows, and Mac OS X.

It is installed in the usual way as your distribution, as shown here:

apt-get install samba

And it’s configured by editing this file:

/etc/samba/smb.conf

This is used to specify which folders on the local machine are available to the other computers and under what conditions, such as passwords or read/write privileges. Since the machine in question is on a private address range, the files will be accessible only to local machines, so you can generally make all these folders publicly accessible because in this context “public” means everyone in the house. 

Unlike a corporate network, abuse of networking facilities in a home environment (usually by the kids!) can be covered by not providing them with any dinner!

There are many ways of configuring Samba to provide files, but the defaults are good for a home environment. I personally add sections to share various files in three specific ways. The first provides full access to my music and video files on my media server, such as //mediapc. These are mounted in a directory structure like this:

/media/mp3

/media/tv

/media/movies

and provided with the configuration section, like this:

[media]

comment = Media Server

path = /media

browseable = yes

public = yes

writable = no

read only = yes

guest ok = yes

This gives anyone at home, including visitors, a chance to listen to whatever band I’ve been enthusing about. It’s public (meaning my visitors don’t need a user account on my computer) and browsable (so it can be found on the network, without anyone knowing its exact name). However, it is made read-only, preventing visitors from accidentally (or maliciously, with rogue viruses perhaps) deleting the files.

They can see it from their Windows network neighborhood (or by typing \\mediapc\media) or from Linux (either by desktop or command line, with smbmount //mediapc/media local_media_folder -o guest).

Next, I have a second share to the same location. This has a password, meaning that only I can add the latest DVD rips or music purchases to the system.

[media_incoming]

comment = Media Incoming

path = /media

browseable = no

public = no

writable = yes

read only = no

guest ok = no

The final share is my computer’s DVD drive. This is almost unused in my house since I’ve had the time to rip all my CDs and DVDs into files on my local machine, but it is still occasionally useful. The default installation provides a suitable example on the method here:

[cdrom]

comment = Media server's DVD

writable = no

locking = no

path = /dvd

public = yes

preexec = /bin/mount /dvd

postexec = /bin/umount /dvd

The last two lines will automatically mount the disk when asked for and unmount it after it’s been unused for a short period of time. The system is told how to handle the (un)mounting of /media/dvd with a suitable description in /etc/fstab.

/dev/scd0 /dvd udf,iso9660 user,noauto 0 0

Depending on the range and login configurations on your network, you may want to set up specific Samba users. If you’re a sysadmin by trade, setting up a centralized login database for all machines (Windows/Linux/Mac) might appear like a simple task. But for the rest of us, each machine will maintain its own set of usernames and passwords. Consequently, the Samba server has no way of knowing about these other machines or when their respective users decide to change their passwords. This makes it impossible for Samba to know what username/password combinations it should accept from this other machine. Therefore, it uses a separate set password table.

You simply need to type, as root, the following for each user who has password access to the particular Samba shared folders:

smbpasswd -a steev

For each user, you will be asked for the following

New SMB password:

Retype new SMB password:

at which point you can either ask the family member for a password or assign them one—knowing that it can be changed only by root on this same machine. Once the user has logged in from a particular machine, however, the operating system will usually remember the credentials, so no one will be continually prompted for this information. 

You should then restart the Samba service to make these changes visible to the world.

/etc/init.d/samba restart

This is all that’s necessary to make the files available across your network. This allows you to use the various media-streaming devices, or head units, currently available.

CCTV Cameras

Although the perception of CCTV is grainy black-and-white footage attached to small TV screens, the reality is much removed, particularly since color CCTV is now very cheap and the images are often transmitted via Ethernet. And although the technology behind webcams and CCTV cameras are similar, it is not particularly easy to use cheap webcams as a suitable replacement for the more expensive CCTV

Cameras:

• Webcams use USB to transmit their data, which imposes a limit on the cable length to around 5 meters, without special extension cables.
• Webcams don’t work particularly well in low-light environments.
• Webcams are not physically rugged, or waterproof, enough to live outside.

So, although you might be able to get away with a webcam peering out of the window beside the PC during the daytime, you won’t get much further than that. Instead, you’ll need a specially designed camera, generally transmitting its images through a wireless network, so you can position the camera where it’s needed—rather than whether you can run a cable to it.

Note 

Several versions of CCTV camera are available that are wired for indoors only. The primary benefit that these have over traditional webcams is that they transmit their data across an IP network, meaning they don’t need to be directly attached to a PC.

Virtually every CCTV camera on the market requires a power cable (although a Power-over-Ethernet connection can often suffice), so regardless of whether you choose wired or wireless networking, you will have to run at least one cable to the camera’s location. Apart from that, the main choice is for an indoors or outdoors mounting, the latter being more resilient to the weather. If you buy for indoors (such as a Ycam) and later change your mind, you can usually place it in a wall mount unit (the Y-cam shell) and attach it underneath a soffit.

For indoor CCTV, used maybe as a baby monitor, there are cameras like the Panasonic Wireless IP camera (BLC-20), which has motion detection and a built-in web server so it doesn’t need a PC to operate and can be viewed remotely provided the appropriate network ports are opened on the router.

Its elder brother (BLC-131) also provides remote control of the camera with pan and tilt functionality. When a camera is located inside but pointing outward, then it is best to look for those supporting some form of “night view mode.” Those using a CMOS sensor are better in this regard because they can work at light levels down to 0.2 lux, whereas traditional CCDs (as used in webcams) are a mere 3 lux. Most CCD cameras that claim night mode usually implement it in software and do nothing that a good GIMP session couldn’t fix, so opt for CMOS wherever possible.

For the most part, all CCTVs will work in the same way; it’s a case of balancing specification and price for your budget. Consider the size of the images, FTP upload, web access, whether you get e-mail notifications on motion detection, and so on.

Wireless Cameras That Aren’t

Many CCTV cameras on the market use the phrase wireless in a context that does not refer to WiFi. One such device is the XCAM2 Wireless Camera System. They actually use the industrial, scientific, and medical (ICM) wireless radio band to transmit their signals to a customized receiver, often for display on an attached monitor. These are therefore unsuitable for integrated home automation solutions, where the CCTV output needs to be viewed remotely.

However, if the particular receiver provides an output to RCA composite video, you can plug these into a TV card and record from that or use a hardware media recorder such as the Emprex ME-1. This limits you to one camera and prevents you from using the TV card (for recording or watching) while the CCTV is active. Of these, the second problem is easily solved by buying a second TV card. The former is more difficult.

If you need multiple cameras, then you will need to employ some additional control hardware, which could push the cost beyond that of an all-in-one IPCCTV camera. There are two approaches to the problem.

The first involves using several cameras but only one receiver. You can then use X10 to switch particular cameras on and off as required. The receiver will pick up the (only) signal now present and pass it to the TV card as before. This is the method suggested for the XCAM2, but it means you can’t review all the cameras at a glance.

The second solution uses multiple receivers (and therefore more cost) and a TV switcher to select between the different inputs. Some of these will even combine all images into one. Switching these units will require the use, and programming, of a computer-based IR transmitter because most are not IPcontrollable. (We’ll look at IR control later.)

Custom Hardware

In many cases, it is not necessary to build your own CCTV configurations, because it’s a known problem for which manufacturers have provided their own solutions. One such unit is a CCTV recorder/DVR, which usually comes with a CD rewriter and video out. This box will capture the feeds from multiple cameras and provide their output by S-video or composite, which can then be fed into a TV card, as before, for remote viewing and recording. Some versions are also supplied with an infrared remote control and network port.

Another alternative, if you’d like to keep everything PC-based, is a PCI card for real-time surveillance that can monitor four or more input channels from a single card, like the RW-1240R. The software and drivers for most of these, however, are currently Windows-based, so we don’t dwell on it any further.

Caution

Many of the stand-alone CCTV devices accept camera inputs from BNC video connectors, whereas the webcam-based ones use RCA.

Linux Software

Once the webcam image is available in a digital format, either through a USB driver or connected to the composite input of a TV card, the image can be processed or transmitted at will. Generally, the processing will occur through one of the standard video for Linux drivers (V4L), now in the second major version. This allows the data to be processed by any compatible software. Here are some examples:

xawtv: An X window utility to play back and record video streams, including composite input and TV stations. It has some functionality for previewing many video streams at once, but since most (analog) cards have to retune between devices, the results are not real time. camserv: This provides its own web server whereby you can watch the video input in real time from any web browser, supporting the motion JPEG format. There is no sound support here, however.

mencoder: Part of the mplayer package, this provides a command-line interface to record the AV signal from a V4L channel.

motion: A small utility that incorporates motion detection so that you only need to record the feed (and therefore use up hard disk space) when there is something moving outside. The specific amount of movement is user configurable to prevent it wasting space on trees swaying in the wind or your cat walking across the view.

Stand-Alone BitTorrent Clients

This is one of many “Linux-in-a-box” devices that have seen an upsurge in recent years, and no doubt there will be more to come. These, such as the Emprex NDS-100, take the place of a full-powered PC and provide functionality for BitTorrent and file and printer sharing. Essentially, it’s the low-power functionality you’d want from an always-on machine, without the high-power hardware to run it. If you already have, or plan on using, your own home server for other things, then this will not save you much depending on the type of server used. A Mini-ITX box, for example, will have a similar power footprint and provide a better level of functionality.

Infrared Remote Control

For coach-potato living, nothing has the convenience of an infrared remote control. A small infrared LED in the handset flashes in a predetermined sequence, which an “eye” on the receiving device decodes to change the channel, increase the volume, and so on. IR remotes are so cheap that every device has once. That is the first problem because as the number of devices increases, the free space on the sofa proportionally decreases!

The second problem is line of sight, by which all IR remotes work. This means you have to point the remote at the device, within a moderate tolerance, for the signal to be received. But it’s not always convenient to have the device placed in front of you; a projector, for example, will usually be behind you. 

If the TV audio is wired up to a HiFi, they may be in different places in the room, because of lack of space or power sockets. Or you might want to run cables from the DVD player into the bedroom or kitchen to continue a film uninterrupted. In each case, you may be unable to remotely control the device without moving yourself or the devices.

An occasionally third problem with IR remote controls is with the receiving eye, which doesn’t always see the signal. This third problem can often be solved by placing a piece of frosted glass or Scotch Magic Tape over the “eye.” This diffracts the incoming light from a greater range of angles, making it more sensitive. The first two problems need more involved hardware.

All-in-One Remotes

There are so many combined all-in-one remotes that it’s difficult to know which to get without trying them. Unfortunately, that is what you must generally do, because each one has some quirk or another that makes it unsuitable for your particular set of devices.

Although several varieties of “all-in-one” remotes exist, they are not created equally. You need to consider the specifics of each device you want to control because in the United Kingdom and Ireland, Sky Plus, for example, uses a slightly different IR protocol than normal, so unless your remote is specifically designed to handle it, you device will appear mute.

A number of learning remotes are available now, and these can prove a good investment. Another useful feature is a macro, which will store a number of commands in sequence. For example, a movie mode macro could switch the TV to DVD input, switch on and eject the DVD tray, and set the HiFi to accept a DVD input.

IR Relays

These devices overcome the line-of-sight problem by retransmitting IR signals from one place to another. They consist of both a transmitter (which watches for IR signals and relays them over the air) and a matched receiver (which replays the same IR message to the device). With a suitable transmission range, you can remotely control the downstairs TV from upstairs.

Sometimes it’s possible to have multiple transmitters, one in the kitchen and one in the bedroom, say, that both send the signals to one place, allowing you to remotely control the TV from anywhere. By the same token, it is sometimes possible to have multiple receivers, enabling an all-in-one remote to send commands from the bedroom to both the TV downstairs and the HiFi in the next room.

However, this configuration is less common because, if you’ve installed an IR relay, the location of the equipment doesn’t matter, so it is usually in the same physical location; therefore, you only need to mount one IR receiver, which sends the relayed signal to all devices at once. If the devices are fairly close to one another but the receiver can’t see both devices, then it is usual to use a Y-splitter and two IR LEDs rather than buying another receiver unit.

Communication between the two transmitter and receiver is done through one of the ways outlined next.

Over the Aerial Cable

If your primary purpose is to relay IR controls for a TV, then you can get devices that embed the IR data onto the existing coaxial aerial cable, hiding it with similar results to X10. The Labgear MRX120 HandyLink, for example, provides such a solution. Naturally, this approach requires an aerial cable in each room, which there will be if your focus is TV control. If the aerial cables already exist, then scaling up is easy, because adding extra amplifiers is fairly cheap and is a simple plug-and-play affair.

Without existing cables, however, this can be more trouble than it’s worth, given the IR-RF-IR possibilities, but it can provide a solution where RF reception is especially poor. In both cases, it is impossible to watch different channels in each room, even with Sky, because it’s distributing a single signal from the tuner.

Note

You may need an IR bypass kit when passing IR signals over coax cables because the messages get muddled when passing through distribution amplifiers.

IR-RF-IR Gateways

These devices relay IR data through the air, at the 433MHz radio frequency used by so much wireless equipment, before being replayed. For these devices, you have a choice between IR-only transmissions and TV senders.

An IR-only transmitter, such as the Powermid XL, is the simplest of these devices and will allow you to remotely control devices without installing cables or sockets. They are fairly cheap but pass only IR data, so the controlled device must be able to have an impact on you when you’re in another room.

TV senders are the wireless versions of the over-the-aerial cables or old TV distribution systems, which involved an aerial amplifier and a separate aerial cable into each TV in the house. The TV sender takes a single input and transmits it to whichever receivers are listening, encoding whatever IR signals it also saw. There are many variants on the market, including those with SCART sockets (instead of the oldschool

coaxial aerial sockets) and RCA composite video. Even the cheaper models often have a “channel” switch on them, allowing multiple receiver-transmitter pairs to be used in the same house without the signals getting mixed up. And with these devices becoming more mainstream, some are almost as cheap as an IR-only transmitter, with the TV functionality becoming a free bonus feature.

IR Over IP

It is also possible to send data over your existing Ethernet cables, using devices such as the Keene IR Anywhere over IP (KIRA). This eliminates any distance or interference issues you might get from the other methods and also provides a way of remotely controlling IR devices from a computer, without needing to have the computer and its IR transmitter physically in range of the device.

Being IP-controlled also means that IR signals can be sent via the Internet. Although this is pointless in itself (because you can’t derive any benefit from changing the TV channel when you’re not sitting watching it), it does provide an off-the-shelf way of controlling IR-based devices from a remote computer. And if something can be controlled from a computer, then it can be controlled from anything connected to the computer, such as a web page or cron job.

Using KIRA to retransmit IR codes first requires that you teach it those codes in the first place. This is done by generating text files, using the software shown in Figure 1-15. 

Figure 1-15. Configuring KIRA

This software is available from the Keene web site and has been thoughtfully written in Java, making it Linux-friendly. After attaching KIRA to your network and after it’s used your DHCP server to provide it with an IP address, you can add new commands. First you request that all the IR messages are sent to this machine, and then you press Learn before hitting the first key on your remote. This should present the code, such as the following, which can then be copied and pasted into a text file for later use:

K 240C 037F 0369 03AC 034D 0624 035A 0378 0382 0378 0381 0396 0366 0377

0382 0396 0365 0396 06E0 03AF 034C 072C 0353 0378 2000

I have used a directory hierarchy for each device so that the on/off button for my TV is in the directory ir/tv/codes/on. Since the same button performs both functions, I created a symlink between off and on. Those with bigger houses and more TVs might like to use a more descriptive name than TV.

Although KIRA has a web page, it isn’t very configurable and limits you to four prestored IR codes. Fortunately, it also listens for commands sent on UDP ports 30303 and 65432. The former is for device discovery and configuration, so consequently the port cannot be changed. The latter is the IR control port, which processes all the basic commands to control the various IR devices within range. All responses to these commands are returned by UDP also, so you need to run two instances of the Swiss Army knife of network utility, netcat, to handle it.

Begin by creating two terminal windows, and start a UDP server in one of them by typing the following:

nc -u -l -p 30303

This will now listen on port 30303 for any UDP messages sent to it. Now, in the other window, send a message to KIRA (whose IP has been determined as 192.168.1.111 by the DHCP server) on the same port.

echo disD | nc -q 0 -u 192.168.1.111 30303

You should see the other window spring to life and report various stats about the device. If not, check that the ports are open and working with (that other Swiss Army knife of networking) netstat:

netstat -ntpl

With some averagely clever bash coding, you can achieve the same result with a script such as the following:

#!/bin/bash

TEMPFILE=`mktemp`

nc -u -l -p 30303 >$TEMPFILE &

PROCESS=$!

echo disD | nc -q 0 -u 192.168.1.111 30303

# Wait for a second so the output has finished writing

sleep 1

kill $PROCESS

cat $TEMPFILE

rm $TEMPFILE

The process for sending IR messages is the same, except you need to switch onto the IR port. Here’s an example:

cat ir/codes/tv/off | nc -q 0 -u 192.168.1.111 65432

The only response sent to port 65432 is ACK, which can be safely ignored. However, if you do decide to listen to port 65432 (and you have requested that all IR messages are forwarded to your PC), then you will see the key codes appear. These can be copied from the terminal window (instead of using the web interface) into your own configuration files. There is a supplied API document detailing each of the commands that each port handles. Note that by using your Linux machine to maintain the IR codes, you don’t need to ever upload keycode files to one of the four slots on its web server.

Note 

You can several KIRA devices on your network, each transmitting messages to different devices, although for KIRA to receive messages and send them back to a PC, you must explicitly enable the functionality from its web interface and give it the IP address where netcat, or similar, will be listening.

IR Control

If you have a PC fairly close to the IR devices you want to control, it is easy to add a suitable USB-based transmitter or receiver to it. These can be either bought from places like RedRat or built from one of the circuit diagrams provided by the LIRC (Linux Infra-Red Remote Control), which also provides the software.

Caution

Most PCs attach USB ports directly to the motherboard, and if you make a mistake when building your own device, you could destroy it. Purchasing a separate PCI board with USB sockets should provide some protection from mishaps.

For IR transmission, you need to know the specific control codes of the device you want to control. If you have a standard TV or video, this data is usually available online 

(http://lirc.sourceforge.net/remotes/); 

otherwise, you will also need to purchase or build an IR receiver to teach LIRC the existing codes. Fortunately, if you took the earlier hint and bought a RedRat, you will have a receiver built in that, along with the supplied Windows software or LIRC, can be used to program the codes directly.

LIRC is the Linux-standard method for reading and transmitting IR data. It comprises a standard daemon, lircd, and a set of tools to record the input messages and transmit them back again. It adopts a modular approach to support the wide variety of LIRC devices available. Reproducing an installation guide here would be foolhardy, but suffice to say there are three main types of supported control:

GPIO devices: These are generally supplied with TV cards, such as those from Hauppauge. The modules are usually compiled into the standard daemon build.

Serial port device: This covers a wide range of different devices, including home-brew transmitters, and because they process serial data directly, they don’t need any specific driver code. Typical circuits are available from the LIRC web site. If you’re unsure about connecting your own electronics onto your PC motherboard, you can buy serial PCI cards, which offer a level of protection against rogue electronics.

Kernel drivers: These, such as the RedRat3 device, require you to build LIRC from source and (in some cases) copy the new driver code into the LIRC directory. From here you can rebuild the setup (data2setup.sh) file and build as normal. These devices will make use of the /dev/lircd device, which should have ugo+rw privileges.

Once built, the drivers can be configured and prepared according to the table at LIRC, which also provides sample configuration files for the various devices that describe each button with a humanfriendly name and the details of the IR signal to be sent. From here, you can add specific commands to be triggered upon the various button presses within the .lircrc file, which has a format typical of this:

begin

prog = mythtv

button = Rew

config = Left

end

Each button on the remote is mapped to a function of the software (prog) in this fashion. One of the big benefits in using RedRat, and LIRC in general, is its inclusion in many standard media players, mixers, and TV applications. Consequently, if this is your primary purpose of IR, then you have completed your media installation already since those commands can trigger something useful in the existing software!

LIRC also has a network mode whereby you can communicate with an LIRC daemon through a network socket, allowing an external application to act as if it were a local IR remote control. This is useful for testing and as a method of remotely a PC-based media player without writing new code. For more specific applications, you will need to make use of irexec, as shown here:

begin

prog = irexec

button = ok

config = /usr/bin/someprogram with arguments here

end

In this way, you can use an IR remote to interact with other arbitrary applications, including media players on other machines. Additionally, you can adopt the same ideas as Cosmic (mentioned earlier and covered in Part 7) to develop a state-based control mechanism using very cheap IR transmitters.

Conclusion

Each device in your home should have the ability to be controlled remotely, either through the power lines (with X10 or C-Bus), with an Ethernet socket, or through basic Infrared. This is the first step of a two-stage process. The second is when you have a computer able to issue control messages to those devices. At that point, they can be used seamlessly from anywhere in the world. When the device doesn’t support such functionality, you have to hack it. And that’s where the geeky fun begins!

Share this post