Professional Documents
Culture Documents
Capstone Report - Oed
Capstone Report - Oed
_____________________________________________
Authors:
______________________________________________
Summer B 2022
______________________________________________
Executive Summary
for monitoring various types of metering devices. The Open Energy Dashboard (OED) provides
a tool for users of any skill level to access and display current and historical data from their
metering system or related equipment. A primary goal of the project is to produce a dashboard
that is simple to use, reduces implementation complexities, and lowers the overall cost of
operating and maintaining a metering system. OED aims to accomplish its goals by
implementing a simple and intuitive dashboard that interfaces effortlessly with equipment and is
easily configurable, yet remains portable and implementable across many organizations. OED
was designed with reliable open-source software that is constantly maintained, ensuring the
dashboard will have a long life and be competitive with the latest technologies.
We live in a time where reducing energy usage, no matter the amount, is more important
than ever. Having an easy and cost-free way to monitor energy usage data encourages more
efforts or businesses looking to raise their bottom line by cutting costs, the end result is a lower
carbon footprint. While it is likely that organizations with large utility costs will comprise the
majority of interest in this project, anyone can take advantage of the project’s functionality.
OED, with its low cost and easy implementation, has the potential to benefit not only large
swaths of society, but the planet as a whole. Being more aware of one’s energy usage allows
Table of Contents
Page
Introduction......................................................................................................................................4
Product Description.............................................................................................................4
End Users.............................................................................................................................4
Feasibility Discussion......................................................................................................................5
Ethical Concerns..................................................................................................................5
Legal Concerns....................................................................................................................6
Platform...........................................................................................................................................8
Major Functions..............................................................................................................................8
Units....................................................................................................................................9
Usability Testing/Evaluation..........................................................................................................12
Timeline/Budget….........................................................................................................................13
Final Implementation.....................................................................................................................16
Discussion......................................................................................................................................18
References......................................................................................................................................21
Appendix A....................................................................................................................................22
Appendix B....................................................................................................................................28
Appendix C....................................................................................................................................31
4
Part I
Introduction
I. Product Description
Open Energy Dashboard (OED) is a web-based application that allows users to create,
link, and monitor their energy consumption. Currently, those who wish to use such a system have
to pay a company that then creates an application for them—such as Wattics, Datapine, and
Automated Logic. While this approach gives the consumer what they want, affordability, ease of
access, and modifiability are sacrificed to achieve this. OED aims to resolve these issues.
As utility costs rise and become more of a financial burden on businesses and
communities, access to information about how we use our resources becomes increasingly
important to consumers. The ability to understand, visualize, and evaluate how and when we use
resources is crucial. Monitoring resource usage is important not only for saving money, but for
preserving the limited resources we have available. With OED, any organization that monitors
energy usage can have a reliable means of displaying and manipulating this data in order to cut
down on cost and optimize resource utilization. Crucially, OED will be available in multiple
languages and metric systems, greatly increasing its reach to organizations and communities
around the world, rather than limiting its use to English-speaking regions. Open Energy
Dashboard is an open-source project that will continue to evolve as more contributors join the
cause.
OED is an application that can be used by anyone who wants to monitor their energy
consumption. This is achieved by having each user connect to the application through a web
5
browser. This makes any device capable of connecting to the internet a valuable tool for
consumers. Furthermore, this application provides numerous metrics for monitoring various
Feasibility Discussion
Although OED is the first of its kind to be free to use, it is not the first energy monitoring
dashboard. There are several companies offering paid services and products that allow their users
to monitor their energy usage. These companies may perform better at certain tasks than OED.
One such task is tailoring the application to customers’ needs and standards. However, while
these companies excel in one area, they lack in others—for example, their status as paid
applications and subscriptions rather than a free resource. Our project aims to outperform paid
resources through addressing the affordability, portability, and modifiability of our product.
I. Ethical Concerns
Not only are these three topics the main concern for consumers, but they are what OED
was founded on. Currently, other companies offering energy dashboards require their customers
to pay a large fee for their services. OED remedies this dilemma by being an open-source
project. This means our dashboard is free to use, offering savings to our users who would
Another issue with current paid energy dashboards is their poor performance with regards
to portability. Typically, these companies create a downloadable application of the dashboard, for
either a custom-made system or for a desktop computer. This is problematic for those without
access to specialized systems or a desktop, as smart devices are replacing desktops as users’
6
preferred way to access the internet and applications. OED fixes this issue by being a web
browser-based application. This means the only thing a consumer needs is a device capable of
Finally, companies that provide energy dashboards rarely provide updates to the
applications they create. Everything is built to suit the needs of their customers then and there,
rather than focus on users’ changing needs and requirements. Any such updates usually require
customers to pay more for a service they’ve already purchased. This is not the case with OED.
Since it is web based and open source, updates can easily be applied to our users' dashboard
without the need for additional fees to implement those updates. OED tackles the issues with
other energy dashboards and provides consumers with a free, easy-to-use product.
As an open-source project, the OED team is minimally concerned with potential legal
issues. One precaution this project uses is the OED’s Contributor’s License Agreement (CLA),
which states that the product will remain free to use, and that contributors are not expected to be
paid, nor expected to provide support, for their work. However, if they decide to provide support,
they do so either for free or for a fee if they so choose. OED is also operating under the Mozilla
Public License 2.0, which gives it permissions for commercial, private, and patent use, as well as
boundless. There is no expected end date for this product—it plans to update accordingly to
7
there are many planned changes in the pipeline, some of which are requests from the community.
One such change is updating the energy-consumption graph to make it less linear in its display in
The Open Energy Dashboard has a bright future ahead as an application made by the
Part II
Platform
Every project has its own coding environment/platform that its developers work on, and
in some cases there could be multiple platforms. OED chose to exclusively use Visual Studio
Code (VSC).
VSC proved an optimal choice for the OED team, as it offers a variety of features that
allow it to implement multiple functions in a single platform. One important feature is the
implementation of Docker, which allows the construction of containers to run the application in a
web browser, such as Chrome or Firefox, for the purposes of testing and debugging. VSC also
features GitHub integration. By implementing this, developers are able to view all currently open
pull requests that exist within the GitHub repository and the current status and progress of those
requests. It also tracks changes between versions by highlighting lines of code that were either
changed, added, or deleted. Lastly, VSC has a built-in feature that allows developers to search
across all project files for a given string. This allows developers to quickly locate code, which
Although VSC offers additional features, those listed above have been the most beneficial
to the OED team. VSC has proven an effective platform for our work and will continue to be so
Major Functions
Because OED already existed prior to our team’s involvement in the project, we had no
hand in dictating its original design. OED has a wide array of functionality spanning many
different use cases, although its primary function is the tracking and graphing of data pertaining
9
to energy usage and converting it into a human-readable format. Our main goal as a team is to
design a template for displaying data from key database tables and to allow for create, read, and
update—though not delete—functionality on those tables. From this template, our goal is to
create two additional pages with similar design and functionality. One page is for Units,
demonstrated below. The other is for Conversions, which is still in the development stage and
I. Units
Main Page:
Figure 1
Units Page
Each line, including the title, represents a mutable database column that can be edited by
administrators. We have strived to use modal elements as a tool for ease-of-use in our page
10
design. Here, they are used to clearly separate database rows and are also used as pop-ups for the
Figure 2
Unit Create/Edit Modals:
Note: These are the modals we created to edit and create units on the units page.
Our goal was to create and utilize consistent design and functionality of the pop-up
modals. Modals are treated as pop-ups so as to make them stand out so it is clear to the user what
All database data lives in the Redux store as a cache that wraps the entire application.
Each page subscribes to the piece of the store that it wishes to track. In this example we are
11
tracking the Units data state. Successful updates to units, or creation of new ones, will
immediately update the store and trigger a re-render, yielding a dynamic, yet quick, web page.
We ensure this store remains consistent with our database data and that it is properly updated on
successful backend calls so what the user sees is an accurate representation of the database.
Open Energy Dashboard is in a unique position when it comes to testing the usability of
the service. Being open source means that any contributor, with access to GitHub, is able to help
test the product. As a result, there is no need for focus groups or test subjects in this matter. The
features we are working on will be tested primarily within our group. The company lead and
other individuals will also perform tests as well, once changes are committed to the appropriate
GitHub branch.
Our testing process will primarily consist of developers using the product as is. This
process will have them implement and test changes manually. This approach helps with
identifying and fixing most of the smaller issues that appear after large changes are made to the
code. This typically happens when a merge occurs from the development branch to the live
service branch.
Another testing method, which is more standardized, is the use of test data. This is
implemented by having developers run scripts through the command line. These scripts are
located within a “package.json” file and cover various areas within the application. For example,
there are scripts which inject unit conversion and special meter data into the testing environment
for the application. This allows for quick and easy automated testing and ensures that every new
Usability Testing/Evaluation
OED is unique in that all testing is done through the developer’s coding environment
instead of with focus groups or application users—although all user feedback is recorded for
future development and testing. The process of evaluating and testing the application is a
straightforward procedure.
First, a developer will need to have their coding environment set up appropriately. This is
done by cloning the repository to be tested and ensuring that the correct branch is active. All of
this is done through VSC, with the use of additional extensions for remote development, Docker,
and GitHub.
Second, the testing data will need to be loaded. With the help of the Docker extension,
this step is simple. All one needs to do is attach a shell to the appropriate container and it will
then open up a command line terminal. From there, a developer is able to populate the
application with test data. This process can be done either manually or automatically. To do this,
one simply needs to pick a test script from the “package.json” file and enter in the command line
Once the testing data has been inserted, the only remaining step is to run the application.
In order to do that, a developer needs to open up a browser of their choosing. Next, they will
enter “localhost:3000” into the URL. This will open up the application on its home page, with
the test data populating the dashboard. Once this has been done, the tester is able to test and
Part III
Timeline/Budget
Timeline
timeline that we could follow to reach them. Major milestones included reviewing the code in
OED, setting up our coding environment, documenting code, and key development tasks.
However, we utilized many smaller milestones to help break up the larger ones. We managed to
accomplish an overwhelming majority of these milestones, but due to some unforeseen setbacks
Our first major accomplishment was updating and finalizing the units page in OED,
which had not been completed by the previous team. This consisted of updating the use of React
and Redux to the newer usage, fixing an array of leftover bugs, adding missing functionality,
cleaning up the visuals, and streamlining existing code. The completion of the units page fell
outside our initial timeline estimate, but proved itself to be a useful template that greatly
expedited the development of the conversion and meters pages. Furthermore, it allowed us to
complete the optional milestone of updating the select dropdown menus and adding a new one
The next major milestone was the refactoring/rebuilding of the meters page.
Unfortunately the meters page was not completed and is still in production. There were many
unforeseen issues with communication between the frontend and the database, as well as new
additional functionalities requested by our client as we continued to develop the page. Also, the
page’s development started later than desired, which played a part in its lack of completion.
Much time was lost due to various bugs and errors when implementing key features into the
14
Our last major milestone was the refactoring/rebuilding of the conversion page. Although
development of the conversions page, like the meters page, started later than planned, its
development progressed faster and more smoothly than the meters page and was completed in
time. Not only were we able to complete the originally requested page, but our team managed to
ship both the originally requested page and the additional features requested by the client during
development.
As discussed earlier, we were unable to complete every milestone our team laid out.
These consisted largely of smaller items such as documentation and code reviews. In addition,
we were unable to complete work on the meters page due to the development process getting
slowed by bugs. Although these milestones do not impact the features provided by OED, they
Overall, the majority of milestones, including those added during the work on the project,
were successfully completed. The units page and dropdown select changes were merged into the
resource generalization branch, which will remain in development until the resource
generalization issues are complete, and the conversions page is currently situated in a pull
request ready to merge into the resource generalization branch pending review. The remaining
small changes required to push the meters page are planned to be completed by our successors.
Our contributions to the project will be merged into the development, and eventually main,
branch. The project is still on track for a 1.0 release in the second half of 2022.
15
Figure 3
Expected Timeline/Milestone:
Note: This was our expected timeline, but due to certain circumstances, we were unable
to achieve all of it.
Budget
This project had no budget, it’s a free and open source software which is maintained by
volunteers and students who take no compensation for the work. The code is hosted for free on
GitHub; end users can install the software on their own computer so the project doesn’t need to
be deployed and hosted anywhere. We did not run into any budget issues since all the technology
16
Final Implementation
After two months of working on OED, the final product’s looks and functions have been
significantly improved from the original code. The units, meters, and conversions pages now use
modals, which are edited individually, rather than the original grid format that had to
efficiency. Units and meters can now be edited, and new ones added. Conversions can be added,
edited, and also deleted. Whenever changes are made, the page reflects these changes without
requiring a refresh. These features are the result of proper communication between our Postgres
React allowed us to create functional components that managed their own state in order
to implement more complex user interfaces. State is an important concept in React and routing
and managing state can get very complicated as the size of the application scales upwards. Redux
helped us handle these complexities by allowing the entire state of the application to exist in a
centralized place that wraps the application itself. This made accessing and altering any state
from any component simple, the code more legible, and sped up the development process.
17
Figure 4
Redux example:
Note: Example of Redux reducer and actions for our unit component.
With units and meters completed, we were then able to work on the graphing element on
the home page. There are dropdown menus to select different items which impact the graph:
Graph Type, Groups, Meters, Units, and Rate. The graph type is simple, the user selects the type
of graph they want, such as a line or bar graph. Meters and groups cannot be graphed without a
unit so meters and groups have a default unit associated with them that auto populates the unit
dropdown when selected. However, they are free to select another unit in the dropdown if
desired, so long as that unit is compatible. As an example, it is possible to graph how much
money (a unit) they are spending on electricity (a meter) over a period of time. The rate
dropdown allows users to measure this by seconds, hours, days, etc. Groups can be created in the
18
groups page. An example group could be one that combines the electricity and natural gas
meters. Back on the home page, a user can select this group and simultaneously graph how much
Discussion
Throughout the two months of project development, our team encountered numerous
issues. The first major challenge was learning and implementing a React/Redux framework,
which our client wanted to use for OED. Our team implemented Redux with hooks in various
parts of the application—such as units, meters, and conversions—while refactoring its UI. The
client described this as a major change to OED that would consist of many changes to the
development branch of OED’s repository. Our team was able to deliver the majority of the
Two related challenges that persisted throughout the development process were the
longevity of the original code and the amount of non-functioning or incomplete code left within
the previous team’s branches of OED repositories. At the beginning of our team’s involvement, a
majority of our time was devoted to understanding how OED worked, which was made difficult
by earlier teams’ incomplete and bug-filled code. For some of our team, the original code
hindered their ability to consistently set up the development environment. While we resolved a
portion of the development environment issues, constant adjustments had to be made due to
hard-to-find bugs and general inefficiency when testing changes. These challenges became
increasingly obvious when our team tried to collaborate and coordinate changes using tools like
Git.
CSUMB capstone team. Overcoming those challenges was possible due to each team member's
ability to coordinate, communicate, adapt to changing environments, and respecting each other's
While our team completed the majority of the client’s goals, the overall application is not
yet ready for end users. However, the client was pleased with our progress and the Open Energy
Dashboard 1.0 is scheduled to be released by the end of 2022, on target for the client’s
expectations.
Throughout the project, our team gained valuable experience and insights into the
development of a web application. Our understanding was helped by working from previous
code, rather than creating the app from the ground up, and also through the efforts and assistance
of our client. Each team member was assigned several tasks and performed many duties
throughout the project. This allowed each of us to experience different aspects of app
development, which was far more beneficial than if we had been assigned static roles from
beginning to end. We are all proud of the work we accomplished and look forward to OED’s
When OED is released sometime this year, we foresee it having major benefits to society,
especially as more users join over time. While we do not expect overnight success or even
necessarily a fast uptake, the ability of users to view their energy usage using a menagerie of
measurements, time-scales, and conversions will allow them to gain more awareness of their
energy footprint. In doing so, OED hopes its users will decide to take steps to decrease their
consumption.
OED will always be free to use, which will likely increase its user base, and thus its
societal impact. That it is also a browser application will make it more accessible, especially for
20
those with less technological access. Ultimately, OED will not only help users save money, but
Our team is proud to have done our part helping others—and the planet.
21
References
https://www.wattics.com/dashboard/
https://www.datapine.com/dashboard-examples-and-templates/energy
https://www.automatedlogic.com/en/products/energy-reports-platform/energy-dashboards
Morgan, J. (2020, October 20). How To Manage State in React with Redux. DigitalOcean.
https://www.digitalocean.com/community/tutorials/how-to-manage-state-in-react-with-re
dux
Appendix A
Introduction:
1. What is your target audience? (age, occupation, interests, comfort level with
technology, etc.)
a. The targeted audience for those using Open Energy Dashboard (OED) are those
who have a familiarity with the tools of the trade. For example, understanding
the application and user interface is made for easy usage, allowing for non-highly
2. Who will be testing your project? If you have a focus group, please state
everyone's names (first names okay) and describe how they fit your target
a. The pilot for testing the application will be our client, whom we have worked
3. What are the main tasks you would like your client/group to be able to complete
while testing? Your tasks should be specific and measurable (i.e. Can they sign
up and log in? Can they navigate to one specific part of the site? Are they able to
play through the first level of the game?). To get good feedback, you should have
i. The user is able to create a new unit and have the page automatically
ii. The user is able to update an existing unit and have the page automatically
iii. The user is able to graph a group or meter without selecting a unit (the
iv. The user is able to see incompatible dropdown items properly get disabled
vi. The user can switch between units when graphing without deselecting the
unit, provided the unit being switched to is compatible with the currently
selected graphs/meters.
4. Observe and take notes while your tester tries out your product. Testing is best
done face-to-face. It also helps if your testers speak out loud so you can hear
their thought process as they attempt your tasks. That way, if they get stuck or
aren't able to complete a task, you have an idea of why and it will be easier for
you to fix.
i. The client was able to successfully create a new unit and the page
1. Side note: All input fields worked correctly along with those that
ii. The client was able to successfully edit an existing unit card and all of the
1. Side note: If the name of the unit card was changed, the page
well.
1. Side note: Previously, this feature did not exist and the user had to
manually input the unit, which the meter and group needed to be
based on.
iv. When viewing either group, meter, or unit, the client is able to
1. Side note: All valid inputs appear as normal black text entries that
can be selected. On the other hand, invalid inputs are grayed out
v. Based on what type of user is logged in, either normal or admin, they are
able to view group, meter, and unit items that are available to them.
1. Side note: The admin is able to view exclusive group, meter, and
vi. The client is able to successfully switch between other valid unit types
based on the meter or group that has been selected. The graph is also
25
1. Side note: The client is also able to reset the group, meter, unit, and
1. Set up a meeting with your client to go over your work. This should ideally be
face-to-face so you can get their initial reactions and see how they navigate your
product in real time. If they test on your device, you may also be able to record
your screen and audio to capture their test to review later (with their
permission). Other good alternatives would be to have them share their screens
over Hangouts, Zoom, etc. while testing or have them record themselves using
a. The testing will be held over a Zoom call on Sunday, July 24th, 2022. Our client
2. Share your tasks with the client. Encourage them to share their thought process
aloud so you have an idea of how your project will be used. If they get stuck,
resist the urge to give them help or hints. Encourage them to find the solution
on their own, and if they can't, remind them that your project is still a work in
progress, it's not their fault that they are not able to complete the task, and then
a. Prior to the meeting day for testing, we sent a message to our client detailing our
situation, along with the list of our test cases. This was to help familiarize
themselves with what is to happen on the day of the meeting. Also, by sending
26
that message we have received feedback about certain test cases and have altered
them as a result. This made the testing process easier for the client.
3. Report on their feedback. Were they able to complete all of the tasks? Did they
get stuck along the way? What will you do to improve your project in the short
a. Based on the feedback from our client, every test case ran successfully.
i. There were certain areas in the project that the client got stuck on for a
brief moment.
1. The first instance was when the client resized the unit page
containing all of the unit cards. Some of the unit cards weren’t
2. The second instance was when the client was trying to find specific
entries either within the meter or group section of the graph. This
was just a matter of navigation rather than an error with the code.
ii. Unfortunately, for the issues that the client came across, they don’t fall
within our jurisdiction as a team. However, this will not stop us from
improving other smaller issues within our sections of the code. Some of
iii. As for the long term, there isn’t much to improve upon. One improvement
would be ensuring all pages like Unit, Meter, and Conversion all follow
Github.
28
Appendix B
Many tasks in this project were assigned to teams of two to three team members. These
teams changed throughout the project as progress was made in certain areas. Some portions of
the project were worked on by all members, while other, smaller tasks were assigned to an
individual who could implement a solution quickly. This non-concrete division of labor allowed
the allocation of resources to remain flexible, as the team could reconfigure in order to give more
Major functionality was broken up into several groups: Units, Meters, and Conversions.
Once smaller tasks throughout the project had been completed to the client’s satisfaction, teams
Fernando Arozqueta: Performed minor change to the “sec in rate” input field in create
unit page. Performed code reviews and project testing. Assisted with the preparation of
Andrew Bundy: Team lead for Conversions page. Added and implemented most
general troubleshooting, code review, QA, project testing, and bug hunting/fixing.
units page. Bug fixing, update, feature addition of select dropdowns. Adding of rates
menu for graphing. Bug fixing, feature addition, finalization of conversions page. Bug
fixing, feature addition of meters page. Refactoring and bug fixing of various key parts of
Austin Stewart: Reviewed and tested code to find bugs. Added pop-up help text for
creating and editing units within the unit page. Coordinated with the capstone advisor and
company lead to organize our group along with upcoming capstone tasks. Kept the team
on track and up to date with various capstone assignments. Worked with the client to help
improve the installation process of the coding environment for Windows users.
Katherine Vickstrom: Edited unit components to reduce the redundant code by creating
functions to handle certain types (eg. string, boolean, integer) instead of a function for
each input field. Implemented the meters pages incorporating the same changes from unit
components in meter components, which had an extra layer of difficulty to deal with GPS
and time zone types, as well as other special circumstances. Created the route to add a
meter for the meter API. Added translations for messages to properly translate on the
Thomas Wooten:
1. The modal pages have the items only span a limited amount of the width of the
3. The edit page does not have a resizable note as is done on the create page
4. The preferred display is true/false on the overview card but yes/no on the
create/edit modal. I think we should just use true/false since this is an admin page.
5. One of the other new modal pages (conversion?) color codes the true/false with
Created pull request for meter modal work, Implemented the meters pages incorporating the
same changes from unit components in meter components, which had an extra layer of difficulty
to deal with—GPS and time zone types, as well as other special circumstances. Reviewed and
Appendix C