Inspiration

We found inspiration in looking over the reviews of the current Dominion applications on the App Store. Many users left reviews saying that when they needed to contact Dominion the most, Dominion wasn't there, or when they needed to pay their bills, Dominion's servers would be unavailable. We wanted to build an app to service these claims first and foremost along with a few other handy features to enhance the user's experience.

What it does

This application serves 5 main functions for the user.

  1. The user can submit power outage reports in as little as one click by registering their address with the system and sending a single push to the server. Alternatively, the user can submit information concerning descriptions of the outage, number of people affected in their home, and locations of downed power lines.

2.The user can receive notifications concerning technician's repairs. Ideally, if a technician is in the area, the technician can notify all users in that area of the power grid and let them know that power is coming back online shortly. Similarly, when they finish up in an area, the technicians can notify locals so that they can return home from any temporary locations that may have been while waiting for the power.

  1. The user can access their billing information through the application and pay/review their bills. This system is essentially already in place as a separate stand-alone application. We have not worked on this portion of the application because we understand it can be integrated into the application later.

4.The user will be able to pull the Dominion FAQ page straight into the application. This allows easy access for users when the website online is bottle-necked with users, which should prevent the site from going down in times when the community needs it.

  1. The creme de la creme of our innovative process is the ability for the user to access an Augmented Reality software which would scan a household appliance using Machine Learning software and recognize what sort of object it was. Having identified the object, it would return watt-hours for that object and tell you how much power your device really uses over a certain period of time. Similarly, the software would determine if the appliance used high energy amounts and would suggest techniques to reduce wasteful energy usage (i.e., unplug your coffee pot when you've finished making your coffee.)

How we built it

We had a number of ideas for design, but so many of the ideas we had weren't compatible with the frameworks we were familiar with, so we ultimately settled for a UML Architecture Diagram to fully depict our intentions with the application, even if we individually didn't possess the skills to turn it into a reality. The fundamental design of our revolves around having two servers: one to communicate with the clients, and one to communicate with the technicians. The clients would be able to push their outage reports to a mapping database that could further be fetched by the technicians so that they could know which areas had the most reported outages and who had seen power lines downed in certain locations. Then once the technician was at the scene resolving issues, they could push back to clients in that area. It isn't a novel concept, in truth, but its a concept the clients could benefit from immensely in times when they need it.

Challenges we ran into

Our biggest snag was that between the four of us, only two of us really know programming and we don't share a common code language between us. This led to a lot of discussion about the best software to use in order to maximize our joint skillsets. We had settled on Android Studio and had gotten to work on that, but around 1:00AM we discovered our Augmented Reality software was incompatible with Android Studio, as it had been depreciated from the software. Beyond that, there was too much collective exhaustion to restart a proper application, so we settled for developing a website.

Accomplishments that we're proud of

Our design plan is pretty solid, despite our inability to implement it properly. We have fleshed out UML diagrams down to the method and instance variable. We needed more skill to pull off something quite this ambitious, but we have laid the foundations for the future developers.

What we learned

We learned a great deal collectively about UML, and those who didn't know any code were taught code. Those who didn't know Git were taught Git. We spread around the resources we had to make sure we were collectively as on top of things as we could be.

What's next for Dome-inion: Dominion at Home

Implementation, in every facet.

Built With

Share this project:

Updates