A placeholder section for future expansion of the project software modules and documentation thereof. Scope, behaviors, interdependencies, and interactions of the components will be documented here to permit the addition of customizations.
All files are human-readable (i.e. regular text files viewable by any text editor, and likewise printable) and line-oriented. Comments can be embedded by starting a line with the # character -- these lines will be ignored by the programs that parse the files. In general, fields of key-words and/or data are white-space separated (tabs and/or spaces) and do not extend beyond the end-of-line character.
A large and exhaustive file specifying the total configuration of the monitoring station. There is a section of global settings, followed by 'paragraphs' describing each datalogger-site.
symbolic name of TCP/IP host that solusd runs on.
Default: localhost
port number that solusd will accept connections on.
Default: 4111
Clients such as sollog, mosler.tcl will poll for
data every pollinterval seconds. Default: 10
Clients such as sollog, mosler.tcl look in this
directory for the datlog file to read from (mosler.tcl) or
write to (sollog).
site
site {site-name} {site-id-#} {local-serial-device} {baud-rate} {..comment}
is a tokenized 16-character max. name for the site that will appear on the site-button in the GUI. No spaces, only characters and numbers.
is a number that is internally used to identify the site. Normally these numbers will be sequential from site to site. A '0' in this field indicates that this site is NOT active.
is the name of the serial device that is dedicated
to communicating with the datalogger. For example, if connected to COM1, the
name of the device is /dev/cua0.
baud rate of the connection -- typically 9600 but could be less if slower modems are used.
the remainder of the line after baud is iterpreted as
additional information or comment for the site and is ignored.
After the site specification, all sub-specifications for that site are
distinguished by lines begin with leading white-space. Thus the
site keyword starts a site-paragraph, and all information pertinent
to that site is indented from it up to the NEXT line that begins with a
site key-word, marking the start of the definition of a new site.
First there are lines concerning contact information at the site. These fields are for the convenience of the administrator only as they are unused by the control software.
{white-space} {contact-keyword} {contact-info}
everything to the right of this keyword is a name.
everything to the right of this keyword is a phone #.
Finally, the sensor configuration is defined in space-separated fields,
indicated by the keyword sensor
{white-space} sensor {name} {sensor-id-#} {hi-alarm} {lo-alarm}
identifies type of sensor. Note that this name must match one of the compiled-in names of sensors provided as this name determines all the electrical and engineering-unit-conversion properties of the sensor. Currently defined sensors are:
a numeric code for this sensor -- '0' means disabled.
if present, marks a hi-alarm point, only supported with temperature.
if present, marks a lo-alarm point, only supported with temperature.
The sollog process will always open this file in APPEND mode
and begin with a time-stamp line that is commented out with a leading '#'.
Thereafter each line consists of:
{datalogger-id-#} {time-stamp} {sensor#1} {sensor#2} ...
id# of the datalogger that this record is from
integer representation of time/date of the readings
readings from each of the sensors in the order declared in the
configuration file Sensors.cnf
All live InterProcess Communication is accompished with TCP/IP SOCKETs using a proprietary port-id and custom command set. Thus should further development be necessary, this command set can easily be expanded. Currently it is limited to instructions to retrieve current sensor readings and setting new alarm trigger points.
A placeholder section for future expansion of the project software modules and documentation thereof. Internal shared data structures will be documented here to permit development of more sophisticated IPC (InterProcess Communications) protocols should the need arise.