This is an addendum to Justin's fine README file with some additional things
that I ran into and further comments on setting up a web page to use the scripts
that Justin provided, or my modified versions. Justin is  a very
Linux-knowledgeable guy and tends to hope others that are doing this type of
coding are as well. This is a fair assumption. I just ended up having to do some
digging and thought I'd add my somewhat verbose blather in hopes it might help
out other semi-beginners such as myself.
- All the paths and files I mention are referring to a Red Hat Enterprise Linux
version 5 distribution. If you have other Unix/Linux, make the appropriate mods
to paths and the like.
Alan Dunwell - http://dunwellguitar.com/solardata/
Last Mod - 02/04/2008

Justin's web pages and contact info are at
   solar.js.cx.htm
---------------------------

DB9/RS-232 CABLE And CODES:
Justin mentions the problem of getting a cable into the Xantrex inverter which
has only 1" knockouts. He was clever enough to just cut off the sides of his
factory made cable. I have access to a good electronics supply house, so I just
bought the plugs and  a length of cable and soldered it up myself all for about
$8.00. I first unscrewed one of the plastic  plugs and drilled a hole in it the
size of the cable. I then slid the cable through and soldered the plug on. This
allowed me to thread the plug back in, plug in the plug, and then use some RTV
Silicon bathtub caulk to seal around the wire at the plug. If you want to do
this you really only need to solder three wires, pins 2, 3, and 5. The info at
    http://en.wikipedia.org/wiki/Serial_Cable
is good reading and further searches will bring up wiring diagrams.
 
For those interested in the details of what Justin's scripts do that talk to the
Xantrex Inverter, the RS-232 communication codes are available on the Xantrex
site at
    http://www.xantrex.com/web/id/172/p/docs/pt/2/product.asp
along with much other documentation for the inverter. Just click on the desired
file. 
- Note that there is also a pre-made Windows application at this location, click
on the link
    GT Solar Inverter Monitor
that will do some amount of chat with the inverter and display the info, and can
also save to files.
 
GNUPLOT "OLD" AND "NEW" PNG SETTINGS:
Even though I have the latest/greatest version of RHEL5, it's version of gnuplot
is not the greatest. In particular, in Justin's scripts that build the gnuplot
files, such as power_graph.gplot, he uses the current gnuplot type of notation
of
  print power_graph_gnuplot_fh "set term png size 960,480\n";
However, with my older version the "size" throws an error. It was necessary to
revert to the older notation of
  print power_graph_gnuplot_fh "set term png picsize 840 420\n";
with "picsize" and no comma. I have inserted notes in my files about this as a
reminder. Also see
   http://www.gnuplot.info/docs_4.0/gnuplot.pdf
and the section under Commands, Set, Terminal, png{old|new} Justin says that he
built with gnuplot 4.0 patchlevel 0, so anything after that should be OK. 

SERIAL PORT SOFTWARE FOR PERL:
This is needed so that the perl .pl files will be able to talk to the Xantrex
Inverter via a serial port and RS-232 via a DB9 cable.
I ran into a problem by not paying attention to the versions of the serial port
software and the version of perl. You need to make sure that you  
  1) match them
or
  2) put an explicit path to the serial port software in the head of each of the
perl scripts (or in the localvars.pm file). 

I was originally using Red Hat Enterprise  Linux version 3 (RHEL3) and 
downloaded a recent version of the serial port software.
  http://search.cpan.org/dist/Device-SerialPort/SerialPort.pm
shows most current version, now V1.04 in tar.gz format. This page also has
details on usage and such. Installation will put it down the perl chain in
something like
  /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Device/SerialPort
and
  /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Device/SerialPort.pm
and also man pages, etc. Note that if you have differing versions, for example,
  /usr/lib/perl5/site_perl/5.8.0/...
or some such, it will still make the 5.8.8 branch for the new SerialPort parts,
but they will not be found by the 5.8.0 perl when executing the .pl files with
just calls by name. If you have this type of mismatch, you must include a line
at the top of the .pl files such as
    use lib '/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Device/'
or 
   use lib '/your-path-to-all-the-cgi-scripts-here'
so that it will know where to look for the .pm file. I had to do this with my
RHEL3 box. When  I switched to RHEL5 then perl and the serial port software
matched and it wasn't necessary. 

A good site for further reading on serial port stuff is at the Linux Doc.
Project at
   http://tldp.org/HOWTO/Serial-HOWTO.html

SERIAL PORT DEFINITION:
Justin has two lines in the localvars.pm file for specifying your serial port.
Your system  may well have multiple serial ports and some may be in use. You
will need to select one that you connect the DB9 cable to. You can look with
   dir /dev/ttyS*
to see the list of ports available, usually [0-3] and try to match to your cable
port. Often they are labeled on the box near the ports, sometimes as COM1 or
COM2, etc. Once determined,  perhaps by trial and error, then specify that port
in the localvars.pm file both for the  serial port itself and also for the lock
file used in /tmp 

CGI SCRIPTS AND CGI-BIN DIRECTORY:
I added in a variable into Justin's localvars.pm file that explicitly includes
the  path to my cgi-bin area. Since in is used by multiple scripts this seemed
to be a better place to put it rather than including it at the head of all the
separate scripts. 

APACHE CONFIGURATION:
Once you are accessing the inverter and saving data out to your MySQL database,
the .cgi scripts that Justin or I provide can be called from web pages to
display the data. Justin provides a nice beginning script. However, you need to
do some mods to your httpd.conf file
    /etc/httpd/conf/httpd.conf
Listed here are some of the mods I made in the order they appear in my file. 
-this one is to include the ExecCGI so that your .cgi scripts can be executed.
This is a global level define, perhaps not needed if you explicitly include this
in your ScriptAlias below.

# The Options directive is both complicated and important.  Please see #
http://httpd.apache.org/docs/2.2/mod/core.html#options
# for more information.
#
#!!!    Options Indexes FollowSymLinks
    Options ExecCGI Indexes FollowSymLinks


- You need, or at least it is desirable, to specify a ScriptAlias that points to
the area where all your .cgi scripts live. You then set all the parameters for
that area. This is the same path I included in the localvars.pm file. The Alias is 
also the part I use for my html web pages to link a button to a .cgi script, in the form
of "http://dunwellguitar/SolarData/cgi-name-here"
 
#!!!+ ScriptAlias for the SolarWebMonitor program cgi-bin stuff. 
#    Directory commands to make the Server Side Includes (SSI) and 
#    the cgi scripts execute.
ScriptAlias /SolarData/ "/usr/local/solar-web_monitor/cgi-bin/" 
<Directory "/usr/local/solar-web_monitor/cgi-bin">
  AllowOverride None
  Options +ExecCGI +Indexes +Includes
  AddHandler cgi-script .cgi .pl
  Order allow,deny
  Allow from all
</Directory>
#!!! -

- just uncomment this AddHandler define and include the .pl suffix so that the
perl scripts will run

# 
# AddHandler allows you to map certain file extensions to "handlers": 
# actions unrelated to filetype. These can be either built into the server 
# or added with the Action directive (see below)
#
# To use CGI scripts outside of ScriptAliased directories: 
# (You will also need to add "ExecCGI" to the "Options" directive.) 
#
#!!! uncommented  and added .pl
AddHandler cgi-script .cgi .pl

Remember that you need to do a restart on your web server damon. I just use
    /etc/init.d/httpd restart
which is not graceful at all but since I'm the only one on my server I  really
don't care <G>.


WEB PAGES:
This part is pretty much up to you. You will need to create some HTML code that
will call and display the info using the .cgi scripts, and a discussion on how
to do that is way beyond this little addendum page. Just for reference,  I use
Macromedia's (now swallowed by Adobe) Dreamweaver MX software for creating my
web pages
   http://www.adobe.com/products/dreamweaver/?ogn=EN_US-gntray_prod_dreamweaver_home
I also use a nice little program called FreeButtons
   http://www.cleansofts.com/get/935/23421/Free_Web_Buttons.html
that not only lets you create buttons of various flavours, but it also will 
generate the html code for their use that can then be copied to Dreamweaver 
with little modification.

SCRIPT MODS:
I have modified the two main web page scripts, cost_graph.cgi and power_graph.cgi, the
later quite heavily. Although I've attempted to annotate with comments starting with 
the flag of #!!!, my mods by version-2 of the power grapph were quite involved so I 
suspect I haven't flagged everything. If you are interested in my changes you should 
look at Version-1 first and compare it side by side to Justin's code. Version-2 is a 
thing unto itself. 

In particular, I've added into the header of the power graph a bunch of buttons and 
and entry field for specifying a date. This allows me to do a better evalation of the 
performance of the installation. The Previous/Clear/Next buttons and the related code 
are funning through javascript routines. The overall idea is on any date entry in the 
fields and the Apply button, the .cgi script calls itself again passing back in the 
values entered in the date fields. These are extracted off as input date inof and then 
sutured into the code. The snippet of javascript 
   function nextbox(fldobj, nbox)
is just an auto-tab for the entry fields while the function
   function setLocation(url)
does the re-call if the Previous/Clear/Next buttons are used. These need to use a passed
through flag to indicate the action to take and this is handled in the perl code near the 
top to set the date and adjust the perl variables. It was interesting to find out that there
seems to be NO WAY to actually modify perl variables direcly from html or javascript code, 
thus all the around-Robin-Hood's-Barn stuff to recall passing in the parameters.
