The Sims: Dorm Energy

Before entering the hibernation mode that was spring break, we set forth a few goals for our new group. Split up into two groups, one working on the sensors (Edwin, Alan) and the other with getting some numbers that could mimic the energy usage patterns of the typical dorm students.

Two things I had though about for this energy. How much energy can a floor use, we need numbers that are close to what we would typically see in our real readings. So my first task was to take a look at some floor plans and make an educated guess...estimate on the max and minimum consumption of energy for a typical floor. The second thing was to look at the typical patterns of a college student.

The first step was simple enough I believe. With some help from a few assistants I found somewhere in my office, I was able to get an accurate floor plan. In conjunction I found floor plans of each dorm and mapped out typical items found in one room.

Not sure which dorm we are going to be installing the sensors in, I'll have to have one of my group members clarify, but for now we'll use this as a bases, The Hale Aloha towers. Though I have accurate floor plans for every dorm.

Never actually dorming myself, I had to look to others around me to assist. Lucky I had plenty of people who've had experiences in this area. One graduate student, a friend, has been in all of these dorms over the course of her experience here at Manoa, so I believe she is well equipped to explain the experiences of a college student. A typical room has a a fridge, extra lamps for lighting other than the one ~ three built in lights provided. Many students also brought in surge protectors to expand the measly 2x2 outlets(2 outlets on each side of the room) they were given. Then there are the quad rooms, but thats another story.

I took on interviewing a few people already in hopes that I might better understand how a college dorming student lives so I can understand and predict when energy usage would be at its highs and lows. One interesting thing that I discussed with a few students is the question of weekend energy usage, because I don't dorm my energy usage usually spikes during the weekend, but this is probably because I stay in much of the time. I generalized that the same thing would happen during the weekends at the dorms, but I was quickly put in place by the more experienced dormers. They had explained to me that many students that live on the islands or even neighboring islands would often go home to their families on weekends (especially 3 day weekends for those in the neighboring islands). Other students were also very active opting to go out, these would offset the energy from the lack of classes and the time spent studying or completing assignments from students who would spend more time inside their dorms.

Together with these people, I've somewhat mapped out a trend that I would like to model our data after. Hopefully when we plug in a real monitor and get the apps hooked up to it, even if the watt data is off hopefully the trend lines will be spot on.

In other news, our sensors and monitors and now both working, all that is left is simulated test data to try and if first tests look good, we may be on our way to having all four types of meters working soon.

Watts For Sensors: New Beginnings

Last week we saw the conclusion of the Wattdepot-Apps group, our two month going project. This week I pick up a new group that has already begun development of their project, so I will be as they say hitting the ground running.

My new group for this next milestone will be the Dorm Energy Simulation group. Our task is to develop a simulated energy program that will send simulation data into the actual Wattdepot servers we were working with.

We haven't had much time to meet or discuss our plans which we will hopefully get together by our first meeting this week, but so far from what I've heard, our two goals right now is to get a working conversion from the data of the meters into actual data that the Wattdepot servers use. The next goal is the actual simulated data in which we are currently doing research on appliances and other items found in dorms that we can base our simulated data on. Once this research is completed we can plug in actual numbers and get this data written into wattdepot to be visualized and queried by all sorts of applications.

Not much else to report this week as I'm still getting my sea legs. This is always a problem that I believe anyone would encounter when joining an existing project. Half the members in our group were already working on this project when I had joined, they will be the more productive members until the rest of us can get it together. In the mean time I hope they continue to be supportive and take lead in the project to direct us new members until we can be a fully functional part of the team.

Wattdepot v.2: Overcoming Challenges

It is now almost four O'clock in the morning and I am still waiting in front of my computer half asleep. Trouble seems to strike at the most inconvenient time these days, but I guess anytime trouble hits it becomes an inconvenient time.

Its been a little over two hours since my internet cut out on me, disconnected from my group and unable to contribute anymore progress into the overall system. Lets recap this previous week and hopefully by the end of this textedit post the internet will be back up.

This project is finally coming to an end. We started off with 3 applications in mind, we've only seen the completion of 2. Not the best, but considering the amount of time spent in refining the other applications we've accomplished plenty in the two months we were given.

This past week we've been scrambling quite a bit, what should have been a week to do finishing touches on our public release of the Monitor application and the next version of the Visualization application met with some road blocks.

In our last weekly meeting we were given comments on a code review that Professor Johnson did… and it was a disaster. There were many comments that issues presented in the meeting that really opened our eyes to the messy code that we have presented.

The first issue was our previous wiki pages. We had slapped together wikis as a placeholder using base from our previous coding assignments. I had use my groups Developers Guide from a previous semester and I had thought all the references to to old project was removed, but Professor Johnson managed to find some. I had forgotten to remove all the links that lead back to the wrong project page.

This week we've had a complete overhaul on the wikis based on the suggestions by Robert and Professor Johnson. It should now be comprehensive and informative enough for both users and developers each on their on level.

The second issue discussed was a package we were using in our code. This semester isn't the first time we are working with Wattdepot. In a previous semester we had written a command line interface for users to quickly query some data based on preset commands. When we first started our project we had though this old code would be useful and save time, so we reused it turning it into a "Command" package. Turns out that instead of directly accessing Wattdepot with all the nice methods presented to us by Robert, we were using this faux command line on top of it and having to do all this extra work before we actually did any calls. This was very inefficient and from a outside developer's standpoint almost impossible to understand.

This week, we did a total overhaul and re-factored the code. We looked at the command methods took what we needed and scarped the rest. Now completely gone is the Command package, each application now only uses what it needs to rather than importing the entire package.

Other than the code clean up, comments, and documentation for the release, we were able to squeeze in some extra enhancements to the Monitor application.

Last week I talked about going portable, so we've added in a proof of concept parameterized link for users to send to others.

Although there are issues with it that I would like to see get fixed in the future, it is a very neat feature to have and I believe it will be useful to users.

Wattdepot Portable: Rounding 3rd!

Another week and a step closer to our second milestone. We are currently in the third week of milestone two. With one more week to go, just how close are we to completion?

This past week has seen some work from each member of the team. At last week's meeting, it has been decided that we are close to the completion of the project. The only thing left on the visualizer is a small issue with loading and column naming issues, along with testing. For the monitor page, we needed to have some error checking and do dynamic type conversions.

One great enhancement that will be useful for both applications is portability. We would like to make the urls portable by allowing users to share urls that pass parameters into the pages. Since this deals with both the monitor page is the visualizer page, as the middle man between both projects, I was assigned this task.

So far its been difficult. I do have portable urls working and the parameters being passed. Below we take a look at the new Urls being use for the applications.

Old Url: Very ugly, What the heck is "wicket:interface=:0:"?

• http://localhost:8003/wattdepotapps/home?wicket:interface=:0:MonitorPageButton::ILinkListener::

New Url: Nice url, 1.1 does represent the pageID, hoping to get rid of it in a future release.

• http://localhost:8003/wattdepotapps/monitor.1.1

Portable Url: All parameters passed using slashes in url encoding.

• http://localhost:8003/wattdepotapps/monitor/Source/SIM_AES/Type/Power%20Consumed/Interval/5%20sec

One problem I am currently running into is finding a way for the url to update without having the page refresh. Since the monitor does do a query or "monitor" in its case on load, I cannot just send all the parameters to a new page for the url and have it start. It is however possible for the visualizer which loads on start so I can apply my current code to the visualizer.

Hopefully I will run across a fix for this, or someone from the wicket mailing list will have an idea. For far no luck, but hopefully we will have a fix within the next week.

One last issue for the overall system is to have a dynamic host uri and port number arguments. This will be helpful because Robert wants to install a second Wattdepot server and using this command argument in the cli, we will be able to have both servers running. This does not seem too hard so it has been set to low priority, it is also there since we have nothing to test it with until Robert add this second server.

It has been recently decided that since we are approaching our next milestone and only two out of the three applications will be ready by then, it is a waste of resources of three people to be working on just the Browser application in the third milestone, so most likely we will be parting ways or if we share similar interests, we will be switching to new projects.

There are already a list of projects to choose from and many do look interesting, hopefully we are able to complete the two required applications we do have left to its fullest before we take our next step.