1 

FGCU Solar Connectivity

Nicholas Minckler

Maintenance Report

April 24th 2015

CEN 4935 Senior Software Engineering Project

Instructor: Dr. Janusz Zalewski

Software Engineering Program

Florida Gulf Coast University

Ft. Myers, FL 33965

2 

1. Project Overview

1.1 General Project Overview

This project is one of multiple in a series that attempts to collect data from Florida Gulf

Coast University's solar arrays and display it in a way that is both meaningful and accessible.

The previous project's intent was to create an analysis and visualization of the data retrieved

from the 16-acre solar farm on the FGCU campus, specifically the solar panels powering

Academic Building 7. It accomplished this task through a Java application, SolarFlare paired

with a PHP site [1].

SolarFlare was a continuation of two other projects, Solar Cloud – Rapid Data Logging

from a Solar Power Plant [2], daVinci: Solarems Data Extraction [3], and daVinci: eBox 4868 –

Sentalis Fetch CSV Server [4]. While the application could be considered finished, it is far from

polished and the goal of this project is to maintain and improve upon the existing design. Figure

1 illustrates a basic interconnection of the data logger (Sentalis 1000) and the Solar Arrays

FGCU operates. 

Figure 1: Solar Farm, AB7, and data logger interconnectivity [1]

3 

The previous project, SolarFlare was developed, due to the projects that came before

being highly dependent on browser automation [1]. This approach was found to be too hands-on

and required high maintenance, so a new way of fetching and storing the data was needed. Using

Java's java.net libraries, the software could emulate a browser and crawl over the HTML file

of the solarems.net website to fetch the data [5]. The Java application maintains a SQLite

database that the PHP site then fetches from to display the user-requested data in a sequence.

To view the data, the SolarFlare application is created as a background application that is

run on the server that updates at periodic intervals by utilizing the webcrawler and updating the

database with the data retrieved. The site accesses the data through PHP's PDO (PHP Data

Objects), and displays these data in the form of graphs using a Javascript library, Highcharts.

The SolarFlare system in entirety is controlled by two users: and admin, and a client as

shown in Figure 2. Only the admin has access to the Java application located on the server.

When activated, the application will constantly update a database from the solarems.net

site, which is fed data from the Sentalis data acquisition unit, which records live data from the

solar array at FGCU. The user can then view this data as displayed on the server site, also hosted

on the server, but accessible from any location. 

Figure 2: SolarFlare Physical Diagram

4 

1.2 General Overview

The system is comprised of five physical entities, as shown in the physical diagram in

Figure 2. The server that contains the SolarFlare application has the webcrawler, database, and

site hosted on it. The webcrawler fetches data from the SolarEMS data server, which is fed its

own data from the Sentalis data logger. These data are finally retrieved from the solar farm at

FGCU. The end product of this system is a user interface on the SolarFlare server that a user can

access over the Internet using the URL: http://solar.fgcu.edu

This project is the maintenance of the SolarFlare application and its adjust Server Site.

The original project succeeded in many of its goals, but problems remain. Very infrequent

crashes still occur, the system could become more modular, and more features could be added

upon request. The original project's description is as follows.

The SolarFlare project in full intended to:

1. Create a user-interface to access solar farm data in a database

2. Create a background-application that writes to a database and utilizes a web crawler

3. Connect to the solarems.net website in order to fetch the data from it.

The context diagram of the SolarFlare application and its adjunct server site is shown in

Figure 3. The diagram describes the existing application and its components. There are three

main entities that SolarFlare interacts with in order to provide this service:

1. The admin which starts it

2. solarems.net, which hosts the data

3. The database which stores the data retrieved

Neither the server site nor the client interacts with the SolarFlare application. Instead, the

server site accesses the SQLite database that SolarFlare periodically updates to construct graphs

to display the data, which the client can then view. 

5 

Figure 3:Double Context Diagram for SolarFlare and Server Site

6 

1.3 Software Requirements Specification

Following the discussion in section 1.2 and the context diagram in Figure 3, specific

software requirements are placed separately on the SolarFlare Application and the Server Site.

▪ SolarFlare Application Requirements

The SolarFlare application shall allow interaction with an admin, to be started

and terminated.

The SolarFlare Application shall request HTML pages from solarems.net

and be able to accept the response.

The SolarFlare Application shall parse the HTML files into meaningful data

under the following headers:

Power Variables

AC Current Phase A

AC Current Phase B

AC Current Phase C

AC Energy Total 

Environmental Variables

Ambient Temperature

Wind Speed Wind

Direction

Equipment Variables

DataLogger Temperature

Cell Temperature

Horizontal Irradiance

POA Irradiance 

The SolarFlare Application shall upload rows of data to a SQLite database

every fifteen minutes after receiving data from solarems.net

The SolarFlare Application shall display a report of recent data uploads upon

admin request.

▪ Server Site Requirements

The Server Site shall accept and respond to HTTP requests for the site

solar.fgcu.edu .

The Server Site shall retrieve data from the SQLite database using the PHP

PDO function upon request by the client.

The Server Site shall accept form requests by the client in the form of PHP

GET and POST.

The Server Site shall ouput data retrieved from the SQLite database in

Javascript Highchart.

7 

The Server Site shall be able to format its data query to the SQLite database

using a URL query string.

The Server Site shall be able to obtain a URL query string when the client

submits a PHP form with requests in the following formats:

15 minute increments

Days valid for the given month

Months

Years

Amount of records (four recorded per hour)

A combination of all of the above, in respect to the first record

being on 4/1/2010 18:45

The requirements stated above form the ideal guidelines to the project completion;

however, since this is in fact a maintenance project, more practical issues dominate the

development.

8 

1.4 Design Description

1.4.1 Software Architecture

The SolarFlare system is based primarily around the Java application. The background

process is comprised of three parts:

A WebCrawler that fetches a page's HTML file.

A File Parser that reads the page

A Database Manager that connects and writes to the existing database.

All of this is controlled by a timer that ticks every fifteen minutes to tell the entire

process to fetch data. The architecture of the software is shown in Figure 4. 

Figure 4: SolarFlare Architecture Diagram

The WebCrawler portion of the software uses the java.net libraries to connect with

the solarems.net site. The methods are given the login information and specific URLs to

traverse in order to fetch the entire HTML page. That data are sent through the HTML Parser

which uses a set of field names to pick out the specific data points and their labels, which it then

sends to a Database Manager. The Database Manager connects to a SQLite database and inserts a

row containing all of the information that was parsed from the site.

Once the data are transferred to the database, the Server Site and its clients are its

consumers. As shown in figure 5, the process begins when a client sends a to the server. The

9 

PHP of the Server Site runs and constructs a PDO object, which accesses the database and

retrieves the requested rows of data. The data and the rest of the site is augmented by external

Javascript libraries which enhances and edits the HTML on a client-side level. The full response

is then displayed to the client. 

Figure 5: PHP Server Site Logic Diagram

1.4.2 Detailed Design

The detailed design of the software is provided in two parts

A class-diagram of the Solar Flare software to display a static perspective (Fig 9).

A set of flowcharts that describe the functionality of the system and its general use

The architecture of the SolarFlare application was described in section 1.4.1. Figure 6 is the

software's class diagram, which shows the structure of the components, all of which are run

through a thread of the SolarFlare class. 

10 

Figure 6: SolarFlare class diagram 

 

Figure 7: SolarFlare Flowchart [1]

The general process of SolarFlare's functions is described in the previous section and in

Figure 7.

The Server Site has its own set of general actions when a data page is initialized. The user

first requests the HTML, which the server acknowledges. The PHP runs before the request is

11 

completed, which includes the connection to the database, the query to said database, the

generation of data, formatting of the charts, and finally returning the HTML for the site. This

process is shown in Figure 8. 

Figure 8: Solar Site Flowchart [1]

12 

1.5 Implementation and Testing

1.5.1 Implementation

The entire software is implemented in two parts, following the Design Description in the

previous section:

The Solar Flare Java application which downloads data from solarems.net

The Server Site which holds the application and hosts a PHP webpage on

solar.fgcu.edu

The Solar Flare Java application is further split into three parts:

A WebCrawler

An HTML parser

A Database Manager

Each of these three parts is controlled by a main function that is tied to a fifteen minute timer.

All of these parts are contained in a thread that is set to run in the background, allowing the

software to be hidden from the server admin when not actively using it.

The SolarFlare application (code snippet below) begins by creating a thread of itself which

initializes its parts and utilizes them individually. The HTMLNavigator takes arguments of a

login and password, and then a list of URLs to navigate to attempt to retrieve the HTML files in

the form of a string. The Parser then accepts an argument from an external list of attribute names

to scan the string for matching names, only to insert them into a SQL string. That string is then

passed to the Database Manager to send an Insert query with the values retrieved. Afterward, the

thread sleeps for 15 minutes.

public class SolarFlare implements Runnable { public void run() { while (true) { try { HTMLNavigator website = new HTMLNavigator(); DBManager database = new DBManager(); ... website.login(...); ... String[] urlsToNavigate = { "https://solarems.net/projects/36-fgcu-ab7/overview",

13 

"https://solarems.net/projects/36-fgcu-ab7/data_sets/26",}; ... HTMLPage = website.fetch(urlsToNavigate); ... while (AttributeNames.hasNext()) { HTMLParser parser = new HTMLParser(HTMLPage); String attr = AttributeNames.nextLine(); String field = fieldNames.nextLine(); Double value = parser.getValue(attr); } stringOfNames = stringOfNames.substring(0, stringOfNames.lastIndexOf(",")); stringOfValues = stringOfValues.substring(0, stringOfValues.lastIndexOf(",")); String SQL = "INSERT INTO \"Values\" (\"utc_timestamp\"," + stringOfNames + ") VALUES " + "("+ "'" + lastUpdate +"'"+ "," + stringOfValues + ")"; ... database.connect() database.update(SQL) Thread.sleep(900000); } } } The WebCrawler is the heart of the SolarFlare application and handles the data-

acquisition portion of the overall process. While it contains many methods, the two core

proponents of it are sendPost(...) and GetPageContents(...). SendPost(...)

functions by establishing a connection using the java.net libraries and setting a number of

properties before using a set of post parameters given through a parameter to the method itself to

write a request to the host server and then read the response through the opened connection. Its

basic code is shown below. 

 

private void sendPost(String url, String postParams, String refer) throws Exception { URL obj = new URL(url); conn = (HttpsURLConnection) obj.openConnection(); // Acts like a browser conn.setUseCaches(false); conn.setRequestMethod("POST");

14 

conn.setRequestProperty("Host", "solarems.net"); conn.setRequestProperty("User-Agent", USER_AGENT); conn.setRequestProperty("Accept", "text/html,application/xhtml+xml,*/*"); conn.setRequestProperty("Accept-Language", "en-US"); for (String cookie : this.cookies) { conn.addRequestProperty("Cookie", cookie.split(";", 1)[0]); } conn.setRequestProperty("Connection", "keep-alive"); conn.setRequestProperty("Referer", refer); conn.setRequestProperty("Content-Type", "application/x-www-form-urlencoded"); conn.setRequestProperty("Content-Length", Integer.toString(postParams.length())); conn.setDoOutput(true); conn.setDoInput(true); // Send post request DataOutputStream wr = new DataOutputStream(conn.getOutputStream()); wr.writeBytes(postParams); wr.flush(); wr.close(); int responseCode = conn.getResponseCode(); System.out.println("\nSending 'POST' request to URL : " + url); //System.out.println("Post parameters : " + postParams); System.out.println("Response Code : " + responseCode); BufferedReader in = new BufferedReader(new InputStreamReader(conn.getInputStream())); String inputLine; StringBuffer response = new StringBuffer(); while ((inputLine = in.readLine()) != null) { response.append(inputLine); } in.close(); } GetPageContents(...) functions in a similar way. This method creates a number of

properties in order to tell the host site that the application wishes to be treated as a browser. Once

15 

the properties are set, it can read the HTML file through the open connection and return it as a

string. The basic code is shown below.

private String GetPageContent(String url) throws Exception { URL obj = new URL(url); // Connect to website conn = (HttpsURLConnection) obj.openConnection(); // default is GET conn.setRequestMethod("GET"); conn.setUseCaches(false); // act like a browser conn.setRequestProperty("User-Agent", USER_AGENT); conn.setRequestProperty("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"); conn.setRequestProperty("Accept-Language", "en-US,en;q=0.5"); if (cookies != null) { for (String cookie : this.cookies) { conn.addRequestProperty("Cookie", cookie.split(";", 1)[0]); } } int responseCode = conn.getResponseCode(); System.out.println("RESPONSE CODE: " + responseCode); BufferedReader in = new BufferedReader(new InputStreamReader(conn.getInputStream())); String inputLine; StringBuffer response = new StringBuffer(); while ((inputLine = in.readLine()) != null) { response.append(inputLine); } in.close(); // Get the response cookies setCookies(conn.getHeaderFields().get("Set-Cookie")); //System.out.println("COOKIE: " + conn.getHeaderFields().get("Set-Cookie")); return response.toString(); }  

The Web Parser portion of the SolarFlare application is far less intensive, but no less

crucial. It contains a single method, getValue() in order to scan a given string, which the main

16 

thread supplies from the HTML file. In short, the method takes the requested attribute as a

parameter and reads lines from the string until it is found. The way that solarems.net is

structured, the value of the named field is on the next line, which is read and parsed into an

integer to be returned to the main thread.

public Double getValue(String attributeName) { ... while (byName.hasNext()) { String currentLine = byName.next(); if (currentLine.contains(attributeName)) { ... Scanner byValues = new Scanner(currentLine); byValues = byValues.useDelimiter("value\">"); byValues.next(); if (byValues.hasNext()) { String valueString = byValues.next(); ... try { double value = Double.parseDouble(strVal); return value; } catch (Exception e) { return null; } } } } ... } The Database Manager is the last step in the SolarFlare application's loop. Utilizing

java.sql libraries, managing the connection and the insertion of the database can be shown in

just two lines. While properties have to be set for the database driver and the location of said

database, to connect and query are the three following lines: 

 

Connection conn = DriverManager.getConnection(sDbUrl); stmt = conn.createStatement(); rs = stmt.executeQuery(SQL_Query); Once the SolarFlare Java application has retrieved the data from solarems.net and

inserted it into the SQLite database, it will sleep for fifteen minutes before requesting a new set

of data. In order to display these data, the system makes use of a PHP Site hosted on the ROCK

17 

server at FGCU. In an attempt to display the data in a meaningful format, the site makes use of

Javascript libraries JQuery and Highcharts. To request the data, the Server Site uses PHP PDO

objects to make connections to the SQLite database. 

 

$dbh = new PDO("sqlite:SolarFlareDB.sqlite"); $query = 'SELECT * FROM "Values" LIMIT (SELECT "id" FROM "Values" WHERE "utc_timestamp" = "'.$utc.'" ) - 1, "'.$attribute2.'" '; $result = $dbh->query($query);

The PDO object is created, which establishes a connection to the database. A SQLite

query is created and passed to the object. The object contains a method to query its contents,

which returns an array of rows which are arrays of the data said rows contain. To use the queried

rows of information, they are first formatted in the form of Highstock dates, which can then be

placed within a string that resembles an array. This array is then passed as a string to the chart

which renders out to the specified element in the page.

new Highcharts.StockChart({ title : { text : '<?php echo $attribute1; ?> vs Time' }, chart : { renderTo : '<?php echo $attribute1; ?>' }, series : [{ data : [<?php echo getData($attribute1, $time4, $utc); ?>] }] }); The combination of all of these elements forms the entire software and each plays an

integral part in allowing a client to view data stored on solarems.net in a more meaningful

and available way.

1.5.2 Testing

1.5.2.1 Test Cases

In respect to the requirements documented in section 1.3, this section describes the

minimum amount of seven test cases in order to test the reliability of Solar Flare. These test

cases represent partial functionality of the numerous system required by the system to run

properly.

ID 1 Title Start and End SolarFlareRelated Requirement 2.2.1.1 Instructions 1. Launch the application using the .jar file

18 

2. Attempt to close the application by using the system tray interface. 3. Confirm closure of application when prompted

Expected Result A startup prompt will print “DataBase will be updated every 15 minutes” An exit prompt will ask if the admin if they truly wish to close the application. When prompt is confirmed, the application closes.

ID 2 Title Data AcquisitionRelated Requirement 2.2.1.2, 2.2.1.3, 2.2.1.4Instructions Wait 15 minutes after starting the application for data to be requested.

Inspect data table through SQLite manager or through Server Site to check if the row has been uploaded.

Expected Result If the data acquisition failed for whatever reason, the application creates an alert with the respective error code. If the data acquisition succeeds, the data for the most recent 15 minute interval is displayed. 

ID 3 Title Recent Record UploadRelated Requirement 2.2.1.5 Instructions Using the system tray interface, right click the SolarFlare icon and

press “View Report.”Expected Result An alert is created displaying the timestamp of the most recent report created. ID 4 Title Site Request Related Requirement 2.2.2.1 Instructions Browse to solar.fgcu.edu with a browser of choice. Expected Result The site shall be returned and presented with the homepage of solar.fgcu.edu ID 5 Title Data Display Related Requirement 2.2.2.2, 2.2.2.4Instructions Browse to solar.fgcu.edu/Environmental.php

Scroll through the site to view Javascript Highchart labeled “Ambient Temperature vs. Time”

Hover over line in chart to view specific data point.Expected Result The chart is displayed with a blue line ID 6 Title Form Submit Related Requirement 2.2.2.3 Instructions 1. Browse to solar.fgcu.edu/Environmental.php

2. Navigate to form with header “Start date for Graphical Displays” 3. Insert “4” for Day, “12” for month, and “2011” for year. 4. Press Submit

Expected Result The charts displayed below the form should have the first data point presented

19 

on the fourth of December, 2011. ID 7 Title Form Data Input FormatRelated Requirement 2.2.2.6 Instructions 1. Browse to solar.fgcu.edu/Environmental.php

2. Navigate to form with header “State date for Graphical Displays” 3. Insert “1” for Day, “4” for month, “2010” for year, and “18:45,” and

“20” for records. 4. Press Submit 5. Confirm charts are set for 4/1/2010 at 18:45, with five hours of records

shown. 6. Attempt to submit “-4” for Day 7. Press submit

Expected Result Upon inserting all correct formatted inputs, the charts are formatted as specified. Upon submitting an invalid input, an error message appears. 

1.5.2.2 Test Results

Following the test cases as described in the previous section at time of project

completion, the results are as followed.

1. Start and End Solar Flare

Success: Starting the application prompts that the database shall be updated every 15

minutes. Closing the application requests confirmation. Upon confirmation, process is

terminated.

2. Data Acquisition

Success: After starting the application and waiting at least 15 minutes, the result

closest to current time is populated on the server site's graph.

3. Recent Record Upload

Success: Using the system tray interface, pressing “View Report” creates an alert

documenting the last upload was on 11/30/2014 at 14:30

4. Site Request

Success: Browing to solar.fgcu.edu returns the homepage of the solar site.

5. Data Display

Success: Upon browsing to solar.fgcu.edu/Environmental.php and

viewing the specified chart, a line chart was generated and displaying data received.

20 

6. Form Submit

Success: By inputting 4 for day, 12 for month, and 2011 for year, the form was

submitted.

7. Form Data Input Format

Success: By inputting the correct data inputs, the charts were properly starting at the

specified time. When inputting a negative value for day, an error message occurred

requesting a valid input.

Unfortunately, the most important test of this project is to ensure the reliability over a

long period of time. Due to the nature of the software, it is not reasonable to expect a test case to

run for an indefinite amount of time. Measures were taken to ensure reliability, and a fail-safe in

case an error does occur.

21 

2. Maintenance Instructions

2.1 Developer's Instructions

The project is divided into two halves, the SolareFlare application, and its Server Site,

coded in Java and HTML/PHP respectively. To access its source files and the existing

production system, the developer must have access to the FGCU ROCK server located in lab

423. Once access is granted to the server, the developer must remote in to access the project in

the following directory:

C:\inetpub\wwwroot\fgcusolar\

2.1.1 SolarFlare

The SolarFlare application was designed in the Eclipse IDE using Java. It is found in the

root directory under the under SolarFlare.jar and is a compilation of the source code. This

code is found in the aptly named found in the project root directory. To edit the functionality of

the Java application is as simple as editing the existing source code and compiling a new

runnable JAR to replace the existing one. Any edits to the application should be preceded with a

back-up of its current state and any iterations the developer creates.

2.1.2 Server Site

The Server Site is located in the root directory and was not developed in any IDE, but the

implementation of one is possible. The site is created using PHP and is segregated into content

and reusable portions of the site. The files that the client regularly views and accesses are

index.php, environmental.php, power.php, equipment.php, and

project.php. These pages, in conjuction to files found in the /include/ folder work

together to provide content.

Reusable objects such as the data generation, navigation, and image carousel are located

in the include directory and are accessed by the main pages. Any section of code that is used

more than once or is otherwise replaceable such as the main page is segregated to provide a clean

working environment.

A backup is provided in the case of any catastrophic event which damages the

functionality of the Server Site. To edit or expand the functionality of the site is to edit the

existing PHP files, which should be tested and validated in a test environment before

deployment.

22 

2.2 Usage Instructions

The following is a step-by-step guide on how to proceed to operate the SolarFlare system.

The instructions are broken into two parts:

SolarFlare Java application operation

SolarFlare Server Site operation

The Java application is located and operated on the server itself, and requires a user with

a level of privilege that includes the ROCK server access. Without this access, only the Server

Site located at solar.fgcu.edu is accessible.

2.1 SolarFlare Application

Launch instructions

1. Log in to any computer connected to the school network.

2. Remote connect to the ROCK server using the IP “63.88.163.32” using the user

administrator. Ask the instructor for the password.

3. Navigate to C:\inetpub\wwwroot\fgcusolar

4. Execute SolarFlare.jar

Errors and Update record

Figure 9. SolarFlare Application

5. In the notification bar of the taskbar, find the SolarFlare icon, an orange square, Figure 9.

6. Right click this icon and select either “Last Update” or “Error Log”

Last Update: A dialog will appear display when the last update was done.

23 

Error Log: A dialog will appear and display the last fifteen errors occurred.

Errors do not necessarily mean a system failure. The error log exists to document recent

errors, typically in respect to response codes from the data-holding site in such a way that will

not halt the ongoing update process. Critical errors will display a prompt that is not documented

in the error log, as any critical error is considered fatal to the execution of the system.

Exit Application

6. In the notification area, in the menu acquired by right clicking the SolarFlare icon, select

“Shut down”

7. Approve the dialog that appears to confirm the shutdown of the application and cease

updates. 

 

2.2 Solar Server Site

Figure 10. Solar Server Site

General Use

1. Using any computer with an internet connection, launch a browser of your choice.

24 

2. Navigate to the site solar.fgcu.edu

3. Using the navigation bar located at the top of the site, traverse the site for desired pages.

For the home page: Home

For data hover over Graph Variables:

o Environmental for Environmental data (Temperature and Wind)

o Equipment for Equipment data (Equipment Temperature and Irradiance)

o Power for Power data (Energy and Current Phase)

For related news, hover over News and select a link

For related information, hover over About and select a link

For project information, hover over Project,

o Solar.fgcu.edu for the site’s project information

o Experimental Plant for an additional project related to the Solar fields.

For administrators, hover over Solar EMS to view where data is hosted.

Data Graph Use

1. On any of the data pages as instructed above, scroll to view data default set to one month

span.

2. Data View

Use buttons at top left of graph, edges of scrubber at bottom, or date range at top right

of graph to scale the size of data shown.

Use the scrubber or scroll bar at the bottom to navigate through the span of data.

Figure 11. Data Query Form

25 

3. Data Query

1. Find the data form “Start Date For Graphical Display” (Figure 11)

2. Following the guide lines as located on the page and below to complete the form.

o Time must be entered in the format of #:## for before 10:00AM and ##:## for all

times after 9:59AM. 24 hour format for PM. 15 minute increments.

o Day must be valid for the specific month.

o Month must be 1-12

o Year must be a valid four-digit number ranging from 2009 to present year.

o NOTE: First data point on record is on 4/1/2010 18:45

3. Submit form.

26 

3. Troubleshooting

Solar Flare Application

With the current state of the data source for SolarFlare, the application has ceased

functioning.

Solar Server Site

Q: The site is inaccessible

A: Ensure the ROCK server is running. Otherwise contact site administrator.

Q: Site is not displaying data

A: Ensure form query was inserted correctly. Otherwise contact site administrator.

Q: Filter form creates a fatal error.

A: Contact site administrator, this is a development fault.

Q: The site is not displayed properly

A: Make sure to use an updated browser.

27 

4. References

[1] F. Velosa, V. Giannone. Solar Flare: Solar Plant Data Acquisition & Visualization, Florida

Gulf Coast University, Ft Myers, FL, December 5, 2013.

URL: http://itech.fgcu.edu/faculty/zalewski/CNT4104/projects/SolarPlantFinalDraft.pdf

[2] T. Talov, Solar Cloud – Rapid Data Logging from a Solar Power Plant, Florida Gulf Coast

University, Ft Myers, FL, July 25, 2013

URL: http://itech.fgcu.edu/faculty/zalewski/projects/files/TalovSolarCloudFinalText.pdf

[3] T. Talov, C. Paulino, daVinci: Solarems Data Extraction, Florida Gulf Coast University, Ft

Myers, FL, November 29, 2012

URL: http://itech.fgcu.edu/faculty/zalewski/projects/files/TalovSolarProjectFinalDraft.pdf

[4] C. Steiner, daVinci: eBox 4864 – Sentalis Fetch CSV Server, Florida Gulf Coast University,

Ft Myers, FL, April 30, 2011

URL: http://itech.fgcu.edu/faculty/zalewski/projects/files/SolarPlantConnection.pdf

[5] Draker Labs, Solar Energy Management System. Austin, Texas. URL: https://solarems.net