Sprint to the Finish Line

We are currently in the final week of school and the projects and finals from other classes will start to pile up making it increasingly harder to find time to work on this project. Though we are no where near completion of all four of the meters/sensors in our original goal.

Within the last two weeks the groups have split into two forces, each working on their own meter. Edwin and Alan duoing the QuadLogic sensor and meter respectively, while Anthony and I start work on just the meter portion of the Shark meter.

When we were being briefed on the design of the project, we would always hear that after the first set of meters/sensors are done it will become quite easy to complete the other three, just find the registers and then change them. I though that it would be simple enough for sure, but I was wrong about that on so many levels.

When I opened up the PDF manuel for the Shark meter, I expected to find some table index of the registers that stored the data, but soon did a realize that it was far from it. To be able to program for a meter you must fully understand how they work and what you are looking for. I spent half an hour pursing for some kind of register values until I locked onto something about using modbus to program it, yet I could not make out a single work on what I had read.

Our inexperience with these meters have really put a road block into the development. I could clearly see the difference between those who have spent hours learning how to deal with these things as Alan and Edwin have churned out an almost fully function Meter/Sensor pair within the two weeks, where as Anthony and I have basically some research on the inner workings of the meter and a lot of prewritten code by Alan.

I still remain optimistic of course and I hope to be able to finish at least our meter maybe with the help of Alan to push us in the right direction. For the four milestone we plan to have maybe three of the four meters/sensor pairs working.

Final Lap

We are on the verge of the end. With about two weeks left we head into the end of this semester long software engineering project.

I'm still working diligently to churn out a few more meter/sensor pairs for possible meters we will be using for next semester.

Last week we had a major problem with the sensors not creating the property files needed to connect to the wattdepot servers. We soon discovered that we needed a folder that was created by the code, but it was never made only checked if it existed and then anyone without the folder would be unable to run the sensors. We have now resolved this issue but it requires further testing done by all members of the group. As it has shown in the past, just because one member confirms a piece of code running, the different configurations between different computers could cause problems.

Other than this issue, the meter code is just about finalized. We have decided to continue working on new meters with current progress being made on two meters, QuadLogic and Shark. We will continue to accept the energy generated as kWhr until we can get a confirmation and decision for wattdepot, which is currently taking energy as Whr.

With the unification and regular meeting and emails from the groups at this point, we will try our best to complete as many possible meter/sensor configuration for possible meters. With the time ticking down we will be scrambling throughout the remaining week.

A Rocky Road Turned Hazardous

These recent blog posts seem to me nothing more of a rant about the problems faced during this current project. I believe it to be very much about problems face, but it can also be about how we've meet with the problems and resolved their issues. But the fact is every time resolve a problem, it just seems to lead into another problem. I truly am starting to wonder when the last of the problems will be resolved.

I was finally able to get the build system working just before the milestone last week, but to my surprise when I had run verify, I was slammed in the fact with countless errors. Not only was the code that my group members working on filled with checkstyle errors, but some of it also contained PMD and Findbug errors. With so little time left until the mile stone, we were only able to do so much, and the fact that our coding style was sloppy was made very clear.

To that we have overcome. With everyone now under one subversion folder we were able to quickly share code that was needed to fix some of the problems. The team worked very diligently to clear up over 100 checkstyle errors that had occurred, many of them occurring from code that was unneeded because it was imported from a package.

With the errors gone we were just tasked with one thing left. Running a complete build system for a new developer. It was my first time working with ant really. Although I had used ant before, I had only been using the predefined build system given to us, but for the next step to progress I would have to start modifying and building my own build files. To this I have almost succeeded. In our current project we have two sub projects that needed to be ran separately. To do so it was almost impossible to use the pre-exsisting build commons we had utilized which were wrapped up in a single project. I separated the two projects each with their two targeted build commons. We can now run the projects and build them separately under one unified project folder that will do the consistency checks for the whole.

So close yet, for every problem we fix, there is always another problem that arises. The current issue this week will be to be able to test the project. For some reason, the sensor portion of the project is only able to run under Edwin's computer. So far Alan and I have tried unsuccessfully to run both my build of the project and the old build (confirmed to be working) by Edwin, but to no success. The problem is a missing property file that should be created on start, whether or not this file is created by you or automatically by the code is another thing. I have traced the code to which I believe it is the source of the problem, but it appears that this portion of code is working under Edwin but no one else. Good that it works, but bad that no one can confirm it other than Edwin.

Chaining Together Troubles: Milestone 3

Group projects are always either a hit or a miss. It doesn't matter if the end project doesn't exactly meet specifications, the goal of a group assignment, in my opinion, is the successful process of collaboration between the group the accomplish a goal. In this sense many group projects in sink or swim depending on whether the group is able to come together and harmonize or not.

So rounding the third mile stone of our software engineering project, where does my group stand?

As I see it was are barely limping towards that finish line, much of these injuries sustained during the process of familiarize ourselves with each others work habits.

At the beginning of the semester, the group formation process was much easier. We were able to essentially choose our group, picking people that we've worked before and are confortable with. This made the first two mile stones pretty easy, as being grouped with Ed Meyer and Kendyll Doi, worked out well for me since I've worked extensivly before and I have easy access to commincations with them. We were able to immediately become productive within the first week.

This however, for our third mile stone, was completely different. Having ending our previous Wattdepot-Apps project, we were put into new groups. Although I've interacted with Edwin, Alan, and Anthony before in other classes during our days on ICS students, I had never actually work extensively with any of them on a project, let alone anything other than a quick shot answer worksheet. Overcoming his hurdle was actually the hardest part for me in the entire month.

The group dynamic did not work as well as my previous group. We had trouble communicating with eachother. There was the occasional email and a brief 5-10 minute group meeting every Monday/Wednesday for a status report on the project. Although this could have possibly worked on my previous project, there was another factor that prevented the fluency of the group dynamic.

The chain of sub-projects that was our code. It was like a giant three piece cog that would only move if all the pieces fit. The project as a whole was subdivided into three parts. Alan was creating the code for the actual meters themselves using Jamod, Edwin was creating the code for the meter sensors that would retrieve data from the meters and write them into the Wattdepot servers where they could be read by applications such as the Wattdepot-Apps. These two items were the basis the the entire meter to wattdepot system. Since we have not finalized a meter yet we do not have any actual meters to read data with, which is where Anthony and I come in. We were tasked with creating a simulation system for the dorms, in which would give simulated numbers and feed them into Alan's meter to be sent to Edwin's sensors then to Wattdepot.

Kind of simple enough I though at first, since Edwin and Alan had been working on this project for quite sometime they were at the verge of completing their sensor and meter respectively, with only a few technical glitches standing in the way. Because of this separation of groups, there was no unity in the entire project. I was hard to test if my simulated data could be read with the meter and then sensor because with only one person on one sub-project for so long, there was no real need to them to have it under version control. Then when Anthony and I joined the group, it was still a very hard process for them to continue to commit to version control until we had a wake up call the week before this mile stone. While working and testing on our part of the code, since our code is directly related to Alan's, if Alan continued to work on his, we could never be sure if they were compatible, and that had actually happened on several occasions were our code would work, but then later on we find out that Alan had made an update to how his meter retrieves data. It was brought to our attention that our style of cooperation was very unprofessional.

This week we hope to change that. With most of our code working individually, we have to connect them properly and find all the hing for the oils to make it run smoothly. My previous group worked very well with everything on version control and our automated build system quickly alerted us to breaks in the code. Working with Edwin who seemed to be almost on the ball with this, we gathered everyone's code and then was able to get everything up on subversion. I took a loot at the ant manual to get a working build system running. I now have a successful build system, although previous bad coding practices have led to numerous checkstyles and some pmd errors, which will need fixing before I can put the project on Hudson.

Rounding Third: Union of the Pieces

I've been worried for quite a while on the current state of this new project I'm working on. With my original project, the Wattdepot-Apps, ending I quickly jumped into a new, already existing, group for the next leg of the semester. This had brought with it many problems related to time constraints and the integration of the new members of the group.

I must admit that we are working together a lot more. We do regular speak to each other and talk about the current status of the project. It is very different from my previous group, as we were always working close with each other, every part of an application was a team effort, but at this point the group is not as cohesive. In other words, we are like two separate groups. Edwin and Alan are putting together the code for the meters, while Anthony and I work on getting a Simulation of data that we will be using. We are all over the place so much that a lot of times, I have no idea what Alan and Edwin have done so far, and only am I updated the next time we meet. I also cannot add any code into subversion because I had been given old code that was working and the status of their projects have progressed too far off from the old one. Although it shouldn't be a problem as my part of this project is not reliant on that of the others, at the end what we hope to accomplish is to connect everything together and pray that it works.

For this week, I've generated some estimated numbers based on my interviews with dorm students from the previous week, in conjunction with some research on the power usage of common dorm items. We created some spreadsheets to look at the graphs generated to make sure it shows a good and probably distribution of energy usage throughout the day.

Left is the weekdays % of the total max estimated usage of 26.5 Kw, right is the weekend estimated values. The graphs are on the same scale, but my screen shot alignments need some work.

We then modified in existing methods of the basic (random) class they were using to allow easy configuration with our simulated data which could be changed at any time. We did this by creating an abstract class, which is very similar to using an interface. I added in abstract methods to which the classes use, so now by can use generic "Data" objects that can switch from giving random numbers from the basic or using our Simulated (pre-defined) numbers that model our graph.

I hear on the other end that Edwin and Alan are inches away from getting their meter code it work the way we want it to. So far on my end it looks like we are wrapping up the simulated data and will be look forward to connecting everything together into a final product for presentation.

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.