Can someone point me to as simple as possible a program controlled method of causing a CM11/12 etc type serial port controller (it's actually an ACT TI103 so it has no local memory or local macro capability) to send X10 commands from a Windows XP computer.
My DSL line periodically drops in a mode which requires the modem to be power cycled to reconnect. To made this automatic I want to use DynDNS Updater's feature of "run a program when public address can not be found" to trigger some Windows program which will send a power OFF and 5 seconds later a power ON to an appliance module ahead of the modem. Right now I can perform this manually via a phone call and touch tone commands to an X10 telephone responder
but automation of this process would be a great help in keeping my home servers and webcams on line when I am away from home.
Any thoughts and advice will be greatly appreciated.
Here is a zero-cost(except for time expended) solution native to XP and TI!03. Talking to a TI103 is different than to a CM11/12. This is for a TI103 (a better interface). Assuming that your ACT T103 is connected to com1 and its DIP switches set for 192000,n,8,1 (if not, change as needed).
You may need to fiddle with the 5000 value in the PING command to achieve a five-second delay. This line in the batch file pings the non-existent IP address 220.127.116.11 to create a nominal 5000 millisecond delay. In pre-W2K we could have used the choice.com command, but ABIK, that's gone in WXP, hence the workaround using PING.
4) Go to
and download the test software for the ACT TI103 ( compressed in TI103-SW.zip)
5) Unzip, install, and run to generate the ASCII commands that you need to include in next two files ( X10_OFF.txt and X10_ON.txt). This program generates the necessary check sums and provides a test-bed for communicating with X-10 devices through the TI103. See also
6) Create two files using notepad.exe named X10_OFF.txt and X10_ON.txt
X10_OFF.txt should contain the OFF command for your appliance module which will look something like this depending on the module address and resulting checksum::
X10_ON.txt should contain the ON command for the module which will look something like:
7) Put all three files in C:\\
8) Have DynDNS Updater run the file c:\\X10toCOM1.bat
Ah .. Good to know that there is a current, free Microsoft source for that external and so unlikely to get broken by some future patch (a particular sore point with me today as I futz with an auto-damaged server 2003 ... )
Download from here:
'Course with respect to the original poster's need, it might be said that adding an 11.7Mb download, yet another program install, and a raft of stuff to the computer is unnecessary.
Some might even say that the single ~30-byte lines we posted are " far more elegant" than another 11.7MB of MSBloat ;-)
It might also be said that I didn't pay close enough attention to the author, which, usenet or not, would be true ;-)
There is a useful po It may be "elegant" but it doesn't actually work within the scope of what I described ("solution native to XP and TI103" ;-)
To which you (Tony) responded:
I have directory C:\\Program Files\\Windows Resource Kits\\Tools\\ in PATH and C:\\Program Files\\Windows Resource Kits\\Tools\\sleep.exe in that directory, so it certainly works for me.
In my experience (and I make no claim that this is universally the case), one of the more avoidable frequent causes of programming errors (and in turn, of home automation failures) is unmet dependencies.
I've been bitten so many times by minor differences in computer setups that I instinctively avoid solutions that are apt to get broken with (eg) an OS upgrade. This goes back to the days of DOS when most machines were customized with all manner of handy-dandy *.com files and TSRs of various sorts.
In the case in point, if you upgrade the OS or transfer your HA stuff to another machine, the 'native' solution ( the batch file) that I offered, will still work. If you do the same with the sleep.exe external, and forget to add the external executable deep within a path, your program gets broken in an insidious way.
Because there is no functional difference between the two solutions, I
*greatly* prefer the robust, 'native' one to one that is susceptible to getting broken -- especially in the context of home automation.
One can reduce the likelihood of a future problem by making a _local_ copy of your 5,120-byte sleep.exe utility, or the 121-byte sleep.com that I showed how to create with debug (which of _those_ is more 'elegant' ? ;-) in the same directory as the batch file.
In short: It wouldn't occur to me (based on my experiences) to depend on an optional extra to the OS buried where I am almost certain to forget about it, i.e., PATHed C:\\Program Files\\Windows Resource Kits\\Tools\\sleep.exe. At minimum, I'd comment the batch file to note that sleep is an external in XP.