The old X10 devices were getting really unreliable: seldom firing at all, getting far too hot, bringing a whole lot of not working to my life. So while it was kind of cool to have my lights controlled by an original 256 MB Raspberry Pi Model B from 2012, it was maybe working one schedule out of ten.
So it had to go: replaced by a Raspberry Pi Zero W and a whole lot of IKEA TRÃ…DFRI kit. I was deeply unimpressed with the IKEA Home smart app, though: you couldn’t use even basic schedules with more than one light cycle per day. So while I know there are lots of clever home automation systems, I wanted to replace my old cron scripts and set about writing some simple command tools. The result is ihsctrl: very limited, but good enough for me. It’s been working exactly as expected for the last week, so I’ll finally get to wade through 8 years of cobwebs and dismantle the old X10 setup. I already miss the 06:30 clonk of the X10 controller turning the front light on â€” that was my alarm clock (or alarm clonk) every morning.
Now I’ve got my X10 system running and know its limitations, I could have saved a wheen of money not buying stuff I don’t need. Our house appears to have been wired by an, um, spirited amateur, so powerline signalling is of limited use. Thankfully, the tiny and cheap X10 FireCracker CM17A (warning: too many flashing GIFs at this link!) can be driven from heyu [previously]. You can score these on eBay for under $10, and all you need is a serial adapter to drive them.
The really cheap bit in my system was discovered in Active Surplus. I found a case of Leviton “Plug-in Frequency Transceiver Modules” for $4/each. One was out of its case, and wouldn’t you know it, it’s the same as a RR501 module, which typically retails for about $30. Sure, these are old stock and are a nasty beige colour, but they provide a way of switching a two-pin appliance. They can also relay remote commands from RF to wired controls.
The only X10 controller I can’t get to work with the Raspberry Pi is the CM19a USB PC Transceiver. I suspect it draws a bit too much power to run from a Raspberry Pi, as it makes the machine unresponsive if it’s plugged it. Running from my bench setup it works fine with the mochad driver, but no dice with the other machine. The CM19a reads wireless RF X10 commands, and it would be useful if I’d added a motion sensor. As is, I’ll stick to the lights going on and off.
(Update: there’s a good chance that my CM19a problems are down to the ancient dwc_otg* fixes I still run on my Raspberry Pi’s kernel. You probably don’t need them, and this device could work fine. One day I will find time to fix ’em â€¦)
(Incidentally, this is the “North American Edition” because X10 RF controls are completely different in Europe, and none of the above is useful to you. Yeah, I know this article is the equivalent of PC Load Letter to you; sorry.)
Yep, springtime’s coming, and today’s the first day I know it, despite the -5.8Â°C outside. I know spring is coming because my sunrise-adjusted lights came on before my alarm today. I’m controlling them with a Raspberry Pi, cron, and X10.
I’d described how to build and use heyu previously, so I won’t go into it further. I use sunwait to control the timing relative to local sunrise and sunset. Sunwait is a simple C program which builds quickly, and you can put the executable somewhere in your path.
(NB: newer versions of sunwait use a completely incompatible command line format. Everything here refers to the 2004 version I linked to above, which does exactly what I need in the way it’s described here.)
You need to know your latitude and longitude to use sunwait. To check its setting for the day, you can call it with the -p option:
$ sunwait -p 43.729N 79.292W
Using location:Â Â Â Â Â Â Â Â Â Â Â Â 43.729000N, 79.292000W
Date:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 6 Feb 2013
Local time:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 7:44
Day length:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 10:13 hours
With civil twilightÂ Â Â Â Â Â Â Â 11:10 hours
With nautical twilightÂ Â Â Â Â 12:18 hours
With astronomical twilightÂ 13:25 hours
Length of twilight:Â civilÂ Â 0:28 hours
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â nauticalÂ Â 1:02 hours
Â Â Â Â Â Â Â Â Â Â Â Â Â astronomicalÂ Â 1:35 hours
Current specified time zone: EST (-5 from UTC)
Sun transits meridian 1231 EST
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Sun rises 0726 EST, sets 1736 EST
Â Â Â Â Â Â Civil twilight starts 0656 EST, ends 1806 EST
Â Â Â Nautical twilight starts 0622 EST, ends 1840 EST
Astronomical twilight starts 0548 EST, ends 1913 EST
So for me, today’s sunrise is at 0726, and sunset is at 1736. All sunwait does is wait until a specific solar time is reached, and then exit. Whatever command you call after sunwait, therefore, is what gets run at the right time. So if I wanted X10 device H1 to come on an hour before sunrise, I’d run:
sunwait sun up -1:00:00 43.729N 79.292W; heyu on h1
Remembering to run this every day before sunrise would be a pain, so this is where cron helps. cron uses a slightly odd config file that is edited using the crontab -e command. Here’s the relevant bit of my crontab, showing the light control times:
# m hÂ dom mon dowÂ Â command
Â 01 00Â Â *Â Â *Â Â *Â Â /usr/local/bin/sunwait sun up -1:00:00 43.729N 79.292W; /usr/local/bin/heyu on h1
Â 02 00Â Â *Â Â *Â Â *Â Â /usr/local/bin/sunwait sun up +1:00:00 43.729N 79.292W; /usr/local/bin/heyu off h1
Â 03 00Â Â *Â Â *Â Â *Â Â /usr/local/bin/sunwait sun down -1:00:00 43.729N 79.292W; /usr/local/bin/heyu on h1
Â 45 22Â Â *Â Â *Â Â *Â Â /usr/local/bin/heyu off h1
(you can view your crontab with crontab -l)
The columns in crontab are:
day of month
day of week
So the four crontab lines mean:
Every day at 00:01, wait until an hour beforesunrise and turn light H1 on
Every day at 00:02, wait until an hour aftersunrise and turn light H1 off
Every day at 00:03, wait until an hour beforesunset and turn light H1 on
At 22:45, turn light H1 off.
So for quite a bit of the day, there are a couple of sunwait tasks just quietly waiting until sunrise or sunset to do their thing. cron, incidentally, is picky about executable paths; that’s why I specified full paths to both sunwait and heyu.
What I’d really like to do is have time on this machine update without a network connection, because it’s running from a particularly messy router set up in a spare bedroom. I should investigate a real-time clock, with GPS time updates from an IÂ²C GPS, talking through a bluetooth console. In my copious free time, of course.
I never quite get the hang of setting timers for lights. Either I forget daylight savings completely, or I set something so general that I find the lights coming on mid-afternoon when it’s still light. Minor annoyances require the over-application of technology, and fast!
I scored an X10 ActiveHome Starter Kit for cheap(ish) on eBay. X10 is a pretty old technology (1970s! Scottish!) and has some severe limitations (slow! prone to interference! unencrypted!) but has a large user base, and did I mention it’s pretty cheap?
The key component of a computer controlled X10 system is the CM11 computer interface. It takes serial commands from a computer, and pushes them out (slowly) as signals modulated over your house wiring. Various plug-in modules pick up these signals, and if the device address in the command matches that of the module, the module turns on (or off, or dims).
Since the version of the CM11 interface that I have is serial, I’ll need a USBâ†’Serial converter. All I had lying around was a very old Prolific PL2303 interface, which works fine with Raspbian, but I’d prefer an FTDI one for more reliability. Long-term stability of USB Serial on the Raspberry Pi is currently questionable; there’s some good discussion on kernel parameters that might help.
To send X10 commands from a Raspberry Pi (or indeed, any Linux computer) you need heyu. You have to build it from source, but the instructions are clear, and it takes about 10 minutes to build on a 256 MB Raspberry Pi. The install script asks you where your serial port is, and for my device it is /dev/ttyUSB0.
(Update: I re-imaged the Raspberry Pi that runs these tasks today and rebuilt heyu without success. Don’t assume you can do a ./configure; make; sudo make install here. You have to run heyu’s own ./Configure.sh first before make. It does some non-obvious magic. Read the README and you’ll be fine, unlike me …)
Most of the lights in our house are fluorescent, which is a problem for the standard X10 lamp modules. CFLs are not dimmable, and the standard lamp module doesn’t work with them. The lamp modules don’t work very well with low-voltage halogen lamps, either; extreme buzzing ensues, with a faint brownish light oozing out from the bulb and a vague burning smell. Best avoided, and better to use an appliance module, which is a simple mechanical relay.
The only controller that came with the kit that would work with my lights was the X10 transceiver, which also includes an appliance switch. I gave this device an address of H9 (house code H, unit code 9), and plugged in a lamp. To turn it on, I issued this command:
heyu on H9
After about 8-10 a couple of seconds and a loud CLUNK from the controller’s relay, the light came on (if it’s taking longer, read this comment). To turn it off, I told it:
heyu off H9
Whoa! Raw power! I can now turn AC devices on and off from my Raspberry Pi (Martin Creed, watch out!). I guess I could set up cron jobs to control the lights, but cron doesn’t know about solar time (Sunwait and SunCron do, if you want to futz with them). I’ve got MisterHouse running on the Raspberry Pi for more clever control, but more on setting that up later.
Incidentally, if you’re in Europe, Marmitek sell a variety of 220 V 50 Hz X10 modules. Their website is much clearer than the angry-fruit-salad that is x10.com. It looks like X10 have updated their starter kit to include the newer CM15 USB interface which will likely not work with heyu.