It has been tested on Windows 95, 98, NT 4.0, and 2K. On Unix, it has been run on Linux, AIX, and Sun.
In theory, any OS that runs perl should be able to run mh. In practice, some platforms will likely have strange Serial Interfaces (e.g. Mac?), so the Serial IO related function would take some work.
On my Celron 400 Mhz computer running Windows 98, using 60 code files with 6000 lines of code, mh takes 10% the cpu, running at 9 passes per second and using about 30 MB of memory.
If you are happy with the Web interface and don't need the Tk interface, turn it off by editing the Tk mh.ini parm or run:
mh -tk 0
If you want the tk window, but don't use the Command/Items/Group pull down menus, try:
mh -tk_comands 0 -tk_items 0 -tk_groups 0
You can turn off the tk 'eye' that bounces back and forth by deleting the tk_eye.pl code file.
You can speed up / slow down mh, using more/less cpu, by mh.ini sleep_time parm.
Here are some memory stats:
Linux 10 Meg <- mh -tk 0 mh_control.pl (run just one code file) 12 Meg <- mh -tk 0 (run all the test code) 17 Meg <- mh (run all the test code with tk gui on) Windows 18 Meg <- mh -tk 0 mh_control.pl (run just one code file) 20 Meg <- mh -tk 0 (run all the test code) 27 Meg <- mh (run all the test code with tk gui on)
Point your mh.ini code_dir, data_dir, and html_dir parms to somplace other than your mh path. Then you should be able to rename your old mh directory and unzip the new one in its place without loosing anything. Also keep your mh.private.ini somewhere else (see next question).
All the entries in mh.ini are read on mh Startup and on a Reload. They are
stored in the %config_parms
array. So, for example, if you
added:
myparm1=a b c
Then, mh would set $config_parms{myparm1} = 'a b c';
These parms also defined what are legal startup values, so if you want to try a different value, instead of editing your mh.ini, you can run:
mh -myparm1 'd e f'
Rather then edit the default mh.ini file, the best approach is to copy just the parms you want to change to your own .ini file (e.g. mh.private.ini), then set the environmental variable mh_parms to point where you keep that file (see the header of mh/bin/mh.ini for more detail).
While the %config_parms
array IS refreshed on a mh Reload,
some parms are only used on mh startup (e.g. http_port), so will only be
reloaded when you re-start mh.
Funny you should ask :) Check out the time_start, time_stop, and time_increment parms in the mh.ini file. Here are some examples:
mh -time_start 0 -time_stop 24 -tk 0 -voice_text 0 mh -time_start "6 AM" -time_stop "11 PM" -time_increment 1 mh -time_start "5/14 7:10" -time_stop "5/15 10 PM" -time_increment 300
This answer is authored by Bill Birthisel, author of the SerialPort and CommPort modules.
The user works with an X10_Item which reflects physical hardware and the state of that hardware. The user ``loop'' code deals with the state and conditions which alter it. This code is independent of OS and specific to mh.
X10_Items talk to Serial_Items which implement a software protocol required by the model and type of the actual hardware. The Serial_Items can use protocol translator modules such as CM11.pm, HomeBase.pm, and CM17.pm. But the output is platform-independent serial commands to the next layer. The protocol translator modules are publicly available outside mh and may be used by code other than Serial_Items. These modules will eventually be on CPAN. The code is still independent of OS. Other Serial_Item types, including ``generic'' read/write ports, also exist.
Win32::SerialPort.pm and Device::SerialPort.pm are CPAN modules which actually implement the serial command interface. Device::SerialPort is a clone of its Win32 cousin. These modules handle high-level OS issues including device names, configuration files, and validation of port settings.
Each also calls a CPAN module to handle low-level interfacing to the OS and the serial driver: Win32API::CommPort.pm or POSIX.pm (you guessed correctly ;-)
Copy mh\code\test\test_x10.pl into your own code dir (e.g. c:\mh_code). Then run:
mh -code_dir c:\mh_code
You can then use http://localhost:8080 for control. If you also want the local Tk windows, also copy the tk* code files.
If all you want to do is control X10 devices with a cron job or from your own cgi scripts, running mh is probably overkill. You can send X10 commands using either the ActiveHome interface (CM11) or the cheaper Firecracker interface (CM17) using the modules and documentation found in mh/lib/site/ControlX10 or download them from CPAN. Examples can be found in mh/lib/site/test_cm11.pl and test_cm17.pl.
You can send mh commands (Voice_Cmd text strings) from other programs in one of 3 ways:
- Write commands to the file specified in the mh.ini xcmd_file parm. By default this is mh/house_cmd.txt. See mh/bin/house and mh/bin/house.bat for examples.
- Use mh/bin/mhsend to send commands via sockets (can be over the internet). If you have run mh/bin/set_password, the mhsend -password parm is required. To enable this, include the code mh/test/code/mhsend_server.pl in your code directory.
You can also control mh remotely via email (see faq question 'Can do I send mh comands via email?'), telnet sessions (if running mh/code/test/telent.pl), and via the built in web server.
Lots of debug errata can be controled with the mh -debug switch. Most of this code is probably meaningful only if you dig into the source code, so most people probably will not use it unless you are generating debug to send to the author. To create a log file with debug in it, run:
mh -log debug.log -debug xyz
Where xyz can be any of the following:
X10 serial socket startup homebase misc http port_name of socket port
One way is to create a code member that contains just the event you are trying to debug, then run mh on just that one member. For example, create a member called \temp\test_time.pl with this code:
print "min=$Minute\n" if $New_Minute; print "hour=$Hour\n" if $New_Hour; print "debug1 it is now $Time_Now\n" if time_now "11:59 PM"; print "debug2 it is now $Time_Now\n" if time_now "23:59"; print "debug3 it is now $Time_Now\n" if time_now "12:00 AM"; print "debug4 it is now $Time_Now\n" if time_now "00:00";
Then run mh using these parameters:
mh -code_dir \temp -tk 0 -time_start '12/15 11:58 pm' -time_start '12/16 12:01 am'
Note, you can run this test mh quickly without stoping your normal mh.
Advantages:
You don't need the latest version of perl installed
You don't have to install additional perl modules
Disadvantages:
For some reason, starting mh with the compiled versions is slower. On my windows box, it is 10 seconds -vs- 20 seconds.
You can apply quick patches to mh, -vs- downloading a larger, less frequently updated mh.exe file.
The memory and cpu used, once mh is started, is the same.
Each time mh is started or a Reload is done, mh will re-read all the .pl
code members in the code_dir directory (this is a mh.ini parm) and the file
code_dir/mh_temp.user_code is created. All of the objects and global
variables (see FAQ question 2.4), are put at top of this file, and
everything else is put in seperate subroutines, one for each file read. A
&loop_code
subroutine is also created (at the very bottom
of mh_temp.user_code), that calls each member subroutine.
After creating this file, mh runs the perl eval function on its contents.
This re-creates all the objects, global variables, and code_dir member
subroutines. Then mh goes back into its normal loop where it queries
various input data (e.g. serial, tcp/ip, voice, time), updates objects and
variables, evals the &loop_code
code (it does an eval,
rather then execute it directly, so we can trap errors and not kill mh),
sleeps for a bit, then repeats.
You can think of the built in mh web server as 2 parts:
- The part that auto-generates web pages that reflect your items and commands.
- The part that responds to commands you give it via URLs.
You don't really have to use the first part. Some mh users custom generate their own mh pages, to be served by the mh server or by a different server. This allows for full control of what is on the web control page and how it looks.
There is more (probably not so easy to read) documentation on how to do this under 'Customizing the Web Interface' in mh/docs/mh.html
You can also use something like mh/code/test/mhsend_server.pl and then read/write to sockets directly from non-mh web server cgi scripts. Or have the web server script simply call mh/bin/mhsend to run mh commands.
Not yet, but you can now define items/events in a table-like format. This should allow us to enable a gui or web based front end tools for editing.
Currently we have defined just one format defined, creativly named A, but other formats (e.g. XML) should be easy to implement.
To use, create one or more *.mht (mh table) files in your code directory, specifying the table format with Format=A at the top of the table. Then mh will process (on starup and reload) each record with mh/lib/read_table_A.pl, to create *.mhp (mh processed) files, which are then processed with all your other mh *.pl code files.
Examples are in mh/code/bruce/*.mht and mh/code/test/*.mht. If you want to create another table format, all you need to do is create a mh/lib/read_table_xyz.pl member, then set Format=xyz.
If there are syntax errors in your code, most of them will be caught on startup or reload. The error, and (hopefully) relevant code member and/or line number, will show up in your console, and if running Tk, in a Tk window on reload.
When you go to write new code, first start mh with old code that works, then edit or copy in your new code and do a mh Reload. Fixing errors with code Reloads is much quicker than trying to fix them on mh startup. You can add/delete the .pl suffix on code members between reloads to enable/disable them.
Some errors (e.g. too few/many {} around code) will point to a misleading line number. In these cases, if you can not find the file with the error, you can try a new option: mh -error_by_file 1 . This will try loading one file at a time untill the error is found, but it runs pretty slow and may not work with members that have # noloop directives.
Some errors will only show up after mh triggers events. The first time this happens, a console/tk message will be displayed, and a message spoken. Since these errors might happen on sequential passes of mh, subsequent errors are only listed in the console window. If more than 10 occur, another window is displayed, and the code member there error was in is disabled.
All of these on-the-fly errors are logged in the file mh_temp.error_log in your code directory. This is useful if you are not running tk and the error has scrolled out of your console window.
You can enable the perl diagnostics module (same as perl -w) to get additional warnings on potential coding errors. Either use mh -diagnostics 1 or set diagnostics=1 in your mh.ini. This takes about 1 meg more of memory and causes mh to run about 10% slower, but the messages it displays often point to valid problems. To simplify coding, the 'uninitialized value' warnings disabled in the user code processing.
You can use the $Startup
or $Reload
variables for
events that should only occur when mh is Started, or when code is Reloaded.
Note that $Reload
is also true when $Startup
is
true.
To run events infrequently, you can use the modulus operator (%), $New_Second/Hour/Day/Month/Year variables, or the Time_Now/Time_Cron functions to control events.
The $New_xxx
variables are 1 (true) for each pass that the xxx
variable gets incremented, and 0 for all other passes. For example,
$New_Hour
is true for one pass when $Hour
changes
from one hour to another.
Here are some examples:
print_log "Only at startup" if $Startup;
print_log "Every 5 minutes" if $New_Minute and !($Minute % 5);
print_log "At 10:05 pm" if time_now '10:05 PM';
print_log "Every weekday at 2:15 am" time_cron '2 15 * * 1-5';
Pretty much anyway you want! You may want to put object definitions all in one member (e.g. mh/code/Bruce/items.pl) so you can easily change device codes, or you may want to define the objects in the file members you use them in.
If the same object is defined in multiple members, it will still work ok, although some object types (e.g. Voice_Item) will warn about duplicate names.
Yep. All objects definitions (e.g. $light
= new
X10_Item('C5'))
are always shared. They are pulled out of the
member loop by mh.
All other variable declarations must be made using with 'my' or 'use vars':
my ($my_var1, $my_var2); use vars '$my_var1', '$my_var2'; use vars qw($my_var1 $my_var2);
The last example uses the qw function (Quote Words) to save you from the ' and , punctuation.
If you code a 'my' or 'use var' record that starts in column 1, mh will pull these records out of the member loop code (as it did with object definitions), so that the variable can now be shared with other code members.
If the 'my' or 'use var' record does not start in column 1, the variable declaration is left in with the rest of the member code and is local to that member.
If you want to use the variable with any mh/web/*.pl script when creating mh web pages, you must use 'use vars', as 'my' variables can not be shared with the server.
Sometimes you may need to have mh run code out of the loop code. For example, if you want to create a Voice_Cmd object that has states that are read from a file. Since objects are moved out of the loop code by mh, we need to also move any other code used to define that object.
You can tell mh to do this using '# noloop=start/stop' comments. For example:
# noloop=start my $mp3names; while ( my $mp3name = <d:/songs/*.mp3> ) { $mp3name =~ s#^.*/##; # remove path $mp3name =~ s#\..*$##; # remove extension $mp3names .= "," if $mp3names; $mp3names .= $mp3name; } # noloop=stop
$v_play_music = new Voice_Cmd("Play [$mp3names]"); if ($state = said $v_play_music) { speak "Playing song $state"; run("winamp d:/songs/$state.mp3") }
You can add your own subroutines anywhere in any of your code files. These can then be called by that member or any other member. Here is a couple of examples:
print_log &mysub1(9990, 9);
sub mysub1 { my ($a, $b) = @_; my $c = $a + $b; return "The answer is: $a + $b = $c"; }
$v_bedroom_curtain = new Voice_Cmd('[open,close] the bedroom curtains'); &curtain_on('bedroom', $state) if $state = said $v_bedroom_curtain;
sub curtain_on { my($room, $action) = @_; set $curtain_updown $action; eval "set \$curtain_$room ON;"; }
Here are a few:
$Pgm_Path is the directory that that mh/bin/mh is found in. $Pgm_Root is one directory above $Pgm_Path $OS_win is true on windows, false otherwise. $^O will reflect the OS name.
On Windows (95,98, NT), you can use the SendKeys to send keystrokes to other windows. See mh.html for details.
If anyone knows of an equivalent function for linux, let me know. Linux is usually clever enough to have command line options, so there is less of a need here.
The state of all objects (Timer Serial_Item X10_Item X10_Appliance
File_Item Generic_Item) and all the $Save
variables.
Every 5 minutes while mh is running, and whenever mh is exited, the state of these variables are saved to your code directory in a member called mh_temp.saved_states. When you start mh, this member is run to restore the states.
You can make up any members to the $Save
array. For example,
you can use $Save{sleeping_cat} to track whenever your cat is asleep.
You can turn all the lights on a single house code on/off by specifying just the house code letter. For example:
$v_bedroom_lights = new Voice_Cmd('Bedroom lights [on,off]'); $bedroom_lights = new X10_Item('P'); set $bedroom_lights $state if $state = said $v_bedroom_lights;
You can also create a group of X10 items. Here is an example that would turn all lights on/off in several rooms.
$all_lights_bed = new X10_Item('P'); $all_lights_living = new X10_Item('O'); $all_lights = new Group($all_lights_bed, $all_lights_living);
$v_lights_all = new Voice_Cmd('All lights [on,off]'); set $all_lights $state if $state = said $v_lights_all;
Out of the box, mh defaults to running all the code in the mh/code/test directory. Once you have played around with the example code, you will want to create your own code directory (probably somewhere other than in mh/code, so you can easily upgrade to new versions of mh), and copy just the code members you find useful. Members test_tagline and the hello_speak members are the main sources of the periodic test speech.
If you want to use the Tk interface, make sure you copy tk_*.pl members. See the FAQ question 'How does mh.ini work' on how to modify the code_dir parm to point to your new code directory.
Set the mh.ini net_mail_command_code parm to a secret code, and copy mh/code/test/internet_mail.pl into your code directory. Now you can send email with the following string either in the subject or the body of your email:
command:your command code:your_code
The internet_mail.pl code periodicaly runs the get_email process and then scans for the above string. If found, it will send a confirmation email saying either ``command run'', ``command not found'', or ``command not authorized''.
All Voice_Cmd objects are listed in the Tk Command pull down and Web Category list. These lists are organize by Category, which is specified with a Category=value comment in the user code. For example:
# Category=Timers
This can be specified multiple times in the same file, with the most recent specification appling to all subsequent Voice_Cmd entries.
If a file does not have a # Category record, the file name will be used.
Answer complements of Brent L Johnson.
The problem is, festival or another sound program, is locking your dsp device. The sound drivers that come stock in the Linux kernel do not allow more than one program to access the /dev/dsp at one time. If you are using RedHat, you can use ESD to multiplex the soundcard usage. The problem is, not all sound programs are esd aware. Festival and Viavoice do not directly support esd. ESD does have a workaround that _sometimes_ works with non-esd aware programs. Try starting your sound programs, festival and viavoice under esddsp. For example: ``esddsp festival --server &''. I had some success with this route but it doesn't always work because of sampling rates and such.
The best fix would be to replace OSS with ALSA. http://www.alsa-project.org. The ALSA drivers directly support multiplexing the dsp devices. The only problem is they currently support fewer cards than the OSS drivers that come with the Linux kernel. Check out the web page and see if your card is supported. If it is, the best avenue would be replacing OSS with ALSA.
This might work ... it has not been tested.
You can globally increase the volume of all waveforms generated by festival by adding the following to your siteinit.scm. Put that in the festival/lib directory, (where all the other .scm files are) probably /usr/lib/festival/lib if you used the standard rpms. Add the following
(set! default_after_synth_hooks (list (lambda (utt) (utt.wave.rescale utt 1.0 t))))
This will maximises the volume within a wavefrom, this wont necessary make all voices the same loudness (though it will be close).
Alternatively
(set! default_after_synth_hooks (list (lambda (utt) (utt.wave.rescale utt 4.0))))
will mutiply the waveform by 4 but this has the problem that it may overflow.
If you want X% of the maximum without overflow use the first example and lower the 1.0 until you get an acceptable volume
If you are experiencing problems with windows not popping up when they should (e.g. control panel or install shield), you will want to install DCOM 1.3, available from here:
http://www.microsoft.com/com/dcom/dcom98/dcom1_3.asp
Note, I had run all the 'Windows updates', including the Service Pack 2, but I still had the problem until I installed the above.
For Windows 95, the update is at:
http://www.microsoft.com/com/dcom/dcom95/dcom1_3.asp =head2 4.2: How do I set setup networking between Windows boxes
You need to have the TCP/IP protocol enabled for your Networking Interface Card (NIC). If you use a modem to reach the internet, you already have TCP/IP enable for the dial up adaptor, but you need to seperately enable it for your NIC card, using the control panel Network icon.
You can find instuctions on how to do this at: http://win98central.acauth.com/inside98/networking.htm .
IP addresses that start with 10. (e.g. 10.0.0.1) are reserved for internal lans, so you can use 10.0.0.1, 10.0.0.2, etc.
Using MisterHouse ;-) Much more fun that trying to code up that report generator at work! Some good books are referenced in mh.html.
Codeing perl is much easier and less error prone if you use an programing editor that automatically highlights and indents code.
One very popular and powerful (and free) editor is Emacs: http://www.gnu.org/software/emacs/. A pre-compiled windows version can be found here: http://www.gnu.org/software/emacs/windows/ntemacs.html
Alan Jackson liks vim: http://www.vim.org. ``Does syntax highlighting quite nicely for perl''
Kieran Ames likes UltraEdit32: http://www.ultraedit.com. ``I swear by UltraEdit32 available at It works fully functional for 30 days and then expires. Registration goes for around $30. I'm coding Perl all day long and would die without it! Fairly thin and goes the distance with just about any language you'd want to use.''
Bill Sobel sent a pointer to J: http://www.armedbear.org/. ``I was using notepad and switched to 'J' and open source development editor. The author, Peter Graves, is a coworker of mine and all around swell guy. This java based editor already includes Perl syntax highlighting and Peter is pretty quick about fixes/changes.''
Mark Yocom writes ``I myself have grown fond of PrimalSCRIPT, which handles Perl, Java (and JScript & JavaScript), HTML, ASP, LotusScript, Livewire, Python, SQL, Tcl, REXX, VBScript, and good old fashioned .BAT/.CMD files. In addition to the obligatory syntax coloring, it also has a number of other handy features. It's spendy, but a trial version is available at their website: http://www.sapien.com/PrimalSCRIPT.htm ''
Doug likes $20
shareware CodeWhiz: http://www.incatec.com . Colored
commands, auto indent, auto remark/unremark, line #s, etc.
Here is a rough timeline of MisterHouse development:
- 12/96 Coded a predecessor called House_Menu - 8/98 Re-wrote everything, called it MisterHouse - 9/98 Uploaded to the web - 10/98 Created compiled version. - 11/98 First known user. - 01/99 Started a mailing list at onelist.com - 02/99 Ported mh to Unix/Linux - 03/99 Article in Popular Home Automation - 05/99 Registered misterhouse.net domain name (misterhouse.com is owned by misterhouse.it, an Italian Real Estate company ... go figure!) - 06/99 Added CM17 & HomeBase support - 06/99 Article in HomeToys: http://hometoys.com/htinews/jun99/articles/winter/winter.htm - 08/99 Mailing list reaches 100 members - 09/99 Added LCDproc and IRman support - 10/99 Article in Circuit Cellar Ink: href=http://www.circuitcellar.com/pastissues/articles/winter111/winter.pdf - 11/99 Linux VR using IBM's ViaVoice - 11/99 HomeVision support - 11/99 Mailing list reaches 200 members - 01/00 Moved the mailing list and CVS repostitory to sourceforge.net - 02/00 Re-worked the web interface - 03/00 Added support for iButtons - 04/00 Added support for X10's IR Commander transmiter - 05/00 Added voice modem, ISDN modem, and Compool support. - 05/00 Article in The Perl Journal #17 - 06/00 Mailing list reaches 300 members - 06/00 Added support for table item/event input and tie_items/tie_events. - 08/00 Enable perl -w checks, .jpg and .gif, and Slinke support. - 08/00 Added rpm and tarballs, NetGear router support - 09/00 Added ViaVoiceTTS.pm, Jabber, and Applied Digital cpuxad support - 10/00 Added barcode scanner and MS Agent support
Bruce (Winter) is the the main author of MisterHouse. He has a day job with IBM in Rochester, Minnesota, designing integrated circuits. He got started with Home Automation as one of the first ECS users in '86 and started the ECS mailing list in '94. He loves getting slaughtered by his twin boys in Quake death matches, hiking in his boyhood state of Montana, and playing a digital piano.
Because open source only has 2 syllables, and proprietary has 5.
That and MisterHouse has developed much faster with the help of a wider user base and help from other coders than it would have if it were proprietary.
Plus it feels good to give stuff back to the growing open source community.
Here are some useful/related Home Automation links:
Dan Hoehnens most excellent collection of HA links: http://www.infinet.com/~dhoehnen/ha/list.html
Over 500 links on about everything with HA: http://home-automation.org/
Lots of good tutorials and articles are here: http://hometoys.com/
X10 has many of its products documented here: http://www.x10.com/support/support_manuals.htm
Lots of good X10 data can be found here: http://www.geocities.com/ido_bartana/toc.htm
Europeans can get X10 stuff from http://www.intellihome.be
Neil Cherry has created a home for linux related Home Automation programs at http://linuxha.sourceforge.net
Rene Mueller has a nice set of web pages with lots of info on HomeAppliances at http://the-labs.com/HomeAppliance/
To get started with cvs, there are instructions at:
http://sfdocs.sourceforge.net/sfdocs/site/cvs.php
For those on windows, you can find instructions for installing cvs and ssh (the secure shell used at sourceforge) at:
http://sfdocs.sourceforge.net/sfdocs/site/user/newproject-howto.php
Here is the command to check out the mh repository. Do this someplace other than your main mh directory. It does not include all the mh code (some of which came from CPAN and is maintained elsewhere), so you will not be able to run out of this directory. Also change username to your sourceforge id:
cd \sourceforge cvs -d:ext:username@cvs.misterhouse.sourceforge.net:/cvsroot/misterhouse co mh
When you have code you want to check in, you would do it with somethink like this:
cp \mh\lib\http_server.pl \sourceforge\mh\lib cd \sourceforge\mh\lib cvs commit http_server.pl
The people at http://www.x10.com sell affordable devices that communicate with each other over normal household power lines.
The most common modules are the Lamp module and the Appliance module. Both sell for around $10-$15. The lamp module has can turn up to 300 watt lamps on, off, and various levels of bright. The appliance module is an on/off relay.
The 2 most popular X10 PC interfaces are the $50
ActiveHome/CM11 and the $6
Firecracker/CM17.
The CM17 is a transmit only interface. In addition to being almost free, another advantage is it is wireless. It is a small, 1 inch box that just dangles off of your serial port and transmits to a receiver that plugs into the wall. The other advantage to the CM17 is gives instant ON/OFF control to the relay built into the wireless receiver. All other X10 devices have about a 1/2 second delay to send and receive the protocol over the power lines.
The CM11 is a 2 way interface, so you can program mh events to react to X10
motion sensor and button pushes from various X10 controlers (e.g. keychain
and palmpads). Some of the newer, more expensive modules, like the
$35
LM14A lamp module, allow you to query their status, so you
can determine it status even if it were manually turned on or off.
If decide you splurge for the CM11 activehome kit, you might as well also get the Firecracker kit. For the extra $6, you also get a few extra modules and mh can support both the CM11 and the CM17 on the same port.
There is lots of great X10 info at http://www.geocities.com/ido_bartana , including information on using and buying X10 hardward outside of the US.
Here is some more info, copied from a misterhouse-users post by Kevin Olalde.
The firecracker hardware, CM17 which plugs into the PC, can only send radio frequency (RF) commands to devices. With the kit you will also get a transceiver, TM751, that receives commands from the CM17 and relays commands for the house code it's set to via your power lines. You also get a lamp module, LM465, which can be control with via the transceiver. With the PalmPad or the CM17 you send RF commands to the TM751, those commands are then relayed to the lamp module (or other power line receiver modules, like light switches). All of this is one way communications, the LM465 lamp module and the TM751 transceiver are not capable of reporting status. The TM751 doubles as an appliance module hard coded to unit 1. You can only control it though RF commands, it does not respond to power pline commands.
The next step I took was to order the Active Home kit. With it you get (among other stuff), another transceiver, RR501, and another computer interface, CM11A. The RR501 works like the TM751, in that it receives RF commands, and relays then on to the power line. A difference is that the RR501 can report it's status. The computer interface, CM11A, can send power line commands (you use computer software to tell the interface what commands to send), 'sees' all commands being sent over the power line (and reports those commands to computer software), and can ask modules for their status. The RR501 also doubles as an appliance module, it can be set to unit code 1 or 9, and can be controlled with both RF and power line commands.
The majority of the devices, lamp modules, appliance modules, wall switches, ..... are one way devices, they can only receive. I have no historical perspective, but it looks as though that was the way the original X10 spec went, one way only.
There are devices that can report their current status to something like the CM11A, but I haven't used any of then (except for the RR501), since that are much more expense.
http://www.x10.com/products/x10_lm465.htm one way lamp module from X10, $13 http://www.x10.com/products/x10_lm14a.htm two way lamp module from X10, $33
Here is a post from Clay Jackson
Right now, I've got 3 sensors (DS1822, in the three-lead package, inside an epoxy filled soda straw) at the end of 150' of Radio Shack ``flat'' cable, talking to a DS9097U (the U is CRITICAL) with no problems. On the bench, I had another 2 sensors on the end of a 50' cable (for a total of 5 sensors). When I strung the 50' cable, I must have crimped a lead, because it now meters ``closed'' and when it was plugged into the ``net'', I got no readings.
I also have an HA5 from Point-Six; that I'm gonna play with soon. The code Bruce did is for the 9097U, so that's why I started there (and, it's cheaper). The 9097U has all the ``passive'' pull-up stuff the data sheets talk about (courtesy of a DS2048 inside the DB9); so I'm hoping it will do the trick. Anyway, I'll keep the list posted as things progress.
Bottom line - all I needed was Bruce's code, a 9097U from Dallas, the sensors and some Radio Shack ``phone'' cable.
One more thing to watch - as best I can tell, Dallas has not standardized their thermal devices with respect to their outputs. For example, the DS1820 and DS1920 both return a 9 bit value that's basically an integer. However, the DS1822 returns a VARIABLE length value (12 bits by default), with a binary point between the 3rd and 4th digits. According to someone else on the list, the ThermoCRON iButton is different yet again.