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
(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
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.
8-10 seconds? Crikey. Is that an X10 thing? I had imagined it would be much faster given that it seems to be popular standard.
Such a delay is quite off-putting for anything like voice command – unless you factor it in by adding a voice response saying “now switching on the main entrance all light” (er, very slowly.. and probably with some bleeps!) it’s not going to impress mates or make them envious. Which of course is the point of all this 😀
Powerline X10 is really slow, Drew; it’s limited by the 50/60 Hz of mains electricity. Wireless X10 is a lot quicker, but there’s still a tiny delay.
Newer protocols like ZWave and Insteon might be faster.
Thanks for that info. I was offered the “Unifi” system, linked into wi-fi for control & usage reporting, when I switched to Scottish Power.
I can’t tell if the technology itself is good, but the implementation is pretty dreadful!
I’d been hoping for an API (maybe an outside chance anyway), maybe just a simple way to fire & receive commands – but in the end even the basics were poor. The website demanded so many clicks to tell it what to switch on/off and still didn’t always reflect the correct state.
Worst of all, after a power outage the plugs default to “on”. The very first example they give on their intro video is about leaving the iron on. http://www.youtube.com/watch?v=QrrBiu8iLfU – I shudder to think of potential consequences from connecting an iron in the hope of making things safer!
I suggest there is some problem with the way this was implemented, I’ve been using x10 on linux for years and although there is a perceptible delay its in the range of 0.5 to 1 sec, certainly not 10 seconds which frankly would have killed off the use of X10 years ago.
Yes, it was taking 15-20s to trigger over powerline with heyu. As is, I’d been ignoring the “RI serial line may be stuck” message which you (apparently) get with old PL2303 USB-Serial adapters like I’m using. Adding the line:
to .heyu/x10config got the delay down to about a second.
I came across this blog and had to respond. I know the post is a bit dated. I am a long, long time user of X10, heyu, and a electrical engineer. I’ve never seen the actual tranport latency of an x10 signal over a power line to be more than 2 seconds. Basically a one bit of information is sent on every power line cycle or every 0.016 sec. (60 Hz power line frequency). A complete ‘message’ is about 10 bits (IIRC), more or less, depending on the types of devices being used. Best case is 0.16 seconds. In my experience, the average is 0.4-0.8 seconds, depending on the activity of other x10 transceivers on the bus.
I am curious as to how you measured the signal latency. I’d bet that a good chunk of the time in the delay was the PI chugging along.
I am also a little surprised that you did not mention the scripting language in heyu and its vast set of capabilities, but instead, implied configuring a bunch of statements in cron and also referring to Mr. House (for more ‘clever’ control). I’ve used Heyu with both the scripting language and cron entries. The scripting language definitely fills the need for more ‘clever’ control scenarios and scene config and management.
Latency is under a second; the old problem was a heyu config conflict with the USB serial adapter.
I don’t use Mr House at all now; I’m pretty much doing what’s described here: hey, itâ€™s the sun â€¦ heyu and sunwait and cron on the Raspberry Pi â€“ We Saw a Chicken â€¦. As for heyu’s scripting, it would be another pointless script language to learn, while crontab I know. I know that this works, so why change?
Im a little late to the Pi party….
Im wondering if one you guys could give me some help or point me in the right direction?
Im trying to do what you guy’s have done by adding automation to X10, i have heyu installed and working, installed sunwait and cron.
I’m at a complete loss even after hours of web trawling as to “where” i write the and save the code for sunwait to function with heyu??
Where do i do it? i want to simply turn light A14 on 30 minutes before sun down and off 01.00 hour before sun up with Lat/Lon 52.879884 -2.108399.
Justin – It’s better explained here: hey, itâ€™s the sun â€¦ heyu and sunwait and cron on the Raspberry Pi â€“ We Saw a Chicken â€¦, but in the terminal, type
This brings up a text editor. Scroll down to the bottom of the file, and add these two lines:
01 00 * * * /usr/local/bin/sunwait sun up -1:00:00 52.879884N 2.108399W; /usr/local/bin/heyu off a14
02 00 * * * /usr/local/bin/sunwait sun down -0:30:00 52.879884N 2.108399W; /usr/local/bin/heyu on a14
Save the file (don’t worry; you don’t need to give it a file name, as the system has given crontab a temporary file somewhere) and exit the text editor. You can (and the first time you do it, should) check that cron knows about your jobs with:
This should list those two lines.
crontab syntax is a little (okay, a lot) cryptic, and my approach of having two jobs (one triggered at 00:01, another at 00:02: both before sunrise, anyway) firing off sunwait is just one way to do this. It’s got the disadvantages of not triggering until the day after you set it, and going off at any old time if your Raspberry Pi loses power, but it works for me.
Stewart, thank you so much 🙂
I read an read your blog post over and over but could not see the wood through the tree’s… Your explanation here (laymans term’s) was perfect and now it makes sense, i do feel exposed and trying to run before i can walk, but your “hand holding” just pushed me to the next stage, so big thanks from me 🙂
A question, if the Pi restarts do i need to restart sunwait and or will the crontab (job) run automatically?
I did try to see if i could understand the script to see if there is an auto run or auto start script / job.
Following Corey’s guide i made ha-bridge auto start, the reason i ask is sunwait is a program right.
I hear what your saying ref the pi losing power, ill know if it went off but ill know if i come home to darkness right lol.
Finally where is the best place to get the right format for Lat/Long?
pi@raspberrypi:~ $ sunwait -p
warning: latitude or longitude not set
default coords of Alexandria, Virgina, USA used
Using location: 38.794433N, 77.069450W
Date: 19 Nov 2017
Local time: 18:09
Day length: 9:57 hours
With civil twilight 10:52 hours
With nautical twilight 11:57 hours
With astronomical twilight 13:00 hours
Length of twilight: civil 0:27 hours
nautical 0:59 hours
astronomical 1:31 hours
Current specified time zone: GMT (0 from UTC)
Sun transits meridian 1653 GMT
Sun rises 1156 GMT, sets 2151 GMT
Civil twilight starts 1127 GMT, ends 2220 GMT
Nautical twilight starts 1055 GMT, ends 2252 GMT
Astronomical twilight starts 1023 GMT, ends 2324 GMT
Trial by fire 😉
Do i understand it correctly, again i dont see the words in the sunwait files…
You cannot set your own ‘default’ coordinates within sunwait but express them when you need an action?
When i check the status of sunwait with, $ sunwait -p (i need to put coordinates here) to get the report for my location, if i don’t it defaults to Virginia. However it will act on the coordinates in the crontab script?
Not quite following all your questions, Justin, but here’s what I understand:
Just saw your reply,
The issue i was having google maps was giving me a – number for long sunwait didnt like it… i couldnt find a site that would give me the format needed latitude/longigude expressed in floating-point degrees but i made it more complicated than it needed to be 😉
Sorry about that â€” I’ve been doing geo things for so long (even have my own abject blog about it: Numpty’s Progress | lost, to five decimal places) that I assumed everyone knew that negative longitude meant west, negative latitude south. It’s not obvious.