Posts Tagged ‘usb’

Simple Disk or File-System Image Encryption with dm-crypt

dm-crypt is a part of modern Linux’s device mapper system which allows for the transparent application of a broad range of block cyphers to a virtual block device. The virtual block device is configured with the cryptsetup command and can point to a real block device (i.e. a real hard drive or partition) or a file which has been attached to a loop device as the underlaying source.

There are a lot of great reasons to use LUKS (Linux Unified Key Setup), not the least of which is the ability to encrypt the host operating system’s partition or change the encrypted volume’s passphrase. In this article however, we will simply be covering the mundane encryption of block devices with dm-crypt.

One of the advantages of encrypting a physical hard drive from head to toe is that there is no partition table around to leak metrics; if you followed Filling a Drive with Random Data: urandom, dd and Patience your encrypted file system will span the size of the device and any cryptographic boundaries should be undetectable.

If you will be working with a file instead of a real block device it will be necessary to create the file and set it up on a loop device before proceeding. Just as with wiping a disk it is recommended that /dev/urandom is used to initialize the file insted of /dev/zero but you may find the same benefit for much less time in simply creating a sparse file (please see Managing Raw Disk/File System Image Files for more details).

# dd if=/dev/urandom of=encrypted.img bs=1M count=1000
OR
# dd if=/dev/zero of=encrypted.img seek=1000 bs=1M count=0
THEN
# losetup /dev/loop0 encrypted.img

Now we’re going to run the device through dm-crypt using 256 bit AES and SHA256 ESSIV. ESSIV is a method of generating initialization vectors which are difficult to predict; this helps protect against watermarking attacks. You will be asked to provide a passphrase, the longer and more complex the better.

# cryptsetup -c aes-cbc-essiv:sha256 create encryptedVolume /dev/loop0 (or /dev/sdd, etc)
Enter passphrase:

Alternatively, you may prefer to use a large chunk of random data stored in a file, perhaps on a USB stick.

# dd if=/dev/urandom of=/mnt/usb/passphrase.key bs=1K count=4
# cat /mnt/usb/passphrase.key | cryptsetup -c aes-cbc-essiv:sha256 create encryptedVolume /dev/loop0

This method provides excellent protection against brute force attacks but may add a physical security dilemma. Consider a case where law enforcement agents have a warrant to search and sieze your property; if they find the USB stick and figure out that it contains the key to your encrypted drive they don’t have to pressure you for your passphrase to use it. On the other hand, depending where and with whom the key is stored this approach could have benefits in a rubber-hose attack situation as 4K of random data is virtually impossible to memorize.

Our new virtual block device is located under /dev/mapper. Now we can create the filesystem of our choice on it:

# mke2fs -j /dev/mapper/encryptedVolume

Once the filesystem is in place the device can be mounted and used like any regular block or loop device:

# mkdir /mnt/encrypted
# mount /dev/mapper/encryptedVolume /mnt/encrypted

As long as the device is available through device mapper the contents of the encrypted volume are vulnerable to the same kind of attacks any part of your regular system is: malware, viruses, cockpit error and so on. When not in use be sure to unmount the file system and destroy the device mapper entry:

# umount /mnt/encrypted
# cryptsetup remove encryptedVolume

If your volume is file-backed it is now safe to unhitch it from the loop device:

# losetup -d /dev/loop0

Configuring APCUPSD on Gentoo for APC SmartUPS Over Serial

Both of the Gentoo wiki links at the bottom of this article are more-or-less USB-oriented so here’s a quick start for Serial connections. I use a USB to serial adapter so my serial device is named /dev/ttyUSB0, yours may be different if you use a regular serial port (i.e. /dev/ttyS0).

Emerge apcupsd:

# emerge apcupsc

Calculating dependencies... done!
[ebuild  N     ] sys-power/apcupsd-3.14.8-r1  USE="cgi nls snmp usb -gnome" 

Be sure to include the snmp USE flag if you will be configuring any UPSes with a networked management card later.

Edit /etc/apcupsd/apcupsd.conf to reflect:

## apcupsd.conf v1.1 ##
# 
#  for apcupsd release 3.14.8 (16 January 2010) - gentoo
#
# "apcupsd" POSIX config file

#
# ========= General configuration parameters ============
#

# UPSNAME xxx
#   Use this to give your UPS a name in log files and such. This
#   is particulary useful if you have multiple UPSes. This does not
#   set the EEPROM. It should be 8 characters or less.
#UPSNAME

# UPSCABLE <cable>
#   Defines the type of cable connecting the UPS to your computer.
#
#   Possible generic choices for <cable> are:
#     simple, smart, ether, usb
#
#   Or a specific cable model number may be used:
#     940-0119A, 940-0127A, 940-0128A, 940-0020B,
#     940-0020C, 940-0023A, 940-0024B, 940-0024C,
#     940-1524C, 940-0024G, 940-0095A, 940-0095B,
#     940-0095C, M-04-02-2000
#
UPSCABLE smart

# To get apcupsd to work, in addition to defining the cable
# above, you must also define a UPSTYPE, which corresponds to
# the type of UPS you have (see the Description for more details).
# You must also specify a DEVICE, sometimes referred to as a port.
# For USB UPSes, please leave the DEVICE directive blank. For
# other UPS types, you must specify an appropriate port or address.
#
# UPSTYPE   DEVICE           Description
# apcsmart  /dev/tty**       Newer serial character device, appropriate for 
#                            SmartUPS models using a serial cable (not USB).
#
# usb       <BLANK>          Most new UPSes are USB. A blank DEVICE
#                            setting enables autodetection, which is
#                            the best choice for most installations.
#
# net       hostname:port    Network link to a master apcupsd through apcupsd's 
#                            Network Information Server. This is used if the
#                            UPS powering your computer is connected to a 
#                            different computer for monitoring.
#
# snmp      hostname:port:vendor:community
#                            SNMP network link to an SNMP-enabled UPS device.
#                            Hostname is the ip address or hostname of the UPS 
#                            on the network. Vendor can be can be "APC" or 
#                            "APC_NOTRAP". "APC_NOTRAP" will disable SNMP trap 
#                            catching; you usually want "APC". Port is usually 
#                            161. Community is usually "private".
#
# netsnmp   hostname:port:vendor:community
#                            OBSOLETE
#                            Same as SNMP above but requires use of the 
#                            net-snmp library. Unless you have a specific need
#                            for this old driver, you should use 'snmp' instead.
#
# dumb      /dev/tty**       Old serial character device for use with 
#                            simple-signaling UPSes.
#
# pcnet     ipaddr:username:passphrase
#                            PowerChute Network Shutdown protocol which can be 
#                            used as an alternative to SNMP with the AP9617 
#                            family of smart slot cards.ipaddr is the IP 
#                            address of the UPS mgmtcard. username and 
#                            passphrase are the credentials for which the card 
#                            has been configured.
#
UPSTYPE apcsmart
DEVICE /dev/ttyUSB0

# POLLTIME <int>
#   Interval (in seconds) at which apcupsd polls the UPS for status. This
#   setting applies both to directly-attached UPSes (UPSTYPE apcsmart, usb, 
#   dumb) and networked UPSes (UPSTYPE net, snmp). Lowering this setting
#   will improve apcupsd's responsiveness to certain events at the cost of
#   higher CPU utilization. The default of 60 is appropriate for most
#   situations.
#POLLTIME 60

# LOCKFILE <path to lockfile>
#   Path for device lock file. Not used on Win32.
LOCKFILE /var/lock

# SCRIPTDIR <path to script directory>
#   Directory in which apccontrol and event scripts are located.
SCRIPTDIR /etc/apcupsd

# PWRFAILDIR <path to powerfail directory>
#   Directory in which to write the powerfail flag file. This file
#   is created when apcupsd initiates a system shutdown and is
#   checked in the OS halt scripts to determine if a killpower
#   (turning off UPS output power) is required.
PWRFAILDIR /etc/apcupsd

# NOLOGINDIR <path to nologin directory>
#   Directory in which to write the nologin file. The existence
#   of this flag file tells the OS to disallow new logins.
NOLOGINDIR /etc


#
# ======== Configuration parameters used during power failures ==========
#

# The ONBATTERYDELAY is the time in seconds from when a power failure
#   is detected until we react to it with an onbattery event.
#
#   This means that, apccontrol will be called with the powerout argument
#   immediately when a power failure is detected.  However, the
#   onbattery argument is passed to apccontrol only after the 
#   ONBATTERYDELAY time.  If you don't want to be annoyed by short
#   powerfailures, make sure that apccontrol powerout does nothing
#   i.e. comment out the wall.
ONBATTERYDELAY 6

# 
# Note: BATTERYLEVEL, MINUTES, and TIMEOUT work in conjunction, so
# the first that occurs will cause the initation of a shutdown.
#

# If during a power failure, the remaining battery percentage
# (as reported by the UPS) is below or equal to BATTERYLEVEL, 
# apcupsd will initiate a system shutdown.
BATTERYLEVEL 2

# If during a power failure, the remaining runtime in minutes 
# (as calculated internally by the UPS) is below or equal to MINUTES,
# apcupsd, will initiate a system shutdown.
MINUTES 3

# If during a power failure, the UPS has run on batteries for TIMEOUT
# many seconds or longer, apcupsd will initiate a system shutdown.
# A value of 0 disables this timer.
#
#  Note, if you have a Smart UPS, you will most likely want to disable
#    this timer by setting it to zero. That way, you UPS will continue
#    on batteries until either the % charge remaing drops to or below BATTERYLEVEL,
#    or the remaining battery runtime drops to or below MINUTES.  Of course,
#    if you are testing, setting this to 60 causes a quick system shutdown
#    if you pull the power plug.   
#  If you have an older dumb UPS, you will want to set this to less than
#    the time you know you can run on batteries.
TIMEOUT 0

#  Time in seconds between annoying users to signoff prior to
#  system shutdown. 0 disables.
ANNOY 300

# Initial delay after power failure before warning users to get
# off the system.
ANNOYDELAY 60

# The condition which determines when users are prevented from
# logging in during a power failure.
# NOLOGON <string> [ disable | timeout | percent | minutes | always ]
NOLOGON disable

# If KILLDELAY is non-zero, apcupsd will continue running after a
# shutdown has been requested, and after the specified time in
# seconds attempt to kill the power. This is for use on systems
# where apcupsd cannot regain control after a shutdown.
# KILLDELAY <seconds>  0 disables
KILLDELAY 0

#
# ==== Configuration statements for Network Information Server ====
#

# NETSERVER [ on | off ] on enables, off disables the network
#  information server. If netstatus is on, a network information
#  server process will be started for serving the STATUS and
#  EVENT data over the network (used by CGI programs).
NETSERVER on

# NISIP <dotted notation ip address>
#  IP address on which NIS server will listen for incoming connections.
#  This is useful if your server is multi-homed (has more than one
#  network interface and IP address). Default value is 0.0.0.0 which
#  means any incoming request will be serviced. Alternatively, you can
#  configure this setting to any specific IP address of your server and 
#  NIS will listen for connections only on that interface. Use the
#  loopback address (127.0.0.1) to accept connections only from the
#  local machine.
NISIP 0.0.0.0

# NISPORT <port> default is 3551 as registered with the IANA
#  port to use for sending STATUS and EVENTS data over the network.
#  It is not used unless NETSERVER is on. If you change this port,
#  you will need to change the corresponding value in the cgi directory
#  and rebuild the cgi programs.
NISPORT 3551

# If you want the last few EVENTS to be available over the network
# by the network information server, you must define an EVENTSFILE.
EVENTSFILE /var/log/apcupsd.events

# EVENTSFILEMAX <kilobytes>
#  By default, the size of the EVENTSFILE will be not be allowed to exceed
#  10 kilobytes.  When the file grows beyond this limit, older EVENTS will
#  be removed from the beginning of the file (first in first out).  The
#  parameter EVENTSFILEMAX can be set to a different kilobyte value, or set
#  to zero to allow the EVENTSFILE to grow without limit.
EVENTSFILEMAX 10

#
# ========== Configuration statements used if sharing =============
#            a UPS with more than one machine

#
# Remaining items are for ShareUPS (APC expansion card) ONLY
#

# UPSCLASS [ standalone | shareslave | sharemaster ]
#   Normally standalone unless you share an UPS using an APC ShareUPS
#   card.
UPSCLASS standalone

# UPSMODE [ disable | share ]
#   Normally disable unless you share an UPS using an APC ShareUPS card.
UPSMODE disable

#
# ===== Configuration statements to control apcupsd system logging ========
#

# Time interval in seconds between writing the STATUS file; 0 disables
STATTIME 0

# Location of STATUS file (written to only if STATTIME is non-zero)
STATFILE /var/log/apcupsd.status

# LOGSTATS [ on | off ] on enables, off disables
# Note! This generates a lot of output, so if         
#       you turn this on, be sure that the
#       file defined in syslog.conf for LOG_NOTICE is a named pipe.
#  You probably do not want this on.
LOGSTATS off

# Time interval in seconds between writing the DATA records to
#   the log file. 0 disables.
DATATIME 0

# FACILITY defines the logging facility (class) for logging to syslog. 
#          If not specified, it defaults to "daemon". This is useful 
#          if you want to separate the data logged by apcupsd from other
#          programs.
#FACILITY DAEMON

#
# ========== Configuration statements used in updating the UPS EPROM =========
#

#
# These statements are used only by apctest when choosing "Set EEPROM with conf
# file values" from the EEPROM menu. THESE STATEMENTS HAVE NO EFFECT ON APCUPSD.
#

# UPS name, max 8 characters 
#UPSNAME UPS_IDEN

# Battery date - 8 characters
#BATTDATE mm/dd/yy

# Sensitivity to line voltage quality (H cause faster transfer to batteries)  
# SENSITIVITY H M L        (default = H)
#SENSITIVITY H

# UPS delay after power return (seconds)
# WAKEUP 000 060 180 300   (default = 0)
#WAKEUP 60

# UPS Grace period after request to power off (seconds)
# SLEEP 020 180 300 600    (default = 20)
#SLEEP 180

# Low line voltage causing transfer to batteries
# The permitted values depend on your model as defined by last letter 
#  of FIRMWARE or APCMODEL. Some representative values are:
#    D 106 103 100 097
#    M 177 172 168 182
#    A 092 090 088 086
#    I 208 204 200 196     (default = 0 => not valid)
#LOTRANSFER  208

# High line voltage causing transfer to batteries
# The permitted values depend on your model as defined by last letter 
#  of FIRMWARE or APCMODEL. Some representative values are:
#    D 127 130 133 136
#    M 229 234 239 224
#    A 108 110 112 114
#    I 253 257 261 265     (default = 0 => not valid)
#HITRANSFER 253

# Battery charge needed to restore power
# RETURNCHARGE 00 15 50 90 (default = 15)
#RETURNCHARGE 15

# Alarm delay 
# 0 = zero delay after pwr fail, T = power fail + 30 sec, L = low battery, N = never
# BEEPSTATE 0 T L N        (default = 0)
#BEEPSTATE T

# Low battery warning delay in minutes
# LOWBATT 02 05 07 10      (default = 02)
#LOWBATT 2

# UPS Output voltage when running on batteries
# The permitted values depend on your model as defined by last letter 
#  of FIRMWARE or APCMODEL. Some representative values are:
#    D 115
#    M 208
#    A 100
#    I 230 240 220 225     (default = 0 => not valid)
#OUTPUTVOLTS 230

# Self test interval in hours 336=2 weeks, 168=1 week, ON=at power on
# SELFTEST 336 168 ON OFF  (default = 336)
#SELFTEST 336

Start APCUPSD:

# /etc/init.d/apcupsd start

Add apcupsd to the default runlevel:

# rc-update add apcupsd default

If you want apcupsd to power off your UPS when it shuts down your system in a power failure, add apcupsd.powerfail to the shutdown runlevel:

# rc-update add apcupsd.powerfail shutdown

Verify you are able to communicate with the UPS with this configuration:

# apcaccess status
APC      : 001,051,1223
DATE     : 2012-08-14 21:19:08 -0400  
HOSTNAME : mdma
VERSION  : 3.14.8 (16 January 2010) gentoo
UPSNAME  : UPS_IDEN
CABLE    : Custom Cable Smart
MODEL    : SMART-UPS 1400 RM
UPSMODE  : Stand Alone
STARTTIME: 2012-08-14 21:16:51 -0400  
STATUS   : ONLINE 
LINEV    : 120.9 Volts
LOADPCT  :  40.5 Percent Load Capacity
BCHARGE  : 100.0 Percent
TIMELEFT :  10.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
MAXLINEV : 120.9 Volts
MINLINEV : 119.6 Volts
OUTPUTV  : 120.2 Volts
SENSE    : High
DWAKE    : 000 Seconds
DSHUTD   : 020 Seconds
DLOWBATT : 02 Minutes
LOTRANS  : 103.0 Volts
HITRANS  : 132.0 Volts
RETPCT   : 000.0 Percent
ITEMP    : 43.6 C Internal
ALARMDEL : 5 seconds
BATTV    : 28.0 Volts
LINEFREQ : 60.0 Hz
LASTXFER : Automatic or explicit self test
NUMXFERS : 0
TONBATT  : 0 seconds
CUMONBATT: 0 seconds
XOFFBATT : N/A
SELFTEST : NO
STESTI   : 336
STATFLAG : 0x07000008 Status Flag
DIPSW    : 0x00 Dip Switch
REG1     : 0x00 Register 1
REG2     : 0x00 Register 2
REG3     : 0x00 Register 3
MANDATE  : 06/04/98
SERIALNO : XXXXXXXXXXXXX
BATTDATE : 10/19/07
NOMOUTV  : 115 Volts
NOMBATTV :  24.0 Volts
EXTBATTS : 0
FIRMWARE : 72.9.D
APCMODEL : KWD
END APC  : 2012-08-14 21:19:51 -0400

Now we’ll do a serious test; tail the log and unplug the UPS then plug it back in. You should see something like:

# tail -f /var/log/apcupsd.events 
2012-08-14 21:17:05 -0400  apcupsd 3.14.8 (16 January 2010) gentoo startup succeeded
2012-08-14 21:23:04 -0400  Power failure.
2012-08-14 21:23:10 -0400  Running on UPS batteries.

Broadcast message from root@mdma (Tue Aug 14 21:23:10 2012):

Power failure on UPS UPS_IDEN. Running on batteries.
2012-08-14 21:23:11 -0400  Mains returned. No longer on UPS batteries.
2012-08-14 21:23:11 -0400  Power is back. UPS running on mains.

Broadcast message from root@mdma (Tue Aug 14 21:23:12 2012):

Power has returned on UPS UPS_IDEN...

If you would like to be notified of events by e-mail edit the scripts in the /etc/apcupsd directory and change the SYSADMIN variable to your preferred e-mail address.

More Reading:

Everything I Wanted to Tell You About X10 Home Automation

…But Didn’t Have the Time to Say

I had been meaning to chronicle my tinkering with Home Automation in the same way I have been documenting my ongoing experience with Electronic Cigarettes. Unfortunately, I never found the time to post as I made my installations and I will be moving soon, leaving most of them behind. I want to make sure the 100th post on foxpa.ws has substance so without further carry-on may I present unto you my complete experience with X10:

What Are X10 and Home Automation?

Home Automation is the art of modifying and integrating household systems (lighting, HVAC, etc.) to respond to events automatically (timers, security sensors, etc.) or methods of control not already provided (computer, remote control, etc.).

X10 is a power-line and wireless communications standard for home automation. Developed in 1975, X10 is widely deployed and devices that use it are relatively inexpensive.

How Does X10 Work?

X10 devices communicate digital information over your house’s power lines at the zero-crossing point of the (60 Hz) AC current by either sending a 1ms long 120 kHz pulse to represent a 1 bit or not sending anything to indicate a 0. Each device is configured with a 4-bit “house” code (A-P) and a 5-bit “key” code (1-16, always ends in 0). Additionally, there are 16 global commands which are also 5-bits and always end in 1. The house code is intended to prevent conflicts with neighbouring houses or units but is more commonly used to group different sets of devices together in larger installations.

House Code Device Code Binary Value Function Binary Value
A 1 0110 All Units Off 0000
B 2 1110 All Lights On 0001
C 3 0010 On 0010
D 4 1010 Off 0011
E 5 0001 Dim 0100
F 6 1001 Bright 0101
G 7 0101 All Lights Off 0110
H 8 1101 Extended Code 0111
I 9 0111 Hail Request 1000
J 10 1111 Hail Acknowledge 1001
K 11 0011 Pre-set Dim (1) 1010
L 12 1011 Pre-set Dim (2) 1011
M 13 0000 Extended Data Transfer 1100
N 14 1000 Status On 1101
O 15 0100 Status Off 1110
P 16 1100 Status Request 1111

To grab the attention of the devices all commands are preceded with a start code, 1110. Since the idle data-stream consists of an absence of 120kHz pulses or 0s, devices can be sure if they see three 1s in a row that a command is being sent and they are not simply picking up noise. To improve reliability all commands are sent twice, with a three cycle delay in between. An X10 frame might look like this:

1110  0110  01100 000   1110  0110  01100
start house  key  pause start house  key

X10 also has a radio frequency specification that lets remote controls and computer attachments send X10 commands via a radio receiver plugged into the house wiring.

My Installaton

My installation started small and increased in stages as I became more aware of the capabilities of X10. My first order was for:

  • TM751 Mini Transciever – This is the device that takes wireless X10 signals and repeats them on the wire.
  • HR12A PalmPad Remote Control – These are large RF “clickers”
  • KR22A Credit Card Controller – A less bulky RF controller that only covers 4 units
  • AM466 3 Pin Grounded Appliance Module – A grounded module is slightly more expensive than a 2-prong “lamp” module
  • WS12A 3-Way Dimmers – I didn’t use their 3-way capability. Annoying one-pole switch requires double tap to adjust light in opposite direction

As you can see, some modules are designed to be wired into the electrical box and others are designed to plug into pre-existing sockets. There are some light modules that even screw into the Edison-type connector typical North American light bulbs use for easy installation in fixtures and lamps. Maliciously, these dimmers have cover plates which are shaped to provide the appearance of rocker switches. In truth, they are one-poll switches. A single tap to turn the light on or off, hold to dim or brighten the light or – this is my favourite part – hold to see if the current “direction” is dim or brighten, release, very quickly press and hold to go in the opposite direction.

It should be noted that most dimmers – including the ones I purchased – do NOT work with fluorescent lighting. I use the 20A rated on/off wall-switches which are usually advertised for appliances where there are fluorescent lights or fans. The drawback to this is every few moments the CFL may flicker very dimly while the switch is “off” due to the switch itself drawing a small amount of current. The other caveat in using the 20A switches is that they must be wired into both hot and neutral; this presents a problem in electrical boxes where both are not accessible. It is perfectly safe to use a 20A rated switch in a 15A circuit; overload protection is provided by the breaker which only means the switch has leftover potential capacity on a 15A circuit.

Here’s a shot of the dimmer and 20A switch I installed in my ensuite. The dimmer is rated for 500watts so it runs my 4x100Watt vanity strip perfectly. I’m sure the ladies can appreciate the kind of light range that can give you in a bathroom. The fan, being an induction-driven appliance, does not like TRIAC-based dimmers so it goes on on a simple 20A switch (WS13A).

It wasn’t long before I noticed there were intermittent problems getting the signals across to certain parts of the house from the RF receiver. Many household devices, particularly: televisions, PCs and uninterruptible power supplies will absorb X10 signals passing through them. The most effective solution is to put them on a filter. X10 filters block the frequency X10 devices use from entering the connected device(s) at the wall. Unfortunately, while the modules in the first two pictures averaged $10 each filters are much more expensive.

An XPPF 5 amp plug-in filter (far below) runs upward of $15 and an AF120 15 amp filter (above) runs upward of $35. Given I use two 1400VA UPSes for my workstation and networking I was forced to get the full 15A filters. These come with a screw hole in a tab at the top aligned so that the screw of a standard receptacle faceplate can be used to secure the filter into the wall. Given its size and weight, I highly recommend doing this. Smaller, singular appliances should be fine with the 5A rated units but check your documentation. I have seen folks out there wire what is intended to be an inline (in the wall) 20A filter into a power strip and use this instead. It is cheaper than the 15A plug-in filters; it is also ballsier.

It didn’t take long for me to get interested in the security applications of X10. To start off I purchased a security console (PS561) and two cheap magnetic sensors (DS10A). The security consoles seem to operate using a proprietary (non-X10 specification) wireless protocol. Sensors and remotes are configured using two-button authentication; first the console is put into a programming mode then the test button or equivalent is pressed on the device to be registered. This particular unit will dial up to 4 numbers until one of the dialled people presses 0 to confirm they are listening to the call. At that point one can listen in on what’s happening in the vicinity of the console. This is severely hindered by the fact that there are two piezoelectric sirens mounted in the same chassis going off at the same time (and optionally additional alarms).

Like an idiot I didn’t realize the console would not come with at least one controller. This set back installation by T+shipping.

The peizo sirens in the security console don’t penetrate much farther than the room it’s in if the door is closed. Apparently the solution to this is throwing more sirens at it. I purchased the X10 PowerHorn (SH10A) which can be installed anywhere in the house by plugging it into the mains. The security console is configured to send alternating on and off commands to a certain house and device code. The original purpose of this was to flash lights on and off to make your house more visible to law enforcement. The PowerHorn takes advantage of this by sitting on the same house and device code as your lights and waiting for a pattern of on and off codes to activate. This sort of brute-force approach has two major limitations: the PowerHorn will lag behind your security console when the alarm is tripped and if you turn the lights with the same code on and off too many times too quickly by hand you can easily produce a false positive. This happened to me twice at poorly chosen hours before I decided to live without the horn. It deactivates shortly after the alternating pattern ceases.

I find the door sensor I installed falls out of sync once every two months or so; this is inconvenient enough to make it not worth using. Often I just don’t have the time to re-program the unit when I’m on my way out the door.

  • XPPA Plug-In Filter Module – A grounded, 5 amp plug-in X10 signal filter.
  • SS13A 3 Unit + Dim RF Style Switch – A wireless X10 switch that can be mounted anywhere
  • SC546A Remote Chime – A doorbell-type module which responds to the ON command

To use the SS13A modules as doorbells I had to open them and slice out the rubber tab that produces the rocker-switch effect that makes one side of the button “on” and the other “off.” I then taped over the “off” contacts on the circuit board so no matter what side the button is physically pressed only the “on” command is sent.

The 15A filters helped my signal problems a lot but there was still the odd blip in service so I went ahead and bought two 5A filters to dick around with. The chimes take a simple on command and – contrary to some advertising – have only one, non-selectable “melody.” The wireless switches can be programmed to take any 3 consecutive key IDs and any of the 16 house codes. The bottom button is a toggle pad for bright and dim commands. The cool thing about them is they stick on to the wall using an adhesive backing and are thin enough to provide the illusion that they are the faceplate of a recessed electrical box without having to smash into the wall. They take a CR-32 battery in the bottom tray and communicate using the RF->mains receiver.

My final purchase was the MT13A Mini Timer. I had for some reason been under the impression that the PalmPad remote would be able to act as a timer, which was one of the main reasons I became interested in X10: it would be possible to automatically turn off the lights when I pass out with them on. I didn’t have the time to do anything really sophisticated with computer automation and I needed a new alarm clock so I ponied up, plugged it in and never touched it again. I’m sure it’s great, I just wouldn’t know.

Controlling X10 Devices with your Computer

Obviously the really sweet part about Home Automation is interfacing your house with your computer. For about $5 you can pick up a wireless transmitter called a FireCracker (CM17A) that works with standard X10 wireless receivers and takes instructions from a standard serial port. I have found that there is an issue with the internal timing on one of my USB-serial cables’ particular chips. The transmitter uses pins not normally used by serial devices to transmit data so it can be transparently daisy-chained with another serial device behind it. I have read that some USB-serial adapters drop one or more of these pins. If your USB-serial adapter does not seem to work with the transmitter be sure to do your research before selecting another one.

Other versions exist for USB which plug directly into the wall. I can only guess as to whether or not these use an embedded USB->serial adapter (linux compatible) or if they are intended for use with Windows based home automation software.

There are a couple of packages that can drive the FireCracker but I have only used bottlerocket

To compile on Gentoo run:

# emerge bottlerocket

Bottlerocket takes these options:

Usage: br [<options>][<housecode>(<list>) <native command> ...]

  Options:
  -v, --verbose                 add v's to increase verbosity
  -x, --port=PORT               set port to use
  -c, --house=[A-P]             use alternate house code (default "A")
  -n, --on=LIST                 turn on devices in LIST
  -f, --off=LIST                turn off devices in LIST
  -N, --ON                      turn on all devices in housecode
  -F, --OFF                     turn off all devices in housecode
  -d, --dim=LEVEL[,LIST]        dim devices in housecode to  relative LEVEL
  -B, --lamps_on                turn all lamps in housecode on
  -D, --lamps_off               turn all lamps in housecode off
  -r, --repeat=NUM              repeat commands NUM times (0 = ~ forever)
  -h, --help                    this help

          is a comma separated list of devices (no spaces),
                each ranging from 1 to 16
      is an integer from -12 to 12 (0 means no change)
     is a letter between A and P
    is one of ON, OFF, DIM, BRIGHT, ALL_ON, ALL_OFF,
                LAMPS_ON or LAMPS_OFF

For native commands,  should only be specified for ON or OFF.

In order to control the lights with a meta key on my mouse I had to wrap this in a little script so the KDE shortcut manager could reference it correctly:

mdma bin # cat x10on
#!/bin/bash
br -x /dev/firecracker k2 on

Where /dev/firecracker is, in my case, a symlink to /dev/ttyUSB0.

I’ve noticed that the device has little or no buffer; sending too many commands too quickly will cause the device to cease functioning, possibly temporarily. Unplugging and re-seating it seems to solve the problem every time. The lack of built in buffer or command queue (indeed, even the ability to ignore commands while one is being transmitted) is something which should probably be addressed in controller software or front-ends.

Neat Stuff I Wanted to Play With But Never Got the Chance

The coolest part about X10 if you’re a real geek is its ability to remotely turn on or off anything that has an on or off switch through your house’s existing wiring.

The so-called universal modules allow you to wire directly into an existing switch. They can be configured for normally open or normally closed operation. This means that you can control virtually any device which does not natively support X10 or remote control like, say, your old garage door opener. Or a hydroponics pump.

Just sayin'.

Coupled with computerized control it would not be hard to make a web interface that controls your coffee maker, or other sinister devices.

Conclusions

Since most houses have their three-phase input split into two two-phase segments signals from one side of the house may need to travel all the way down to the transformer at the end of the road then back into the house, by this time severely degraded. To remedy this a repeater can be installed across the phases at the breaker panel (about $30) but this is “serious business” and should only be performed by a real electrician. The safer alternative is a $100 (depending on three or four prong configuration) repeater that plugs into the dryer or stove outlet.

I look forward to trying one of the newer home automation protocols in the future. X10 is slow to the point of agony. To dim a 100W light bulb from maximum to minimum takes about a minute of repeat pressing on the buttons. The controllers either do not auto-repeat when the buttons are held down or they repeat so quickly the messages become garbled on the wire. In support of this theory, I have found that clicking the dim button then waiting for the reaction before clicking it again is far faster than mindless rapid clicking. This, combined with the poor quality of the entry level security modules and lacklustre signal performance make X10 a labour of love in my most humble of opinions.

 

Return top
foxpa.ws
Online Marketing Toplist
Internet
Technology Blogs - Blog Rankings

Internet Blogs - BlogCatalog Blog Directory

Technology blogs
Bad Karma Networks

Please Donate!


Made in Canada  •  There's a fox in the Gibson!  •  2010-12