Computer System Details

The sources of data are the SMA Sunnyboy SB5000US inverter in the solar electric system, the Davis Vantage Pro weather station which reports a whole set of observations of which solar radiation and temperature are used here, custom hardware which monitors the Steca TR 0603mc U controller and the other devices in the solar thermal system, and the Brultech ECM-1240 home energy monitor which measures the electrical power used by the heaters and pumps in the thermal system.

Server and Associated Hardware
The server hardware is a four-core processor in a workstation class motherboard. A 4 port RS-232 PCI card is used to talk to the data providers. Two of the data providers use RS-485, so a couple of stand-alone opto-isolated RS-485 to RS-232 converters are used to do the signal conversion.

The Sunnyboy inverter is located in an out-building. It uses RS-485 at 1200 baud so there is no problem wiring to it over several hundred feet using CAT5.

Server Software
The server runs FreeBSD with ZFS, and the Apache2 web server with mod_perl. All of the software from data acquisition to CGI is written in Perl, about 10k lines of code. The software system is divided into five daemons.

Three daemons talk to their assigned hardware and convert what's read from the hardware into the appropriate format. The processed real-time data is then written to a common Unix socket. The fourth daemon acquires the solar thermal data and processes it for the same socket as the others, and it also uses this data to run a software model of the solar thermal system. This model is then used to generate the animated display which is created with the Perl GD module.

The fifth daemon sucks up all the processed real-time data and generates several products for both the LAN-connected dedicated displays and the web. It outputs products to Unix sockets, TCP sockets and the file system. All of the graphics created by this daemon are done with the Perl GD module. All the astronomical calculations are done with the Astro::Coord::ECI module.

The LAN-connected displays run FreeBSD and X11. The interactive display software is written in Perl/Tk. Displays are 1080p and what is shown can be changed dynamically using drop-down menus, function keys or through an IR remote control. The remote is set up to use MCE button encodings, and it is implemented using webcamd and lirc. The display system is discussed in more detail here.

Perl/Tk gives good visual and functional results, but it suffers from memory leaks. Tk::Animation leaks badly and it can't be used for a long-lived process that updates the animation with new frames. It was therefore necessary to write a new animation routine built around Tk::repeat. Even though considerable effort was put into fixing the leaks, it was necessary to include code to restart the process when it grows too big.

PV
The Sunnyboy software interface uses a complex packet protocol which is not completely documented in the public domain documentation. Much of this driver is built upon the Perl code provided by Gray Watson at 256.com. He figured out all the hard stuff. Changes were made to increase the update rate from once a minute to six times a minute by dividing the parameters into two groups with different update rates. It was so slow due to the large number of bytes being passed at 1200 baud. Changes were also made to reduce the boot-up time from about 8 minutes to 1.5 minutes. The inverter's firmware must be common across a wide product line because when asked about what parameters were available it would respond with data about wind turbines and other non-PV technologies.

Weather
The Vantage Pro has a fairly simple well-documented serial interface. There are several software packages available on the web to talk to this hardware. The Vantage Pro has its own non-volatile archive memory as well as the ability to report real-time data every 2.5 seconds. This driver was first written here in C in 2002 and then upgraded and converted to Perl in 2009. It acquires data every 2.5 seconds.

Thermal Monitoring
The Steca controller has a serial interface but they do not publish how to use it. The controller is marketed in Europe with an external display but not so in the US. To see what the controller sees and what is does, a data acquisition module was wired to the controller's inputs and outputs. The device used is a SuperLogics ADC-1R2-485 which is an 8 channel, 12-bit analog data acquisition module with 16 digital I/O lines and an RS-485 serial interface. Since this device is marketed for data acquisition, it has a simple well-documented interface and requires the least complex driver. Data is acquired every 5 seconds.

Steca uses platinum RTDs for temperature. To get one degree F resolution you need one mV resolution at the A/D converter. With the voltages present you really need 13 bits to get to 1 degree, so the temperatures shown on the animated display at not exactly the same as the Steca is seeing. Fortunately all those temperatures are just for show. The two temperature sensors that are needed for the power calculation are not connected to the Steca. They are implemented with AD590 integrated temperature sensors and provide 0.1° F resolution.

Flow rate is measured with an Omega FTB2004 Hall-effect turbine flow rate sensor which outputs a pulse frequency proportional to the flow rate. This output is connected to a 32 bit counter in the ADC. The sensor has a maximum operating temperature rating of 212°F. At temperatures above 130°F it has been observed producing spurious pulses about 1 usec. wide following the negative edge. It was necessary to add a low pass filter to remove them.

Thermal Control
The Steca controller is configured to transfer heat to one of two heat exchangers with the domestic hot water tank set to have the highest priority. When heat is being transferred to the floor (the low priority), the controller runs a priority test which is to stop the collector pump every 30 minutes, wait two minutes, and then restart the collector pump. If the collectors have heated enough during the stop period, the controller switches to the higher priority heat exchanger.

In practice, this priority protocol does not work very well and gets worse as the temperature of the hot water tank increases. The controller only has the temperature of the collectors upon which to make this decision, and when heating the floor, the collectors run at a much lower temperature than is needed to heat the hot water tank. The two minute wait period isn't long enough for the collectors to reheat.

To implement a smarter priority protocol, a bit on an output port of the ADC is wired to increase the temperature of the floor as seen by the controller. When the server wants to give priority to the hot water tank, it sets the ADC control bit which causes the Steca controller to think the floor is 40°F hotter than it actually is. The controller stops putting heat into the floor because it thinks the floor has exceeded is maximum allowed temperature.

The priority protocol running on the server uses the output of the PV system to know what the sun is doing. The PV system was chosen over the weather system's global irradiance sensor due to the simular tilt and orientation of its panels, and a higher data update rate.

Power
Brultech Energy Monitor has a fairly simple but not well documented serial interface. However there are links on the Brultech site to several drivers written by others. Some of these links point to source code where the data format for the streaming data protocol is documented. The interesting thing about the streaming data protocol is that once it is turned on it pushes data whenever it becomes available with no ability to do flow control.

The Brultech box can be programmed with both a delta power threshold and a time threshold. When either threshold is met, the unit outputs data. If you are monitoring a modern electric cook top, its elements cycling on and off produce frequent large power fluctuations. These fluctuations easily meet useful power thresholds, and they produce a constant stream of data from the Brultech.

The driver was written so that is can't block for more than a couple of seconds and therefore will not generate serial I/O overflows in the kernel. The daemon is run with a real-time scheduling priority using the rtprio(1) command, and the serial interface card has UARTs with 128 byte FIFOs.