Computer System Details
The solar systems are monitored through a combination of custom and off-the-shelf
hardware and custom software. Four sources of real-time data feed a server
which archives the data and it produces the web pages for remote access and it
produces the content for the real-time displays connected to the local network.
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 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.
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.
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.
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.
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.