3. Components in detail

3.1 MOSLER.TCL: the Tcl/Tk Graphical User Interface

The Tcl/Tk script mosler.tcl presents a graphical overview of the current status of the system with a screen like that shown in Figure Main-Screen. This real-time display of sensor readings is accomplished by mosler.tcl polling the solusd process for current values.

Each site or location (as in solus1, solus2 ...)is represented by a button showing the current reported readings from that location. More detailed information about the site can be viewed and edited by selecting the button, generating the display of a site-specific window as in Figure Site-Screen

Several notable indicators in the behavior of the mosler.tcl main screen:

• If an alarm condition has occured at a site since starting mosler.tcl then the color of the site-button will be altered to:
  • RED if the Hi-Temp mark was triggered.
  • BLUE if the Lo-Temp mark was triggered.
  This indication of alarm condition is a one-shot that needs to be manually cleared. Thus once an alarm is triggered and the color of the button has been altered no subsequent alarms conditions at that site are locally monitored. Thus for example if the temperature drops too low at the site and the button therefore turns BLUE, the button will remain BLUE regardless of possibly rising temperatures remotely -- i.e. the button will neither self-clear the BLUE nor will it register a hi-alarm point and turn RED on its own. One manually cleared by hitting the alarm status button in the details window corresponding to the site, watching for new alarm conditions resumes. Thus for example if remote temperature is still below the lo-Temp mark, the button will revert to BLUE upon recieving the next report from the remote datalogger. A more detailed look at temperature trends is available through the histroy button whence long term historical (i.e. data saved to disk by sollog) trends can be graphed.
• If a Tcp/Ip socket connection cannot successfully be established with solusd, then mosler.tcl will indicate this lack of connection with the sensors by having the Connected button UN-selected. See the section on solusd for information on the possible circumstances and remedies for this failure. Note that this indicator is for the connection to the solusd daemon only, and does not necessarily indicate that ALL defined datalogger are currently responsive. When the project grows beyond this single-datalogger stage to encompass large collections thereof, each site-button itself will contain an indicator as to the current responsiveness of the site.
• The Setup button spawns a window permitting the editing of some of the global settings as defined in the file Sensors.cnf Note that since all the processes only read this configuration file on startup, if things such as Data gathering interval or Directory for log files are altered they will not take effect until these processes are restarted. A button to accomplish this restart is provided in this window.
• In the process of editing either global settings or per-site settings via the provided GUI, various data structures are updated to reflect these edits. However for these changes to be saved and used the NEXT time the GUI (or other processes) run, they must be saved to disk. The save button updates the file Sensors.cnf with the current information. Likewise, the button revert discards any changes that have been made since the last time the configuration file was saved.
• Each individual site can be examined in more detail by selecting its button: see figure Site-Screen. From this site-specific window, the details of the site can be viewed and edited. The top items of contact and site information are all free-form text input fields are for the convenience of administration only: the information therein is not currently used by the control software. The selection fields below however ARE used:
  • Fields for baud rate and serial device specify communication parameters to the remote CT2500 datalogger device. It is up to the administrator to be knowledgeable about how standard and add-on serial ports are mapped to the UNIX (Linux) filesystem in /dev. For this demonstration phase, only COM1 (/dev/cua0) and COM2 (/dev/cua1) devices are available.
  • The sliders to set the Temperature HI and LO marks are active though only take effect upon the selection of either the done or apply buttons. By 'take effect' we mean that the values are updated internally for the purposes of flagging alarm conditions with colorful buttons as well as updated on the remote datalogger. Note that the remote-update will fail with a warning message if the attempt to communicate with it fails.
  • The live graph on the right side of the window shows a real-time graph of data collected on all three sensors for the site as of the last 30 minutes (about 1800 seconds). This is a live graph so if the molser.tcl program has been running for less than 30 minutes, the graph will be limited to the elapsed time since starting the program.
  • The history button spawns a window that prompts for a date-range and a single measurement (temp, humid, or volt) to graph over that range. Note that only one such long-term historical graph window can be spawned at a time.

3.2 SOLLOG: the solus data logging daemon

To be able to accumulated historical trends in the sensor readings, the sollog deamon is provided as a utility to log readings to disk file.

On startup sollog will read the global configuration file Sensors.cnf which informs it where to get the readings from (with the settings for datahost and dataport), how frequently to poll for the readings (pollinterval), and what file to append these readings to (logdir).

If any of these settings change -- for example by having edited them within the mosler.tcl GUI -- sollog will have to be re-started for them to take effect.

The log file that all readings are stored in is in the directory specified by the setting for logdir, with the filename "datlog". At this time, this file will grow forever as it is always appended to every time sollog has more data or is re-started. It is the responsibility of the system administrator to periodically do maintenance on this file -- for example by periodically archiving off its contents and truncating its length.

3.3 SOLUSD: the solus data gathering daemon

The base producer process, solusd is designed to be the only program that needs intimate knowledge of the hardware details of communicating out through serial COM devices to the CT2500 dataloggers.

After reading the Sensors.cnf configuration file, this program will attempt to establish communications with all the enabled dataloggers defined therein. This process includes gaining access to the serial port and sending an initialization sequence to the datalogger at the other end. Once this is done, solusd is ready to relay commands and data between client programs and the datalogger. For as long as it remains running, sousd remains in an infinite loop waiting for socket-connections and servicing the requests that arrive on those sockets.

solusd is also responsible for handling the electrical properties of the sensors installed and has knowledge of how to set alarm points and do the unit-conversions for each sensor. These capabilities are compiled into the program and the names of the sensors specified in Sensors.cnf must match one of the pre-defined names compiled into solusd.

The most common cause for failure in solusd is a problem on the serial line, thus a failure of the initialization sequence with a datalogger. These kinds of problems can generally be ironed out with the use of simple terminal programs (such as cu) to manually and interactively be able to verify serial devices, baud-rates, etc.