web statistic EvilLawnGnome.com » Using X10 Home Automation and Linux to manage your home internet connection

Using X10 Home Automation and Linux to manage your home internet connection

Blogged by Brian as Main — Brian Wed 20 Jun 2007 11:05 am

I've been using SBC/Yahoo!/AT&T DSL for quite a while now, and i'm more or less satisfied with my service. My one complaint would be that my modem tends to flake out now and again. Who cares, right? Me. I run a linux server behind my DSL. I use it as a jumpbox, a private fileserver, an audio streamer, and i manage my torrents from it. Under most circumstances, i would simply call up AT&T and request that they troubleshoot my modem. However, i know that this is going to be a painful process. They aren't going to like that i use a dedicated Linux PC as my router - they will want me to hook up the modem directly to my PC, or buy an "approved" broadband router. So, you say, "Lie to them! Tell them it's all hooked up like in the manual!" They'll want me to run the "software" that came with the modem - little more than glorified spyware. Not gonna do it. Failing that, theyll want to spend a half hour doing meaningless tests that i've already done. I'll have to listen to them tell me how to ping and run ipconfig. It will be an hour of frustration that i just don't need.

Instead, I've devised my own needlessly complicated solution: Monitor the internet connection via shell script, and power cycle the modem with a couple of X10 home automation modules fit the internet is unreachable.

Summary:

1. Get a couple of x10 modules
2. Hook a lamp module up to the cable modem and the transmitter module up to a linux pc
3. Write a script that checks the connection to the internet and power cycles the modem if necessary
4. Set the script up to run every five minutes via cron

The modules

I did a google search for "linux x10" and found Heyu (http://heyu.tanj.com/), an actively developed set of tools for the X10 protocol in linux. Looking at the supported devices, i popped a couple of those in to amazon, and a few days later, i had myself a CM11A and an LM14A module.

NOTE:
Some people (Eric and Neil) are saying that the LM14A may not be appropriate for this job. Personally, i find that it's working just fine, and i'm not to concerned if it lowers the life of my modem - at that point, i'll replace it. This added functionality is worth it, and the functionality comes with minimal input effort. Read the comments if you are concerned that the LM14A may reduce the life of your modem. Additionally, GrinningArmor advises, "Any X10 module being plugged to the battery-powered output of an UPS is not likely to work, and could be burnt," and i agree with him. Your mileage may vary, but please be aware of these factors when making your decision on implementing this solution, and when choosing a module.
The CM11A plugs in to the computer via serial port, and the LM14A simply plugs in to the wall. The modem is then plugged into the wall module, and we are, for the most part, done. The wall module needs to have an address, and I left this module set to A1 for simplicity. (Further details about the X10 system are out there; they are simply beyond the scope of this document.)

The software

I chose Heyu because it was command line based, and therefore, easy to script. I'm running Ubuntu Feisty on my router, and Heyu wasn't available through apt-get. However, compiling the source required minimal effort. Up until now, this computer had no need to compile source code, so i had to install the toolchain. That's easy enough:

PLAIN TEXT
  1. apt-get update
  2. apt-get install build-essential

The next step was to configure / make / make install.

PLAIN TEXT
  1. cd /directory/with/source
  2. ./Configure
  3. make
  4. sudo make install

Heyu is now installed and can be accessed like any other command. Heyu is a complete X10 toolset, but there were only two commands i needed:

PLAIN TEXT
  1. heyu on A1
  2. heyu off A1

The basic functionality was there - i heard the wall module click on and then back off. Now, all i need to do is script up an internet check script.

The script

I've done a little programming in the past - at least enough to know that this is a ... wordy way to do things. This script could be optimized in a number of ways, but considering the simplicity of function, i'm fairly satisfied with the results. Below is the exact script i use to check for a valid internet connection, and power cycle the modem if necessary:

PLAIN TEXT
  1. #!/bin/bash
  2. #logger -t intertest "Beginning outbound connectivity test..."
  3. ERRORS=0
  4. ping -q -c1 -W1 208.67.217.230 &> /dev/null
  5. let "ERRORS = $ERRORS + $?"
  6. ping -q -c1 -W1 216.91.182.78 &> /dev/null
  7. let "ERRORS = $ERRORS + $?"
  8. ping -q -c1 -W1 69.147.114.210 &> /dev/null
  9. let "ERRORS = $ERRORS + $?"
  10. ping -q -c1 -W1 216.74.180.189 &> /dev/null
  11. let "ERRORS = $ERRORS + $?"
  12. ping -q -c1 -W1 69.63.176.13 &> /dev/null
  13. let "ERRORS = $ERRORS + $?"
  14.  
  15. if [ $ERRORS -ge 5 ]; then
  16. logger -t intertest "FAILED OUTBOUND INTERNET PING TEST! THE MODEM WILL NOW POWER CYCLE!"
  17. logger -t intertest "Beginning power cycle..."
  18. heyu off A1
  19. sleep 2
  20. heyu on A1
  21. if [ $? -eq 0 ]; then
  22. logger -t intertest "Done. Modem was power cycled successfully."
  23. else
  24. logger -t intertest "ERROR: Unable to power cycle the modem. We are screwed."
  25. fi
  26. logger -t intertest "Done. Cycling outbound interface [eth3]"
  27. logger -t intertest "Power nap before cycling eth3..."
  28. sleep 8
  29. logger -t intertest "Waking up, cycling eth3..."
  30. ifdown eth3 &> logger
  31. ifup eth3 &> logger
  32. logger -t intertest "MODEM POWER CYCLE COMPLETE! Stirring the pot..."
  33. ping -q -c1 -W1 208.67.217.230 &> /dev/null
  34. ping -q -c1 -W1 216.91.182.78 &> /dev/null
  35. ping -q -c1 -W1 69.147.114.210 &> /dev/null
  36. ping -q -c1 -W1 216.74.180.189 &> /dev/null
  37. ping -q -c1 -W1 69.63.176.13 &> /dev/null
  38. #else
  39. #       logger -t intertest "Connectivity check OK."
  40. fi

Let's take a look at this one section at a time.

Section one: Check for an internet connection:

PLAIN TEXT
  1. #!/bin/bash
  2. #logger -t intertest "Beginning outbound connectivity test..."
  3. ERRORS=0
  4. ping -q -c1 -W1 208.67.217.230 &> /dev/null
  5. let "ERRORS = $ERRORS + $?"
  6. ping -q -c1 -W1 216.91.182.78 &> /dev/null
  7. let "ERRORS = $ERRORS + $?"
  8. ping -q -c1 -W1 69.147.114.210 &> /dev/null
  9. let "ERRORS = $ERRORS + $?"
  10. ping -q -c1 -W1 216.74.180.189 &> /dev/null
  11. let "ERRORS = $ERRORS + $?"
  12. ping -q -c1 -W1 69.63.176.13 &> /dev/null
  13. let "ERRORS = $ERRORS + $?"

These IP addresses resolve to google, yahoo, hotmail, savvis communications, and facebook. You can select your IPs differently if you choose, but it wont really matter. The script will only power cycle the modem if all 5 pings fail. Speaking of pings, these aren't your garden variety pings.

-q is quiet
-c1 is to send one packet
-W1 is a one second timeout
&> /dev/null redirects stdout and stderr to the black hole.

We redirect the output to /dev/null because we don't really care about it. What i'm looking for is the exit status of ping - 0 if a reply is sent, 1 if no reply is sent. This section of code tallies up the exit codes using the special variable $? which contains the exit status of the last command.

Section two: Error handling (the meat and potatoes)

PLAIN TEXT
  1. if [ $ERRORS -ge 5 ]; then
  2. logger -t intertest "FAILED OUTBOUND INTERNET PING TEST! THE MODEM WILL NOW POWER CYCLE!"
  3. logger -t intertest "Beginning power cycle..."
  4. heyu off A1
  5. sleep 2
  6. heyu on A1
  7. if [ $? -eq 0 ]; then
  8. logger -t intertest "Done. Modem was power cycled successfully."
  9. else
  10. logger -t intertest "ERROR: Unable to power cycle the modem. We are screwed."
  11. fi

The first if begins the test of our error count. If it is greater than 5, it is safe to say that the internet is out. Less than 5, it could be that hotmail was being DOS'ed, or any number of other reasons why a site is unreachable. We only want to cycle the modem if we are SURE that the internet is unreachable.

Logger is a handy command to write an entry to the syslog - this way i can look back and see when or how often the internet failed.

The next command you'll see is the Heyu command. We turn it off, and wait a couple seconds to make sure everything is drained before bringing it back up. I'm sure the manufacturer would like me to wait 5 minutes before turning it back on, but the manufacturer also made a crappy modem, so that shows how much THEY know.

We check the exit status of heyu on the second command to see if the modem was cycled properly. This way i can see in my log if the heyu command failed.

Section three: reset the outbound ethernet connection

PLAIN TEXT
  1. logger -t intertest "Done. Cycling outbound interface [eth3]"
  2. logger -t intertest "Power nap before cycling eth3..."
  3. sleep 8
  4. logger -t intertest "Waking up, cycling eth3..."
  5. ifdown eth3 &> logger
  6. ifup eth3 &> logger

I found that sometimes after the modem was up, i was still experiencing connection issues. "Flipping" the interface seemed to resolve the issue. We log that we are about to do it, then wait a few seconds to give the modem a chance to warm up. At that point, we proceed, piping the output to logger.

Section four: Priming the pump

PLAIN TEXT
  1. logger -t intertest "MODEM POWER CYCLE COMPLETE! Stirring the pot..."
  2. ping -q -c1 -W1 208.67.217.230 &> /dev/null
  3. ping -q -c1 -W1 216.91.182.78 &> /dev/null
  4. ping -q -c1 -W1 69.147.114.210 &> /dev/null
  5. ping -q -c1 -W1 216.74.180.189 &> /dev/null
  6. ping -q -c1 -W1 69.63.176.13 &> /dev/null

We repeat the ping exercise, except this time, we don't care about the return. All this does is generate some internet traffic to get the modem to establish a connection to the internets.

Section last: Fin

PLAIN TEXT
  1. #else
  2. #       logger -t intertest "Connectivity check OK."
  3. fi

This section is mostly commented out. I had it enabled for about ten minutes to make sure that the script was actually running. I commented it out so that if the check is successful, no output is generated. "fi" ends the if statement we began so long ago, and also ends our script.

The cron job

With the script written, the last step is to set it up as a cron job that runs every five minutes. As root,

PLAIN TEXT
  1. crontab -e

and insert the following:

PLAIN TEXT
  1. # m h  dom mon dow   command
  2. 0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/bin/intertest

This sets up the intertest command (my script) to run every five minutes, every hour, every day of the month, every month, every day of the week. This concludes the installation.

And this also concludes the how-to. I hope you enjoyed it.

21 Comments »

  1. Comment by Doug — June 22, 2007 at 5:11 pm

    I had a similar problem but opted for a brute-force solution. I took a programmable power timer and wired it to cycle the power to my cable modem once an hour. I only needed to turn the power off for a couple of seconds at most and my modem boots back up in less than 15 seconds. Cheap and dirty, just the way I like it.

  2. Comment by wally — June 22, 2007 at 5:27 pm

    Interestingly I'm just working on the same idea for our ADSL modem which stops working due to a weak signal. Not having the money to fork out on such sweet hardware as yourself however, I'm considering using a serial port, transistor and relay to do the job :) I'll blog about it if I ever get it working.

  3. Comment by Eric — June 22, 2007 at 7:41 pm

    That's a fine implementation software-wise, but the LM14A is not rated for use with non-incandescent bulbs; the switching power supply may cause problems. I would use an AM466 Appliance Module instead.

  4. Comment by Dave — June 22, 2007 at 8:38 pm

    Great idea. I have a similar problem with my PacBell/ATT DSL line getting messed up once in awhile. I need to powerdown etc.

    Thanks..Dave

  5. Comment by jay — June 22, 2007 at 9:06 pm

    Very simple as you have proven, but awesome, I have similar issues w. My dsl modem. I have a linux box, now just need some x10 devices...damnit!

    Great job!

    Jay

  6. Comment by Brian — June 22, 2007 at 9:10 pm

    Eric,

    I've not looked at the power supply in a while (its tucked back behind the server rack (and by "server rack" i mean Black and Decker Shelves In My Room)), but i pulled it out to do a little math.

    A standard incandescent bulb is around 60 watts.
    The output from the power supply is 12vdc @ 500ma. That works out to 6 watts.

    I think this module will do just fine. :)

  7. Comment by Fred — June 22, 2007 at 10:01 pm

    To be way less verbose, use "5* * * * * /usr/local/bin/intertest" to get it to run every five minutes.

  8. Comment by tzizimine — June 22, 2007 at 10:44 pm

    Only problem with this is that some cable companies do not do honor a DHCP request by only a power cycle. Often the modem needs to think it's in an outage, meaning it has power but no coax connection before it requests a new DHCP lease. I work as tech support in New England for a cable provider, handing this exact kind of issue.

  9. Comment by Daleus — June 23, 2007 at 5:49 am

    My cable modem has a page on its own built in http server which when accessed says "Are you sure you wish to power cycle" hit it and the modem reboots. surely that must have been easier and cheaper, this feature isn't advertised but it was just at *ip*/reboot.htm

  10. Comment by GrinningArmor — June 23, 2007 at 6:46 am

    Nice idea. But are you running that server without an uninterruptible power supply?
    I have a Linux personal server running 24/7 too, but mine is protected from AC spikes and thunderstorms through an UPS. Both the server and the modem are plugged to the UPS.
    Any X10 module being plugged to the battery-powered output of an UPS is not likely to work, and could be burnt.

  11. Comment by Neil Cherry — June 23, 2007 at 8:21 am

    I know you said that the X10 is beyond the scope of this document. But don't use the LM14A, it's a lamp module and it uses an SCR to control the power going to the appliance. Appliance with power supplies don't like getting this modified power (the SCR cuts off part of the AC signal). This can cause the death of your appliance. It's OK for lamps (what it's intended for). Second thing is that the applaince module, such as an AM14A, uses leakage current to monitor for manual on/off of the appliance. What this means to you is that the modem won't really turn off. To fix this visit:

    http://www.geocities.com/idobartana/Modifying_Appliance_module.htm#Modifying%20appliance%20modules%20for%20local%20control

    You just need to clip the appropriate diode and you'll fix the problem.

    And yes I know what I'm talking about. I wrote the book: "Linux Smart Homes For Dummies" and I have a chapter on using X10 to control a printer in a similar manor. :-)

  12. Comment by Brian — June 23, 2007 at 10:39 am

    Neil,

    Thanks for the update. It sounds like you may have a little bit more experience with this than i do. ;-) Since what you're saying means that this could possibly effect the life of the modem, i have added a notice in the how-to warning people as such. As i state in the new section, I'm willing to risk it, but it's not fair not to warn people. I'm keeping my setup, and i'll be sure to update the page if it fries. :D

  13. Comment by matt — June 23, 2007 at 1:44 pm

    I can't speak for a DSL modem but I work for a cable internet provider. If there was some sort of neighborhood problem going on the modem would of course act odd and possibly lose sync. Powercycling the modem forces it it re-ask for how it is supposed to operate. If it was a simple outage then yeah, I can see this working out good for you. If this is a intermittent issue such as any number of a hundred things starting to fail in your neighborhood you power cycling your modem constantly is going to screw up the diagnostics screens we check and cause all sorts of headaches. If the problem happens more then once, get on the phone, refuse to diagnose the issue for some reason or another and make them roll a tech. a few minutes lost but a far better solution.

    Of course if this powercycle is a once a year thing then by all means, do this trick.

    Again, I don't know anything about DSL aside from how much I dislike it. Cable is the way to go.

  14. Comment by bubbafunk — June 24, 2007 at 10:46 am

    dude, i did the same thing about a year ago, except i used a pic micro, i was super pissed at my isp, blaming them for a poor connection.. they sent tech after tech out to tell me everything looked fine, WE BOTH WERE WRONG! i promise you that your getting a bad cable in connection to your modem, if you have ANY weak links in your cable distribution, your modem will flake out. ie a splitter in a "star" pattern... you need to put your modem as close to the signal comming into your house or apt as possible by putting in on a three way splitter (at the drop if possible!) and using as short as possible cable to first the modem, then run the rest of your house off the other line, splitting it as needed. use quad-shield RG-6 for EVERYTHING! sadly its your problem if the wiringin your pad is poor, not the isp.. dsl users are well, dsl users, sorry guys... maybe trying the same thing with your phone lines will work as well?

  15. Comment by Brian — June 24, 2007 at 11:18 am

    All, this is a DSL connection. During an "outage" that i am experiencing, the lights on the modem will indicate that everything is fine. HOWEVER, i will be unable to reach the internet, and, any attempts to pull up the modem's configuration page at 192.168.0.1 will fail. This tells me the modem has locked up and needs to be power cycled.

    Matt,
    Cable in st. louis is TERRIBLE. The speeds are nice, but there are frequent service interruptions from the only cable ISP in town, Charter, and their customer service is the worst thing i have ever experienced. I am quite happy with my DSL reliability. My modem flakes out maybe once a week, and once this solution ceases to be a solution, i will spend the requisite hour on the phone with AT&T getting them to replace my modem.

  16. Comment by carlton — June 24, 2007 at 1:25 pm

    As mentioned by a previous poster, I would have just gone with a simple parallel port device with a relay and a transistor to drive the relay coil (or just a solid-state relay). That'd be wicked cheap. And if you're already running linux, making a simple device driver (especially for a parallel port device) is really cake. Really, would only take like 5 minutes (if you know what you're doing), or less than a day (if you've never written a device driver for linux before).

    Just my two cents for anyone else planning on doing this.

  17. Comment by Steve — June 25, 2007 at 6:04 am

    I had the same problem with SBC/Yahoo!/AT&T DSL flaking out once at least once a week (and I'm also in the St Louis area and run linux). Power cycling the modem was the only cure.

    3 weeks ago I had multiple lockups on a Saturday and installed a different modem from one of SBC's self-install kits I had sitting around. Replacing the Speedstream 5100 with the 5260 seems to make all the difference. No lockups since, no impact on speed (4500 kb/s download), just better reliability.

  18. Comment by Winston — June 25, 2007 at 9:52 am

    For all the people about the LM14A, it shouldn't cause a problem... all the power supply for the cable modem is is a transformer and a rectifier (aka diodes) to convert AC->DC... The modified wave of the scr and all that will just lower the output voltage a little, and shouldn't affect anything.. The cable modem itself will regulate the input dc to a lower regulated voltage internally. They do this because variances in the line current are normal, so they feed the modem with a higher voltage so that if you've only got 110 vac instead of 120, stuff will still work happily for your devices.

    Second, sometimes the flakiness of the cable modem is caused by the cable company.. Rogers here in Canada will cause purposeful disruption of your connection if they detect certain download systems.

  19. Comment by Insolence — June 25, 2007 at 3:04 pm

    Commenting on carlton's recommendation, I actually did this 4-5 years ago for a client who's DSL would die about once a week and require me to drive for a hour to mindlessly unplug it for a minute and plug it back up. I used a existing linux server there that was sharing SMB and was their gateway, and made a simple parallel relay. I just wrote a simple script to run every 5 minutes in cron that pinged random reliable sources on the internet (google, msn, etc.) if one failed, it would try two other reliable sources, and if those failed, it would power off the DSL modem for a minute and power it back on. The project in all cost me less than 9 bucks from a local electronics store. :) Nice quick and dirty hack. :)

    - I

  20. Comment by muffin — June 26, 2007 at 4:27 pm

    I have a similar problem with my SBC DSL connection (that I am quite happy with, best upload rate for the price). It seems that before the connection crap out entirely it goes though a "fuzzy" period where anything bigger than text only Google is too mangled to be read. Images time out 90% of the time but text will still pop through. IMHO wget-ing something like the Google banner or your local weather stations radar images would be a better test of connectivity than pings. Nice idea though, they should just send one of these out along with the modem.

  21. Comment by Deb Reppenhagen — January 9, 2008 at 4:00 pm

    Can anyone translate this for use with a plain old windows (XP) PC?

    I have COMCAST cable internet. I have it hooked up to my LYNKSIS wireless router. The router has never had a problem. The modem needs to be restarted several times a day on some days but on the average only several times a week. A few times, the modem ran for weeks without a problem. I've tried different Modems without result. Calling Comcast does no good. I don't think they even log these kinds of issues; they're out of the picture if restarting the modem gets you running again. This has been going on for years.

RSS feed for comments on this post. TrackBack URI

Leave a comment

Proudly powered by wordpress - Theme Back in Black 2 by neuro