openenergydashboard / oed Goto Github PK

We have enough actions types now that we need to make a conscious effort to make their names distinctive. The type definitions are also creating large blocks of boilerplate at the tops of files.
Factoring out the action type definitions into a dedicated file should help with both of these issues.

Some of the sql queries for retrieving meters didn't get the extra columns added when we added more fields to the meters table. As a consequence, some meters have undefined type and status after they are returned from the database.

Actual meter names may have been changed since the beginning of the logs, need to find any that have. Also, need to match logs to their meter they're from and identify which aren't from a current meter name. Also also, we're not posting the shareable link to the data publicly, so I have that for you if you're working on this.

• Choose a license
• Make the site look nice
  description, contacts, and so on.
• Get people to use feature system
  teach them how
• Decide how to safely store DB passwords

Set up a demo to show collaborators and establish a front end framework to use going forward.

The admin panel should allow admins to import new meters, create/edit/view groups, and any other administrative duties.

There has already been some work done on this, located in the "adminPanel" branch.

Under "Licensing" the readme states that the project is licensed under the GPL v3. We should change this immediately.

Before going open source we need to clean up the repo so that Beloit specific things aren't cluttering the repo.

Create a UI to add, remove, and edit groups.

Winston was set up on a test branch a while back but due to the substantial changes to the code since then it should be reimplemented and added to master.

• Temperature (about every hour), degree heat/cool (per day) into DB based on location
  allow for coming from another source
• See if you can get general weather info
  sunny, cloudy, etc.

Do any users need to be able to set their data resolution explicitly? If so, do they need to be able to set a minimum resolution (e.g. at least 1 point per given time period) or an exact resolution? How would that work?

Our testing doesn't have E2E tests working yet, getting Protractor up will let us write these tests.

meterCron.js is a leftover from early testing. We should duplicate the functionality in a way that makes more sense in the long term.

Interpret the data in terms of cost.

Add some dummy data to see if our system will be able to serve up charts as quickly in the future.

This issue has been seen on one personal computer and on the OED server.
The problem is requests to the API returning the source of index.html instead of the requested data, causing an error in the frontend when data.map is not a function.
The cause appears to be some thing to do with the Express routing setup in src/server/app.js. In line 32 of app.js, we have:

app.get('*', (req, res) => {
	res.sendFile(path.resolve(__dirname, '..', 'client', 'index.html'));
});

This block is intended to forward routing except API requests to react-router on the client. The issue is that requests that should be sent either to an API or to an error handler are instead being handled by this logic and getting index.html. The APIs with which we've had this problem have been registered with the API middleware above this block in app.js.

Changing the * to a / so that the code reads:

app.get('/', (req, res) => {
	res.sendFile(path.resolve(__dirname, '..', 'client', 'index.html'));
});

appears to fix the problem, but the strange thing is that changing it back to a * does NOT cause the issue to reappear.

If you run into this issue pay attention to what's going on and reply to this issue with relevant details.

Find and detect gaps in data.

We need first-class responsive mobile support, including placing the options for manipulating the graphs in a way that works on mobile. This is going to require some discussion about what we want the site to look like on a phone.

We need to display properly on multiple types of screens.

Parallel to #57. Allow graphing between groups (each group is represented in aggregate) or within groups (each meter in a single group is represented individually).

Design questions:

• How should the UI look?
• How should nested groups work? (graph subgroups or graph meters? Optional? Default?)

Initially, focus should be on comparing groups with each other.

The Readme file has a link to a CLA in the contributions section. Clicking on that link produces the following error message: You need permission

This form can only be viewed by users in the owner's organization.

Try contacting the owner of the form if you think this is a mistake. Learn More.

Set up an API so that frontend has something to work with.

Discover why the crash happened and try to make the program more resilient.

We should figure out how to support https, esp. as we develop login/admin

Design problems:

• How do we generate baselines?
• How do we store them?
• Can they ever change retroactively (can yesterdays baselines change today?)
• Integrate into graphing (at a later date)?

Add legacy MAMAC readings to db

Standardize tools and workflow

Currently when the user changes which meters are selected, we fetch readings for both line and bar charts. This will be efficient if users switch between line and bar chart for the same meters more frequently than they switch between meters within a graph type. I do not think this will be the case. Until there is some reason to believe otherwise, I think a single user action should dispatch as few API requests as possible. This was briefly discussed in re #85, and I think we came to the wrong conclusion.

We need to be able to compare and normalize readings in order to support things like competitions between buildings or to compare energy usage from different periods in time.

We currently read them by the hour but our system should be able to handle the extra data.

We're currently sending every data point to the server, which is crashing the browser after about 2000 points. We need to condense the points before we send them.

The current system works but as we make progress on the project changes should be made and incorporated.

• Link new DB to Tableau

Implement a way to inform the user when things happen.

Create back-end testing with Mocha and Chai.

• Export data to spreadsheets

I was thinking that maybe we should change the repository name. First, JS is probably not needed and is not the only technologies used. Second, ED is not as descriptive so should we spell it out? An alternative is to add topics so it is easier to find. I think we should do this before it goes public.

Much of the code needs to be documented to allow for ease of understanding.

Create a nice way to import new meter data.

• Create ER diagram of DB
• Implement DB on server
  Tell MAMAC meter data and archive data groups when done.

Extend #22 (PR #83) by allowing users to export all available data.

Implement Grouping

Look into adding internationalization support to the software.

2. Read in Metasys data from Beloit College

Figure out how to back up our postgres db.

Getting Tableau working with the database may have left some potential security holes on our server. Fix them.

need to get admin tool working so can set up for others. Once done notify DB team to set up tables.