fgcu solar connectivity nicholas...
TRANSCRIPT
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