x10web Version 1.5
Two Java based programs are provided in a separate package called wishweb. The first is a simple GUI that looks like SmartHome's Power Synapse. The second is a more powerful GUI that is similar in function to HomeControl. The last one is an application built solely around the SmartHome Templinc. All use the same server mechanism described below.
This section provides step by step instructions to go from a tar file to a working WEB Applet for all three Java based GUIs. Perform all of these steps as the user that can write to the HTML home. It is assumed that $HTMLHOME is set to the location for html files for the server HTML pages.
Once these steps have been completed, you need to run x10home as a standalone application so that you can create your configuration file. From the server running x10serv, type "make runx10home". You can also create the default configuration file on a Windows box locally and then copy it to your server html directory by typing "makex10home" and then "x10home server <x10 server>".
Once all of this has been done, you simply need to open a browser and open:
The primary component is the x10 WEB server. The server is named x10serv and is written with some security in mind. Security is very simiply making the driver only serve to devices that are relatively based off of /dev/x10 or whatever device base is specified when the driver is started. The syntax for starting the server is as follows:
# x10serv -t tcpport -u udpport -b devicebase -p pidbase -m maxconnections
tcpport: The TCP port to listen on for client connections. The default port is 1418. TCP sessions are used by clients to create two-way communications with the drivers such as would be needed to listen for status or log events.
udpport: The UDP port to listen on for client connections. The default port is 1930. UDP sessions are used by clients to create one-way communications to the drivers such as would be needed issue commands to the x10 devices.
devicebase: The base directory name used to access the individual x10 devices. The communications protocol for the server accepts device names for the actions and will block any file reference that begins with a "/" or contains any relative paths in the filename. The default is /dev/x10.
pidbase: The base name for the pid files for any open connections. The pid file base will be /var/run/x10serv. The base will receive a suffix of .udp.pid for the process id for the UDP thread of the daemon. The base will receive a suffix of .tcp#.pid for each TCP connection opened to the TCP thread of the daemon. The number will be incremented for each TCP thread created.
maxconnections: The maximum number of simultaneous TCP connections that the server will accept. The default is 4.
The defaults for the server are set up to be identical to the defaults used by the makedev.sh device so that a standard installation can run the server without any options specified. When the server is run, it will open up the sockets, and if all is successful, it will fork off two threads. One thread will be the TCP receiver and the other will be the UDP receiver. Each TCP connection will result in forking off a new thread to handle the new TCP connection. The number of connections (and number of processes that the server will start) is limited by the maxconnections argument.
The protocol used by the server is composed of 3 commands as listed in the following table:
| command | protocol | shell command syntax | description |
|---|---|---|---|
| > action device | UDP | echo action > device | Sends an X10 action to the x10 device. The commands are of the same form as those used for all other communications with the drivers. |
| > action device | TCP | echo action > device | Sends an X10 action to the x10 device. The commands are of the same form as those used for all other communications with the drivers. |
| < device | TCP | cat device | Opens the specified x10 device for blocking read and send any data from the device across the TCP connection. |
If the server is installed and running, it can be tested using telnet. On the localhost, type "telnet localhost 1418". You will get nothing back until you enter a command. If you enter a valid command, you will receive "OK". If you enter an invalid command or the command fails, you will get "ERR". If you enter the command "> ON a1" and get an error, then your system may not match the defaults. Run the server in debug mode by passing it the parameter "-d" and look for any errors when you repeat the above exercise.
First install and get the wish drivers installed on your X10 server. Verify that the server is operating properly and that commands can be sent to the /dev/x10 devices. Once you know that the X10 server is operating correctly and the necessary modules are loaded, Download the wishweb package and compile the socket server for the client using the following command:
# make x10serv
This will will create the daemon that needs to run on the server with the X10 drivers installed. For convenience, copy the server to a location on the server. It must be run as root so /usr/sbin is appropriate. Use the following command:
# cp x10serv /usr/sbin/
The server is now installed and can be run by typing "x10serv" from the root prompt using the options described above.
x10web is an application that looks very much like SmartHome's Power Synapse. The application runs as a standalone application or as a WEB applet. In either case, to run the applet, the Java Swing library must be installed as well as a java runtime environment supporting Java 1.4. The applet is provided primarily as an example of how to create a WEB interface to manage the X10 network.
The client is written in Java and contains the standard capabilities that the X10 protocol defines. Although some drivers may have a subset of the standard commands, the client will be unaware of the features supported and will enable all buttons. The server will discard any commands which are unsupported by the x10 driver loaded. The client can run as either a standalone java application or as a java applet in a WEB browser. If you don't have a WEB browser that supports Java 1.4.1 or the Java plugin, you can use the appletviewer that comes with the Java Runtime Environment.
Below is a screenscape of the GUI interface (from within a WEB browser) set on the Action tab. The client starts by opening a TCP connection to the server on the default port of 1418. To change the port, pass the parameter "tcpport" to the Java program when it is started or by modifying the WEB page that calls the client. For each Unit or Action command, the Client sends a UDP message to the server for the housecode. The udp port defaults to 1930 but can be changed by passing the parameter "udpport" to the Java program when it starts or by modifying the WEB page that calls the client. The client accepts 4 parameters when it starts:
server: The server to connect to. The default is "localhost" when running as an application and the hostname of the WEB server when run as an applet.
tcpport: The TCP port to open a stream connection to. The default is 1418.
udpport: The UDP port to open datagram connections to. The default is 1930.
The action tab allows the user to send commands to the X10 network and it is also where all information from the log is stored.
The second tab is the status tab. This tab shows a dot for every possible X10 device and will show a blue dot for each device that is on. This page demonstrates the use of the /dev/x10/status page to capture the state of devices on the network.
Bot the log on the action tab and the buttons on the status tab are updated in real time using a TCP socket for each page and a thread for each socket. The application takes advantage of the Java object oriented language such that each status light is driven by a state machine that mimics an X10 switch. Therefore, only one socket is required for the application to work and the indicators for the status page are driven from the log entries to maintain state. Note that the original program used two sockets and used the /dev/x10/status interface to read the status and update the page. However, in light of controversy over whether the drivers should maintain state or not, this application has been written assuming that it doesn't.
To turn on device E10, select the radio button for Housecode E. Then press the button for Unit 10. Then press the Action for ON. The actual commands sent for the action will be "E10, E ON". By default, the Date and Time for each command are translated and displayed in the monitor window.
To issue a preset dim of 100%, move the slider down so that the text below the PresetDim button says 100%, select the housecode to dim, press the Unit to dim, and then press the PresetDim button. The GUI is forcing you to use the raw X10 protocol so it doesn't group commands together or automatically add addresses to the commands. When you press the unit button, the client sends the address (housecode and unit) on the X10 powerline. When you press a command, the client sends the housecode and command on the powerline. While the server will take commands such as "> on e10", the GUI will not utilize this format.
The goal of the client is to demonstrate how to utilize the server. Since the server just passes commands through to the X10 devices, a client could utilize the more complex interactions of the X10 drivers.
The distribution of the application provides the signed version of the precompiled source in the file x10web.jar. The source code to the x10web application is provided and can be compiled to create x10web.jar by the enduser. Java is byte compatible across operating systems so the precompiled x10web.jar file can be installed directly without any changes. It is always recommended that the source code be recompiled by the administrator; and, the precompiled x10home.jar file should only be used when the end user does not have the J2SE 1.4.1 (or later) JDK installed. The source can be compiled on either a Windows or a Unix machine using the commands listed below::
Windows c:\x10web> makex10web.bat Unix (user) $ make x10home.jar Copy x10start.html, x10web.html, and x10web.jar to a location on the x10 server where the Apache (or suitable replacement) WEB server document files are located. For most RedHat installations the location of the WEB documents is /var/spool/www/html. Use the following commands:
# cp x10web.jar /var/spool/www/html/
# cp x10start.html /var/spool/www/html/
# cp x10web.html /var/spool/www/html/With everything installed, all that needs to be done is to load the x10home.html WEB page from a browser that has access to the server. No special parameters or options are required as the applet will connect back to the serving host automatically to access x10serv and the x10home.cfg file.
Let's make that real simple. If the server running the wish drivers is at IP address 192.168.200.2 running Apache with a document directory of /var/spool/www/html, and a Windows client is at address 192.168.200.4, to run the applet on the Windows client, the following commands would be used to run the applet (including installing starting the server):
Unix server at 192.168.200.2 Windows server at 192.168.200.4 # cp x10web.html /var/spool/www/html
# cp x10web.jar /var/spool/www/html
# cp x10start.html /var/spool/www.html
# cp x10serv /usr/sbin
# x10serv
#explorer http://192.168.200.2/x10start.html
The standalone application is a bit more difficult in that it requires that the user of the client machine have a bit more knowledge of the computer and the packages installed on the computer. If the Java applet can run on a computer, the Java Runtime Environment (JRE) is already installed; therefore, the user must know where the binaries are stored. Another drawback of starting the application in standalone mode is that the user must be able to specify the server name when starting the application.
The distribution of the application provides the signed version of the precompiled source in the file x10web.jar. The source code to the x10web application is provided and can be compiled to create x10web.jar by the enduser. Java is byte compatible across operating systems so the precompiled x10web.jar file can be installed directly without any changes. It is always recommended that the source code be recompiled by the administrator; and, the precompiled x10home.jar file should only be used when the end user does not have the J2SE 1.4.1 (or later) JDK installed. The source can be compiled on either a Windows or a Unix machine using the commands listed below::
Windows c:\x10web> makex10web.bat Unix (user) $ make x10home.jar Once the x10web.jar file has been created, copy it to a location that you want to run it from. The application can be run in standalone mode on a machine that either has the J2SE SDK or the JRE version (1.4.1 or higher) environment installed. These are both available for download from http://java.sun.com. The command is identical on both Windows and Unix as follows:
Windows C:\x10web> java -cp x10web.jar x10web.x10web server <hostname> Unix (user) $ java -cp x10web.jar x10web.x10web server <hostname> Substitute the name or IP address of the server running x10serv for <hostname>. A window similar to what is shown earlier will appear on the screen.
Let's make that real simple. If the server running the wish drivers is at IP address 192.168.200.2, and a Windows client is at address 192.168.200.4 with the Java Runtime Environment installed in C:\Program Files\JavaSoft\1.4.1, to run the applet on the Windows client, the following commands would be used to run the applet (including installing starting the server):
Unix server at 192.168.200.2 Windows server at 192.168.200.4 # cp x10serv /usr/sbin
# x10serv
#C:\> mkdir C:\Program Files\x10web
C:\> copy x10web.jar C:\Program Files\x10web\
C:\> C:\Program Files\JavaSoft\1.4.1\bin\java -cp C:\Program Files\x10web\x10web.jar x10web.x10web server 192.168.200.2
C:\>
x10home is an application that creates a virtual representation of the X10 network allowing the user to create objects that represent the switches in the home and give them names. The application runs as a standalone application or as a WEB applet. In either case, to run the applet, the Java Swing library must be installed as well as a java runtime environment supporting Java 1.4. If you don't have a WEB browser that supports Java 1.4.1 or the Java plugin, you can use the appletviewer that comes with the Java Runtime Environment. You must also have the JFreeChart and JCommon libraries available for the application to operate.
The x10home client is written in Java and supports the standard capabilities defined by the X10 protocol. This interface differs from the x10web interface in that it allows the user to specify the functionality of the switch and then allow the application to manage the switch accordingly.
Below is a screenscape of the GUI interface. The client starts by opening a TCP connection to the server on the default port of 1418. To change the port, pass the parameter "tcpport" to the Java program when it is started or by modifying the WEB page that calls the client. For each Unit or Action command, the Client sends a UDP message to the server for the housecode. The udp port defaults to 1930 but can be changed by passing the parameter "udpport" to the Java program when it starts or by modifying the WEB page that calls the client. The client accepts the following parameters when it starts
| server | The name of the server running x10serv. The name can be either a fully qualified domain name or an IP address. |
| tcpport | The TCP port used to for creating a stream to the x10serv server. The default is 1418. |
| udpport | The UDP port used for sending datagram messages to the x10serv server. The default is 1930 |
| devicebase | The base address for the devices. The default is "." and should match the argument used when starting x10serv. |
Overview of operations: x10home is considerably more user friendly once it is set up. x10web is very simple in that it allows for very direct control of the network; however, it is fairly limited in use to people that are very familiar with the X10 protocol. To make the X10 drivers and network available to a broader group, x10home has been created. x10home allows an adiminstrator to create a configuration file that fully describes the X10 network of devices. The file is then placed on the WEB server along with the X10 application and any user who has access to the WEB server can control the X10 network. The Graphical User Interface (GUI) is built around the use of icons (no menus). It creates representations of each switch as an object on the screen and allows the user to manipulate the network through the representations.
The icons are intended to make viewing and understanding the state of the network intuitive. Once the house is set up in the application, the configuration is saved to the server or to a local directory (if it is run as an application). Each switch window is fully moveable and can be iconified. When iconified, it will display an indicator for whether it is on or off as well as the name of the switch that is in the titlebar. The GUI is driven off the same state machine that is used in x10web and each little window is driven by the state machine that simulates a switch. The application watches the log for activity from the X10 network and updates the state of each switch by passing the log information to the switch. In doing so, the application simulates the true nature of an X10 network except that it does not account for noise on the network. When the application first starts, it will load the configuration and create all of the switches. It will then start reading the log and the switches will react as each log item is pulled in. This means that since the X10 drivers maintain a circular log, a number of historical entries will be loaded and the switches will react so that the latest information is displayed.
Application layout: The display is divided into 3 areas of interest. The toolbar for all of the button action, the log window to watch the network, and the rooms where the representations of the switches will be.
Toolbar: x10home has a toolbar that is detachable. You can use the mouse to pull the toolbar at the top of the window to the sides or to pull off the application completely. When it is detached from the application, it can be reattached by closing the detached toolbar window. The icons on the toolbar are as follows (from left to right):
| Name | Description | |
| New Room |
 |
Create a new tab on the screen to represent a room. In the example shown above, two rooms have been created names Lights and Controls. |
| New Switch |
 |
Creates a new X10 switch |
| Save |
|
Saves the current configuration to the local host. Currently this is only enabled when the application is running as a standalone application. At some point I will figure out how signing works and will be able to save even when running as an applet. |
 |
Prints out a text based description of the X10 network to a local printer. Currently not enabled. | |
| Copy |
 |
Copies the currently selected X10 switch to a hold buffer. This option is enabled if a switch has been selected. |
| Paste |
 |
Creates a new switch with the attributes copied using the Copy button. This button is enabled if a switch has been copied to the copy buffer. |
| Cut |
 |
Copies the currently selected switch to the copy buffer and deletes the switch. This button is enabled if a switch has been selected. |
| Delete |
 |
Deletes the selected switch from the configuration or deletes the entire room if it is empty. This button is enabled if a switch has been selected. |
| Edit Properties |
 |
Displays a dialog box allowing the properties of the selected switch to be edited. This button is enabled if a switch has been selected. |
| Rename Room |
 |
Displays a dialog box allowing the user to change the name of the currently displayed room. |
| Align to grid |
 |
Aligns each switch to its nearest point on the mesh. The switch will be aligned to the nearest grid position that is less than the current position. |
| Show Log |
 |
If this button is selected, the log of activity on the X10 network will be displayed on the left hand side of the screen. |
| Auto Discovery |
 |
If this button is selected, the application will create switches as it hears them on the network. The default switch will be dimmable and support scenes. All new switches will be added to the room "Discovered". If the room does not exist, the room will be created. |
| Audio |
  |
This button is a toggle button. When it displays the picture of a speaker, audio feedback is enabled. When it displays the square button, audio feedback is disabled. |
| Reconnect |
 |
Reestablishes communications with the x10 server. This is primarily intended to allow the application to continue to run even if the x10serv application is restarted. x10web loses its connection when x10serv is restarted and must be restarted to reestablish communications. |
| Help |
 |
Displays a help window. |
Log Window: The screen is divided into two sections. On
the left is the current log of activity on the network. The application
listens to all devices on the X10 network and will display the activity in this
window. The window can be resized as needed and will store up to 100
events which can be scrolled with scrollbars that will appear when the window is
filled. At the top of the log window is a display of the current server
that the application is connected to. If there was an error connecting to
a server, an error will be displayed. The Log Window can be disabled or
enabled by pressing the
button.
Rooms: The right side of the screen is devoted to managing rooms
and switches. Initially there are no rooms. Once a room is created,
the room can be populated with switches. For each room that is created
using the
button, a
tab will be created at the bottom of the area with the name "New
Room". The room can be renamed by pressing the
button. Switches are
then added to each room using the
button and set up to represent the way the real switches behave. Note that
unlike the Switch properties dialogs, the room properties dialog is modal.
This is to prevent making changes to a room while it is being edited. If a
room is completely empty, pressing the
button will delete the room.
Devices: This is where the whole plan comes together. In
traditional object oriented style, each switch is a fully self contained
representation of the physical device on the network. When a new device is
created, it defaults to the address "A1" (not so different from real
physical switches huh). To create a switch, press the
button. The
configuration dialog box (shown below) will appear to set the type of device.
Any device can be changed by selecting the device and then pressing the
button in the toolbar. As a result you will get the same dialog as when
creating a new switch where you can change the type of device. Each type
of device has a different look. If you have a device that isn't
specifically listed, select the "Generic" type and then set the options that are
appropriate for the X10 device.
(Yea, I know the OK and Cancel buttons suck...but I will replace them)
Note that even when the dialog is displayed, the switches will continue to receive commands from the network and update accordingly until the OK button is pressed. Once all of the configuration has been created, save the configuration to an XML format file and store it in the same location that the application will be started from.
Every switch has capabilities that the statemachine needs to know to operate. By default, the switch is a plain wall outlet with nothing more than on and off capability. The switch is adjusted using the settings in the checkboxes. These are fully described below:
| Setting | Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Name | This is the name of the X10 device that will be displayed in the title of the device object. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Address | Use the up and down arrows to cycle through the addresses for the X10 device. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Type | A number of basic types are provided which set the general capabilities
to default values. These are described as follows:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Receive only | Set this option to indicate that the device is only capable of receiving X10 commands from the network. This is typical of the majority of devices on the X10 network. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Transmit only | Some devices can only transmit but cannot receive. Such devices are photocells or motion detectors. When this option is selected, all other options are disabled and all controls except the ON/OFF button will be disabled. To be true to the switch state machine, the application should disable the ON/OFF button; however, this would preclude being able to simulate the network since the user couldn't send the ON/OFF command to mimic what the actual network would do. The rationale here is that when you create the switch, you not only want to know that the device has sent the on or off command, but you may need to simulate it if it is driving macros. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Two-way | Set this option to indicate that the device is capable of both sending and receiving. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Simple DIM/BRI dimming | Most light switches respond to the DIM and BRIGHT commands; however,
wall outlets, relays, chimes, and photocells do not have a capability for
dim or bright. If this capability is enabled, the switch will DIM or
BRIGHT by 1/16th each time the command is sent on the network. Not
all switches respond the same to DIM/BRIGHT so a pulldown list is provided
which lists the increments that the switch can make. The default is
1/16 which is the standard for the original X10 switches. Newer
switches made by SmartHome and Leviton can dim in increments of
1/32. Select the increment that your switch supports. When
this box is set, the
and
 symbols will
be enabled on the switch. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Preset Dimlevels | Also known as Scenes by most marketing material. When preset dimlevels are enabled, the switch will respond to PRESET DIM HIGH and PRESET DIM LOW. Preset dimlevels allow you to move the slider to a specific position and then send the dimlevel. As a result, the switch will go to that dimlevel directly without having to send a number of BRIGHT or DIM commands. This feature is usually only supported on high end switches. When this box is set, the slider bar will be enabled and the button with the dim percentage will be enabled. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Stateful | Most X10 devices perform an action such as turning a light on or off. As a result, the device is maintaining some state which can be read if the device is two-way. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Stateless | Also known as "No state". Some devices do nothing more than take an action when their address is heard on the network. Such a device is a chime. The chime is neither on nor off, but when its address is heard with the ON command, it will chime. |
Rather than go through some detailed explanation of how the application works, it is easier to just experiment.
Example: How to configure as shown above:
Start the application using one of the methods describe below.
- Select the
- A dialog will pop up for you to give a name to the room. Type "Lights" without the quotes and press OK.
- Select the
- A dialog will pop up for you to give a name to the room. Type "Sources" without the quotes and press OK.
- Click on the tab for "Lights"
- Select the
- Deselect all checkboxes, select the box for "No state", set the address to E16, and set the name to "chime" then press the "OK" button.
- Drag the switch by clicking in the switch titlebar and move it to the upper left corner of the window.
- Select the
- Select the
- Select the
- Change the name to "foyer", the address to E10, uncheck the box for "No state", and check the boxes for Dimmable, Scenes, and Two-way, then press the "OK" button
- Drag the switch by clicking in the switch titlebar and move it near the other switch.
- Select the
You should now have a configuration similar to what is shown above. This method used the
The simplest way to run the client is as a WEB applet. The limitation of running the application as an applet is that the size of the applet desktop cannot be changed from the client and so the applet will run at a size of 1024x768. This can be changed by editing the x10home.html file to specify a different size. If the unsigned version of the applet is used on the WEB server, the applet will not be able to write its configuration file on the client machine.
The benefit of running the x10home as an applet is that nothing special has to be done for the server or the client to make it run. This allows any client that supports the Sun Java 1.4 plugin to run the code. When the applet is first run, it will look for the Java Runtime environment. If it is not found, it will attempt to automatically download the appropriate Java Runtime plug-in for the browser being used. Once the system has the Java Runtime plug-in installed, the applet will start and appear in the upper left corner of the WEB browser.
The distribution of the application provides the signed version of the precompiled source in the file x10home.jar. The source code to the x10home application is provided and can be compiled to create x10home.jar by the enduser. Java is byte compatible across operating systems so the precompiled x10home.jar file can be installed directly without any changes. See below for the differences in signed and unsigned files. It is always recommended that the source code be recompiled by the administrator; and, the precompiled x10home.jar file should only be used when the end user does not have the J2SE 1.4.1 (or later) JDK installed. The source can be compiled on either a Windows or a Unix machine using the commands listed below:
Unsigned JAR Signed JAR
Windows c:\x10web> makex10home.bat Unix (user) $ make x10home.jar
Windows c:\x10web> makesignedx10home.bat Unix (user) $ make signedx10home.jar Signed versus Unsigned:
An unsigned applet cannot read or write to files on a local computer. Conversely, a signed applet can. Normally Java applets are run in a secure "sandbox" where they cannot do any damage to the client machine. This is for everyone's protection. But, there are times when it might be reasonable to have an application write to the local computer hard drive.
Unsigned operation/limitations: Most Java applets that you will load on the internet are unsigned. They run transparently such that the user is not aware that they are even loaded. These applets typically do not need to read or write information to the local computer and so have no need to be signed. When x10home is loaded as an unsigned applet, it will function fully but will not be able to print or write any changes to the configuration to the local storage on the client. This may prove to be an advantage in that the client will still be able to load the configuration file x10home.cfg from the server that hosts the x10home.jar file and so a standard configuration of the X10 network can be automatically loaded and cannot be changed by the clients. After all, once a house is set up, it is rarely necessary to change the configuration.
Signed operation: The signed version of the x10home applet has the ability to read and write to the local directory from which the applet was started. There are two obvious scenarios where the ability to read/write locally is useful. First, even if the unsigned version of the applet is to be used by the clients, a configuration file must be created. Second, it might be useful for each client to have a different configuration for the network that is independently setup and maintained. The first case can also be resolved by running the applet as a standalone application (see below).
To make it easiest for an applet to be used for all users, the signed version is distributed with the source code. As a result, if the distributed version of the x10home.jar file is copied to the WEB server and loaded in a WEB browser, the following dialog box will be displayed:
This is telling you that the applet signature authenticity has not been verified by any agency and could be dangerous. If "No" is selected, the applet will still load, but it will not be able to save the configuration file (exactly as if it were unsigned). If "Yes" or "Always" is selected, the applet will be able to write the file x10home.cfg to the working director for where the WEB browser was loaded. This is very important!!! Make sure that you are in a location where you will always start the WEB browser when loading the applet, and that it is a location where you want the x10home.cfg file to be written. The configuration file contains the window size, window position, position of the vertical separator, the volume status, and the list of rooms and switches. It is in plain text and you can look at it and modify it at any time.
Startup: When x10home applet is loaded, it will attempt to load the configuration file named x10home.cfg from same directory as the x10home.jar file on the WEB server. If this fails, it will attempt to load the configuration file from the current directory on the client machine. If this fails, the application will start up with no rooms and no switches. If it succeeds at loading it from the WEB server, it will not attempt to load from the local client. This feature enables the administrator of the network to place the configuration for the home on a server and every client will start up with the same configuration regardless of what is on the local computer computer. Saving to a local computer is only available when running the signed applet. The client can, however, still save files to the local computer if using the signed applet and the local copy can be copied to the WEB server if improvements are made. This is the easiest method to produce the file for the WEB server.
Once the x10home.jar file has been created, it and the x10home.html file must be copied to a directory that the WEB server will host. For RedHat installations running Apache, the default location is /var/spool/www/html. The commands to copy these files would be:
# cp x10home.html /var/spool/www/html/
# cp x10home.jar /var/spool/www/html/
# cp x10home.cfg /var/spool/www/html/With everything installed, all that needs to be done is to load the x10home.html WEB page from a browser that has access to the server. No special parameters or options are required as the applet will connect back to the serving host automatically to access x10serv and the x10home.cfg file.
Let's make that real simple. If the server running the wish drivers is at IP address 192.168.200.2 running Apache with a document directory of /var/spool/www/html, and a Windows client is at address 192.168.200.4, to run the applet on the Windows client, the following commands would be used to run the applet (including installing starting the server):
Unix server at 192.168.200.2 Windows server at 192.168.200.4 # cp x10home.html /var/spool/www/html
# cp x10home.jar /var/spool/www/html
# cp x10home.cfg /var/spool/www/html
# cp x10serv /usr/sbin
# x10serv
#explorer http://192.168.200.2/x10home.html
The standalone application is a bit more difficult in that it requires that the user of the client machine have a bit more knowledge of the computer and the packages installed on the computer. If the Java applet can run on a computer, the Java Runtime Environment (JRE) is already installed; therefore, the user must know where the binaries are stored. The advantages of the standalone application are that it can read and write to the local file system and it does not require that a WEB server be available on the X10 server. When the program is run as a standalone application, it will have full access to the local resources (Printing, Read, Write) without the dialog display requesting permission. Another drawback of starting the application in standalone mode is that the user must be able to specify the server name when starting the application. Running as a standalone application is also another method to use the unsigned x10home.jar file to create a configuration to put on the WEB server.
The distribution of the application provides the signed version of the precompiled source in the file x10home.jar. The source code to the x10home application is provided and can be compiled to create x10home.jar by the enduser. Java is byte compatible across operating systems so the precompiled x10home.jar file can be installed directly without any changes. See below for the differences in signed and unsigned files. It is always recommended that the source code be recompiled by the administrator; and, the precompiled x10home.jar file should only be used when the end user does not have the J2SE 1.4.1 (or later) JDK installed. The source can be compiled on either a Windows or a Unix machine using the commands listed below::
Unsigned JAR Signed JAR
Windows c:\x10web> makex10home.bat Unix (user) $ make x10home.jar
Windows c:\x10web> makesignedx10home.bat Unix (user) $ make signed x10home.jar Once the x10home.jar file has been created, copy it to a location that you want to run it from. The configuration file will be written to the directory where the java application is started. For example, if x10home.jar is copied to /usr/local/bin/java/x10home.jar, if you run the applet from /home/user, the configuration will be written to /home/user/x10home.cfg. Similarly, if x10home.jar is copied to C:\Program Files\x10home\x10home.jar and it is run from C:\My Documents, the configuration file will be written to C:\My Documents\x10home.cfg.
The application can be run in standalone mode on a machine that either has the J2SE SDK or the JRE version (1.4.1 or higher) environment installed. These are both available for download from http://java.sun.com. The command is identical on both Windows and Unix as follows:
Windows C:\x10web> java -cp x10home.jar x10home.x10home server <hostname> Unix (user) $ java -cp x10home.jar x10home.x10home server <hostname> Substitute the name or IP address of the server running x10serv for <hostname>. A window similar to what is shown earlier will appear on the screen. Create the tabs and the switches, set up their configuration, and save the configuration to a file with the
button. If x10home is run from the same location, the configuration will automatically be loaded. If the x10home.cfg file is copied to the same directory as the x10home.jar file on a WEB server, the file will automatically be used as the configuration file when the applet is loaded from the WEB server.
Let's make that real simple. If the server running the wish drivers is at IP address 192.168.200.2, and a Windows client is at address 192.168.200.4 with the Java Runtime Environment installed in C:\Program Files\JavaSoft\1.4.1, to run the applet on the Windows client, the following commands would be used to run the applet (including installing starting the server):
Unix server at 192.168.200.2 Windows server at 192.168.200.4 # cp x10serv /usr/sbin
# x10serv
#C:\> mkdir C:\Program Files\x10home
C:\> copy x10home.jar C:\Program Files\x10home\
C:\> x10web> C:\Program Files\JavaSoft\1.4.1\bin\java -cp C:\Program Files\x10home\x10home.jar x10home.x10home server 192.168.200.2
C:\>Java GUI: x10templinc
x10templinc is an application that creates a popup window to display the temperature events as reported by your templinc. The application will show you a historical log of the temperature reported by the TempLinc as well as three tabs that show you a thermometer, historical graph, and options to control the application. You can specify that the measurements are reported in Celsius or in Fahrenheit and specify thresholds for the colors on the thermometer. To run the applet, the Java Swing library must be installed as well as a java runtime environment supporting Java 1.4. If you don't have a WEB browser that supports Java 1.4.1 or the Java plugin, you can use the appletviewer that comes with the Java Runtime Environment. You must also have the JFreeChart and JCommon libraries available for the application to operate.
The x10templinc client is written in Java and supports the standard capabilities defined by the X10 protocol and the SmartHome TempLinc device. This interface is a read-only interface as you cannot interact with the TempLinc sensor.
The X10 Templinc application reads its configuration from one of three files. First, if it can find the file x10templinc.xml, it will read the file expecting the following XML format:
<x10>
<options>
<soundEnabled>true</soundEnabled>
<autoadd>false</autoadd>
<showlog>true</showlog>
<rawlog>false</rawlog>
</options>
<tab name="anything">
<templinc name="Temp">
<locationX>374.0</locationX>
<locationY>430.0</locationY>
<address>O11</address>
<tempformat>F</tempformat>
<lowthreshold>32.0</lowthreshold>
<highthreshold>80.0</highthreshold>
</templinc>
</tab>
</x10>If x10templinc.xml is not found, the application will look for the file x10.xml of the same format. You can easily create the x10.xml file using x10home to set up the devices for the home and then saving the configuration. Copy the configuration to the same location that the x10templinc applet will be loaded from. Finally, if neither of these files are found, it will use the original format of x10home.cfg to try to load the configuration.
Below is a screenscape of the GUI interface. The client starts by opening a TCP connection to the server on the default port of 1418. To change the port, pass the parameter "tcpport" to the Java program when it is started or by modifying the WEB page that calls the client. For each Unit or Action command, the Client sends a UDP message to the server for the housecode. The udp port defaults to 1930 but can be changed by passing the parameter "udpport" to the Java program when it starts or by modifying the WEB page that calls the client. The client accepts the following parameters when it starts. Also, since you may be running the application without having run the x10home application, there is a parameter to specify the housecode when starting the server as a standalone device.
server The name of the server running x10serv. The name can be either a fully qualified domain name or an IP address. tcpport The TCP port used to for creating a stream to the x10serv server. The default is 1418. udpport The UDP port used for sending datagram messages to the x10serv server. The default is 1930 devicebase The base address for the devices. The default is "." and should match the argument used when starting x10serv. housecode Specify the housecode for the TempLinc. The default is "A". This option is provided so that the application can be run without having a configuration file. The default display when x10templinc starts up is a display of the log and a thermometer representation of the temperature as shown in the following screen shot.
To view the history of the temperature over time, select the History Tab as shown in the following picture:
The options tab allows you to control the settings of the application. Note that the settings are not saved between sessions with the application. The following picture shows the default options page:
The simplest way to run the client is as a WEB applet. The benefit of running the x10templinc as an applet is that nothing special has to be done for the server or the client to make it run. This allows any client that supports the Sun Java 1.4 plugin to run the code. When the applet is first run, it will look for the Java Runtime environment. If it is not found, it will attempt to automatically download the appropriate Java Runtime plug-in for the browser being used. Once the system has the Java Runtime plug-in installed, the applet will start and appear in the upper left corner of the WEB browser.
The distribution of the application provides the precompiled source in the file x10templinc.jar. The source code to the x10templinc application is provided and can be compiled to create x10templinc.jar by the enduser. Java is byte compatible across operating systems so the precompiled x10templinc.jar file can be installed directly without any changes. It is always recommended that the source code be recompiled by the administrator; and, the precompiled x10templinc.jar file should only be used when the end user does not have the J2SE 1.4.1 (or later) JDK installed. The source can be compiled on either a Windows or a Unix machine using the commands listed below:
Unsigned JAR
Windows c:\x10web> makex10templinc.bat Unix (user) $ make x10templinc.jar Startup: When x10templinc applet is loaded, it will attempt to load the configuration file named x10home.cfg from same directory as the x10templinc.jar file on the WEB server. Yes, you read that correctly. The x10templinc application uses the configuration written by the x10home appliation. If this fails, it will attempt to load the configuration file x10home.cfg from the current directory on the client machine. If this fails, the application will start with a default housecode of "A". If it succeeds at loading it from the WEB server, it will not attempt to load from the local client. This feature enables the administrator of the network to place the configuration for the home on a server and every client will start up with the same configuration regardless of what is on the local computer computer.
Once the x10templinc.jar file has been created, the x10starttemplinc.html, x10templinc.html and x10temlinc.jar files must be copied to a directory that the WEB server will host. Additionally, the lib/jfreechart-0.9.20 and lib/jcommon-0.9.5 must be copied to the subdirectory lib/ below the location where x10templinc.html is copied. For RedHat installations running Apache, the default location is /var/spool/www/html. The commands to copy these files would be:
# cp x10templinc.html /var/spool/www/html/
# cp x10templinc.jar /var/spool/www/html/
# cp x10starttemplinc.html /var/spool/www/html/
# mkdir /var/spool/www/html/lib
# cp lib/j* /var/spool/www/html/lib/With everything installed, all that needs to be done is to load the x10templinc.html WEB page from a browser that has access to the server. No special parameters or options are required as the applet will connect back to the serving host automatically to access x10serv and the x10home.cfg file.
Let's make that real simple. If the server running the wish drivers is at IP address 192.168.200.2 running Apache with a document directory of /var/spool/www/html, and a Windows client is at address 192.168.200.4, to run the applet on the Windows client, the following commands would be used to run the applet (including installing starting the server):
Unix server at 192.168.200.2 Windows server at 192.168.200.4 # cp x10templinc.html /var/spool/www/html
# cp x10templinc.jar /var/spool/www/html
# cp x10starttemplinc.html /var/spool/www/html
# cp x10serv /usr/sbin
# x10serv
#explorer http://192.168.200.2/x10starttemplinc.html
The standalone application is a bit more difficult in that it requires that the user of the client machine have a bit more knowledge of the computer and the packages installed on the computer. If the Java applet can run on a computer, the Java Runtime Environment (JRE) is already installed; therefore, the user must know where the binaries are stored. The advantages of the standalone application are that it can read and write to the local file system and it does not require that a WEB server be available on the X10 server. When the program is run as a standalone application, it will have full access to the local resources (Printing, Read, Write) without the dialog display requesting permission. Another drawback of starting the application in standalone mode is that the user must be able to specify the server name when starting the application. Running as a standalone application is also another method to use the unsigned x10templinc.jar file to create a configuration to put on the WEB server.
The distribution of the application provides the signed version of the precompiled source in the file x10templinc.jar. The source code to the x10templinc application is provided and can be compiled to create x10templinc.jar by the enduser. Java is byte compatible across operating systems so the precompiled x10templinc.jar file can be installed directly without any changes. It is always recommended that the source code be recompiled by the administrator; and, the precompiled x10home.jar file should only be used when the end user does not have the J2SE 1.4.1 (or later) JDK installed. The source can be compiled on either a Windows or a Unix machine using the commands listed below::
Unsigned JAR
Windows c:\x10web> makex10templinc.bat Unix (user) $ make x10templinc.jar Once the x10templinc.jar file has been created, copy it to a location that you want to run it from. The configuration file x10home.cfg must be in the same directory that the user starts the application from. For example, if x10templinc.jar is copied to /usr/local/bin/java/x10home.jar, if you run the applet from /home/user, the configuration must be located in /home/user/x10home.cfg. Similarly, if x10home.jar is copied to C:\Program Files\x10home\x10home.jar and it is run from C:\My Documents, the configuration file must be located in C:\My Documents\x10home.cfg.
The application can be run in standalone mode on a machine that either has the J2SE SDK or the JRE version (1.4.1 or higher) environment installed. These are both available for download from http://java.sun.com. The command is identical on both Windows and Unix as follows:
Windows C:\x10web> java -cp x10home.jar;lib\jcommon-0.9.5.jar;lib\jfreechart-0.9.20.jar x10templinc.x10templincApplet server <hostname> Unix (user) $ java -cp x10home.jar:lib/jcommon-0.9.5.jar:lib/jfreechart-0.9.20.jar x10templinc.x10templincApplet server <hostname> To make it simple, Makefiles have been created to simplify this process:
Windows C:\x10web> x10templinc.bat server <hostname> Unix (user) $ make runx10templinc server <hostname> Substitute the name or IP address of the server running x10serv for <hostname>. A window similar to what is shown earlier will appear on the screen. If the x10home.cfg file is copied to the same directory as the x10templinc.jar file on the server, the file will automatically be used.
Let's make that real simple. If the server running the wish drivers is at IP address 192.168.200.2, and a Windows client is at address 192.168.200.4 with the Java Runtime Environment installed in C:\Program Files\JavaSoft\1.4.1, to run the applet on the Windows client, the following commands would be used to run the applet (including installing starting the server):
Unix server at 192.168.200.2 Windows server at 192.168.200.4 # cp x10serv /usr/sbin
# x10serv
#C:\> mkdir C:\Program Files\x10web
C:\> copy x10templinc.jar C:\Program Files\x10web\
C:\> x10web> C:\Program Files\JavaSoft\1.4.1\bin\java -cp C:\Program Files\x10home\x10templinc.jar;C:\Program Files\x10home\lib\jfreechart-0.9.20.jar;C:\Program Files\x10home\lib\jcommon-0.9.5.jar x10templinc.x10templincApplet server 192.168.200.2
C:\>
This is a very small and simple DOM type XML writer and reader. The classe utilizes a recursive tree of objects to store the XML data in memory which can then be serialized to disk or can be traversed to retrieve the XML data. The class also includes a parser which will read an XML file from disk. It doesn't support much beyond the standard format of elements, attributes, and tags. Empty tags are supported as are entities. Documentation for the class is provided in the doc directory off the x10web root directory. The documentation can be reproduced by running "make javadocs". The format supported is as followed:
<?xml version="1.0" standalone="yes"?>
<!-- Comment -->
<rootname>
<tag>
<tag attribute1="value" attribute2="value">elementvalue</tag>
</tag>
</rootname>
The following are not supported:
How to create XML tree in memory to write to disk:
Example:
Results in the following:
<?xml version="1.0" standalone="yes"?>
<root>
<element1 attribute1="att1" attribute2="att2">value1</element1>
<element2 attribute20="att20">
<element21 attribute21="att21">value21</element21>
</element2>
</root>
Values for Elements and Attributes can be any type of object but will be converted to String by calling toString() before storing the value.
How to load XML tree from disk:
How to walk through the XML tree:
For a straight forward example of how to load, save the tree, look at the loadXML(), save(), savexmltree() in x10home.java. Walking the tree to retrieve information is illustrated in the methods applyCoordinates(), applyOptions(), and createObjects() in x10home.java.
The configurable x10 applets share the x10 state machine to simulate the activity of the X10 network. Documentation for the state machine functionality is provided in the doc directory off the x10web distribution. It can also be regenerated from the source code by running "make javadocs".
The configurable x10 applets share the x10 templinc state machine to simulate the activity of the X10 network with relation to a SmartHome TempLinc sensor. Documentation for the state machine functionality is provided in the doc directory off the x10web distribution. It can also be regenerated from the source code by running "make javadocs".
