Smartphone Meter Reading

Application
--------------------------------------------------------------------------------------------------------------------------------------

Planning Documentation and Initial Design

By:

Vishal T. Mishra - 5308057

Jingwang Teh - 5238699
Christopher Tan Wei Ming - 5297667
Olawale Adeyinka Adu - 5275441
Yuxin Deng - 4359999

Date:1st June 2017

(Approved by Supervisor)

Page | 1
Table of Contents
1. Introduction .................................................................................................................................... 3
1.1 Background ................................................................................................................................... 3
1.2 Scope ............................................................................................................................................. 4
1.3 Justification of the project: ........................................................................................................... 5
1.4 Overview of the document ........................................................................................................... 5
2. Initial Requirements List .................................................................................................................... 6
2.1 - Use Case ...................................................................................................................................... 6
2.2 - Requirements List ....................................................................................................................... 7
3. Implementation Planning: ................................................................................................................. 8
3.1 - Development Plans: .................................................................................................................... 8
4. Design overview ............................................................................................................................... 11
4.1 Iterative Design Process .............................................................................................................. 12
4.2 - Design Features - Ease of use ................................................................................................... 18
4.3 - Key Design Features .................................................................................................................. 20
5. Initial Design ..................................................................................................................................... 21
5.1 First Prototype ............................................................................................................................ 21
5.1 Considerations of standards and HGI’s ....................................................................................... 29
6. Knowledge and Analysis .................................................................................................................. 30
6.1 Project Timeframe ...................................................................................................................... 30
6.1.1 Current Timeframe .............................................................................................................. 30
6.1.2 Expected Timeframe ............................................................................................................ 32
6.2 Agile Methodology ...................................................................................................................... 32
6.2.1 Issues .................................................................................................................................... 32
6.3 Concepts...................................................................................................................................... 33
7. Future Work...................................................................................................................................... 35
8. Reflection.......................................................................................................................................... 37
9. APPENDIX ......................................................................................................................................... 39
9.1 Meeting Agenda .......................................................................................................................... 39
9.2 Meeting Minutes......................................................................................................................... 40

Page | 2
 1. Introduction

Our Group is working on the project titled as Smartphone Meter Reading

Application under the supervision of Dr. Koren Ward. The project is also
referred as Snap-Meter which forms our branding name. The Primary aim of the
project is to develop an application that is capable of reading various types of
meters ranging from simple basic analog meters to variants of digital meters.
The Application will be available to user and to the retailer, as two different
version respectively. However, there won’t be much of the difference in the
application between the two versions. The purpose of having two different
versions is to provide retailer (meter reading person) more flexibility and allow
him to save time. However, the purpose of not using the same version for the
client / normal user is to provide him with only the functionality he needs, thus
not complicating the use of application. The application at the present stage is
being developed primarily for the android platform, however in later stage it
will be extended to support iOS users as well. The primary objective of this
application is to provide an easy alternative and efficient one to users and
retailers to read meters.

1.1 Background

The point that needs to be discussed before discussing the application itself is
the need of the project, thus providing background information about the
application. This section focuses on the background details with respect to the
market and problem issues , needed to understand the implementation of various
design features and of the application as whole.
At present retailers / organisations pay a huge amount of money per year to get
the meter readings done. The annual average salary of a meter reader hired by
these retailer organisations is $50,000 per year which is a lot for many of the
organisations. Not only this the current process of reading the meter as stated is
expensive but also inefficient, as to cover large regions , organisations hire large
number of meter readers to get the job done, making it prone to human errors
and slow without the aid of technology.
Meter Reading companies tried to solve this problem by implementing the use
of smart meters, these smart meters used sim cards which gave them access to
the network and kept them connected online with the retailers directly over
network. However, the implementation proved inefficient and less feasible. The
telco companies did took advantage of this, as the functionality of the meter
solely relied on the telco service providers. Not only this smart meters charged

Page | 3
at a higher rate during the peak hours which was not widely accepted by large
population. Another issue that was raised because of the use of smart meter was
the radiation it released, the basic working implementation followed the simple
design where each meter used to send its readings over to the next meter at a
regular interval of time, however the last meter on the street was connected to
the retailer 24 X 7 , thus releasing more than accepted radiations.

1.2 Scope

The industry of using smart phone to read the meters is a growing one, which
clearly indicates we aren’t the only one to we working on the system to solve
the problems of the meter reading. At present there are 4 major companies
providing the same service. However none of them is in Australia. The major
players in the area of meter reading are Smartphone Meter Reading LLC,
Pixolus GmbH, EnergyElephant, and Munibilling. All these companies do have
one thing in common, i.e. the use of image processing library. Integrating the
products developed by these companies in Europe and America is bit easier
compared to here in Australia. Each of these companies provide variant versions
of the application matching the needs of the number of utility providers
available there.
However, our application do standout from the products developed by this
companies in numbers of aspects. Firstly our application tend to make use of
GPS to fetch the address automatically and secondly the application itself turns
out to be a Smart one, these two forms the key design feature of our application
which will be discussed later in this document. On other hand the application
designed by these organisations does not provide ease of use to the users, as the
whole product is developed keeping the Utility retailers in mind rather than
user. Lastly , even if brought in to the Australian market or any other country’s
market these products will fail with respect to the adaptability and will need a
retuning and revamped versions to support the need.
Based on these observation, our application does stand as a good market value
product keeping client and utility retailers in mind, providing the functionality
as needed by them in feasible manner.

Page | 4
1.3 Justification of the project:

After analysing the project’s scope and getting the background market value of
the application it’s necessary to have a quick look on the justification, why we
actually need an application with all the functionality offered by Snap meter.

On the basis of all the problem stated before our application tends to follow a
design which is very easy to use for user and the utitlity retailer as well. Our
project aims to provide efficiency and accuracy to read meters which will will
help the utility providers to cut down their cost of readin meter in a long term
run. Snap Meter also reduces the amount of work involved to read meters. By
using technologies, meter readers can be assured of accurate results and can get
their work done at a faster rate than before. From a normal user point of view
snap meters does help in reading the meters , allowing user to keep a track on
the utility consumption thus preventing the bill shock. The design feature of
having GPS to fetch in the address and Smart Application to detect the type of
meter and check for the values minimises the error rate and fasten up the
process by having the minimal user interaction.

1.4 Overview of the document

This Document has been produced with the purpose of describing the planning
and initial design of the application Snap-Meter our group has been working
under the supervision of Dr. Koren Ward. The document is divided into sections
like list of requirements, initial selected requirements implemented in our first
prototype, various design aspects and why they were chosen with respect to user
interaction, the developed time frame and current milestones along with the
working as per the selected methodology also focusing on our future plans with
regards to further development. The document also explains our first prototype
features and explains the system flow.

Page | 5
2. Initial Requirements List

2.1 - Use Case

The following section describes the requirements of the application, following

by the list of selected features that was selected to be the part of our first
prototype.

fig 2.1 Use Case diagram of the system

Page | 6
2.2 - Requirements List

The following section lists down the some of the key Requirements that our
application must have which was also described in details categorising it into
priority levels in the software requirement specification (Assignment 3).

 The Application should consits of login function allowing user to access the
system using username and password.
 The Application should have a registration page allowing user to create an
account.
 The System should have guest user access functionality
 The System should maintain the session and should not ask for login
everytime
 The System should support log out functionality
 The system should allow user to edit his profile
 The system should be able to read different types of meters
 The system should be able to detect the type of meter automatically
 The system should be able to fetch the location automatically
 The system should support voice feedback functionality
 The system should allow the user to view his past readings and
consumptions
 The system should allow user to file complaint to its utility provider.
 The System should allow the search functionality to quickly search the past
readings

Out of the following key requiremnets list some of the requirements were
categorised as of high priority and as a result of this they were implemented in
our first prototype . The list of selected requirements is as follows

Page | 7
 The Application should consits of login function allowing user to access the
system using username and password.
 The Application should have a registration page allowing user to create an
account.
 The System should maintain the session and should not ask for login
everytime
 The System should support log out functionality
 The system should be able to read different types of meters
 The system should allow the user to view his past readings and
consumptions
 The system should allow user to file complaint to its utility provider.

All of these implementations are explained in section 5. Initial Design – First

Prototype

3. Implementation Planning:

3.1 - Development Plans:

At the start of the project we carried out a bit of research with respect to the
technologies that we will be using to achieve the functionality along with some
general research on the development platform along with various human
interface guidelines we need to follow. On the basis of these research we came
up with specific technologies and platform versions to be used. This section of
the document gives us an overview on our development plans.

a. Development language to be used:

The primary development platform for the project is decided to be as android, as
a result of which the development language has to be Java. Since Android
makes use of Java Language for development of android application
After the completion of the Android application the application wiil be extended
to iOS platforms, thus making use of Objective C and Swift as primary
development language for the respective platform.

Page | 8
b. Technologies to be used:
The key technology needed for our application to successfully achieve the
desired goals is image processing libraries. For our project, we decided to make
use of OpenCV and Anyline OCR to read the meters.

c. Why we need two different image processing libraries?

Our project intends to read meters, there are different types of meters available
that are application should be able to read. As a matter of fact, all of the meters
differ from each other. Here are some of the commonly used meters that are
application aims to read accurately and efficiently.

Page | 9
On the basis of this research, it was found that different meters requires
different mechanisms to be read. If a single library is used to read all type of
meters it can prove inefficient with respect to accuracy and time.
Thus, we make use of Anyline OCR to quickly read all the digital meters and
use OpenCV algorithms to read the the analog meters with dials, by calculating
the pixel value and calculating the average thus getting the points on dials

d. Platform Version:

Page | 10
On the basis of the above mentioned statistics we aim to develop our project for
all the android mobiles running Android 4.1 or above. (Developer.android.com
2017)

Similarly, as per the report by apple, approx. 79% iOS devices use iOS 10
followed by iOS 9 which share 16% of the market. As a result if the secondary
need of the project that is development of iOS application is to be achieved we
will be developing the same for iOS devices running version 8 or later.
(Developer.apple.com 2017)

4. Design overview

To understand the design principles its necessary to highlight some of the

problems associated, with the meter reading from different views.. Explained in
section 1 - Introduction

From Customer point of view :

- They are not very familiar with reading the meter
- Human Error / Inaccurate readings

Page | 11
From Utility retailer point of view
- Human Error
- Expensive
- Time Consuming

So as a result of all the problems associated with current meter reading

techniques , we wanted to build an application that is
 Easy to Use.
 Fast and efficient
 Accurate
 Requires minimal user interaction
 Accessible to large number of audience

Therefore, we decided to implement the following design principles, the main

design features of our applications are as follows
 Iterative design process
 Easy to Navigate
 Known interface and menu options
 Help Menus.
 Navigation Help.
 Smart Application
 GPS Support

4.1 Iterative Design Process

For the development of the interface of the application, we followed the

iterative design methodology, although it isn’t a design feature but it did help us
in achieving a design suitable for our needs.
For the interface we didn’t jump to the final design at once, we started building
mockups, got them reviewed from our supervisor, noted down the changes,
made the adjustments reviewed it again , this cycle continued for number of
times and as a result of which we finally ended up with a dsign approved and
verified by our supervisor.

Here are some of the examples of the iteration improvements we made over
iteration cycle.
Page | 12
a) Communicative Buttons

In the first screen, you can see that we used a buttons having names as Login
and Signup. This was our first design, however in the next iteration we changed
the buttons to be more communicative and removing the feel of the button by
replacing the text as “Login”, “Don’t have an account? “and “Forget password”,
however the title “forget password” wasn’t very suitable as the user might face
problems with username as well as a result of this we changed the title to
“Having trouble?” in the 3rd iteration. The reason for doing changes was to
make user more comfortable with various options available and make the
system more interactive to the design.

Page | 13
 b) Tour Screen

We decided to have a screen at the start of the application to give user an

overview of what exactly the functionalities of the application are. There were
changes that were made to it over iteration cycle. In the first iteration, we didn’t
provided user the option to hide the tour screen on his second visit to
application, which means based on the first design user would have visited tour
screen everytime he turns on the application which wasn’t very user-friendly
approach. As a result, in second iteration we provided a check box to the user to
tick if he doesn’t wish to see the screen on his next visit.

Page | 14
 c) Menu options

At the first iteration, we made the menu options available to user using carousel
view, which did provide the application a better look and feel but wasn’t very
feasible from user’s view. This approach would have asked user to scroll left or
right to select a menu option which doesn’t make it very user friendly, as a
result of this we replaced the carousel view in our second iteration to a single
page layout displaying all the menu options at once.

Page | 15
 d) Read Meter option

Reading meter is one of the key feature of our application. We wanted to have
an application that allows user to read meters without much of the user
interaction and efforts. But our first design failed to accomplish this target, In
our first design the read meter was asked user to select the meter he wants to
read, later on at the camera screen asking him to capture the meter snap to get
the reading. But one of our objective was to have a system requiring minimal
user interaction. Thus in our second design we removed the select meter screen
thus meter reading option directly taking user to camera screen, where the meter
will be read without any clicks of button thus providing better usability and user
friendly design.

Page | 16
 e) View Past History

This option allows the user to have a look at the past read values. As in our first
design we were focusing on the look and feel of the application, thus the first
design didn’t have a very user-friendly approach to do this. We presented user
with large calendar icons to selct the month by scrolling either left or month and
view the reading. In the second iteration, we opted to have a list view rather
than a calendar view and having all the readings displayed in single screen.
However, our supervisor raised a point of having a large list of past values,
scrolling through the list wasn’t the best approach. Thus, we placed in search
and filter options to ease the process and make it more feasible.

Page | 17
 f) File Complaint Screen

This option allows the user to file a complaint to its utility provider with respect
to any problems associated with meter like example faulty value. In our first
iteration we had a screen, which displayed a form where user was given a
option to write in the subject and fill up the body with the complaint. Along
with this user was also displayed his username and main meter id. But from
user’s perspective providing username and meter id wasn’t needed as a result
we removed this two information from the form. The third iteration replaced the
conventional send button to a button icon providing the better look and feel and
also providing user to send an attachment along with the complaint.

4.2 - Design Features - Ease of use

We wanted to have an application that is easy to navigate As a result, we

decided to have menu options having names in context to what they do. the
whole menu is designed keeping the user in mind, as a result achieving a overall
known interface for the user, thus clicking on options like delete, submit or any
other options performs the functions as expected by the user , and does not lead
the user to something which he is not aware of or something new.

Page | 18
Even though having a very well organized and known interface, user can still
get confused about some or the other functionalities. As a result, we have placed
help options to help user with the application use. These help menus are placed
on every single screen and even in the navigation drawer so that user can
quickly refer to it in case of any confusion or help. We also provide navigation
menu drawer for quick navigation to different functions of the application, thus
user can navigate to any other menu options without clicking much of the
buttons.

The screen above displays the menu option and quick navigation drawer. You
can see that the names of the menu options are very clear and labelled with
context to the functionality also the icons used represent the functionality of the
option. The quick navigation drawer is accessible from any screen (other than
camera screen) and have various quick navigation options available.

Page | 19
4.3 - Key Design Features

The Key design features are

 GPS Support
 Smart Application

Currently the process of reading meter requires the meter reading person to
enter the address manually into the system while reading the meter, which is
time consuming. But our application will not ask the reader to do the same,
using Meter’s Unique ID and GPS of the phone it will automatically detect the
address of the meter. Secondly while reading the meter the user doesn't have to
capture the meter reading by click of the button, as soon as user focuses on the
meter value it will be detected and saved.
But having just these features didn’t quite made us unique to the customers, as
result of which we decided to have a smart application. Reading meter is a vast
discipline as there are number of meters within each utility resource, for
example in case of electric meter user has to read peak meter, solar meter and
main meter. It will less feasible design if user has to tell the application which
meter he’s going to read. But in our case, our application will be smart enough
and will automatically detect the type of meter it’s reading.
This will be done by using meter’s unique id. Along with this it will also check
the meter’s current value and will compare it with the stored value (previous
value) to see if the value is in range of what expected, in case of error it will
alert the user and will ask for the confirmation.

Page | 20
5. Initial Design

5.1 First Prototype

The first prototype that our team has designed are as follow:
1) Start the tour screen

The start the tour screen will be presented to the user when they open the application
for the first time. Once the user clicks the start the tour button, the application will
show them various types of function that the application can perform. This screen was
implemented to give users a rough overview of the application and to help them to get
familiar with the application. The start the tour button is available on both the
customer and retailer version.

Page | 21
 2) Main Menu screen

Once the user has completed the tour he will be navigated to the main menu page
where the user can choose what they want to do such as read meters, view past
readings, register a complaint and logging out from their account. We aim to design a
simplistic and user-friendly interface for the user hence, the swiping function to select
their options.

Page | 22
 3) Sign In screen

The sign in screen is designed to be simple and direct, users will just have to enter
their user name, password and click on the sign in button and that is it. This 3-step
sign in process makes signing in easy for users. However, if the users doesn’t have an
account, he/she can click on the sign up link at the bottom of the screen which will
prompt the user to a sign up page

Page | 23
 4) Sign Up screen

Users who don’t have an account will be navigated to the sign-up page where they
will be able to create a new account. The application will prompt the user to enter
their details such as user name, email and password. Once they have entered those
details their account has been created and they will receive an email notification that
their account is created and they will be able to sign in straight away. Also, there is a
button at the bottom of the screen whereby if a user already has an account they can
click on the button which will navigate the user to the sign in page.

Page | 24
 5) Read Meters

Reading meters is the main functionality of this application. On this screen when a
user clicks on read meters, will open the phone’s camera and there will be a box on
the screen. The user must align the meter numbers within the parameters of the box.
There is no need for snapping the image, the app itself will auto detect the reading for
the user. There is also the option to turn on the flashlight on the bottom right of the
screen for more convenient meter reading during the night. Furthermore, if there is a
barcode on the meter that the user is reading, the user can turn on the barcode
detection on the bottom left of the screen The application is designed to read different
types of meters as shown below

Page | 25
 Meter Reading Screen

Different Types of meter that the app can read

6) Register Complaints

Page | 26
Register complaint is an accessibility functionality. When user touch this button, there
will appear another site shows how to upload Complaint. When user upload
complaint, first user should type subject on the text field, and user also needs input
body text. If user has attachment, also needs upload. When user finish this form, the
problem will report to the service department, and problem will be solved as soon as
possible.

7) View Past Reading

This application support user check the past readings. If user use application to
reading meters, the record of this action will be recorded. If user want to check past
record, just click “View Past readings” button, the screen will show the record of
readings, and records include date (When user use app to read meters), type of meter
(which type of meter box) and reading (the number of meters).

Page | 27
 8) Quick Navigation

At the top left of main menu screen. There is a controlled icon menus, when user
touch this button, it will shows quick navigation site on left side. The quick navigation
includes main menu, read meters, view past reading, file complaint, update profile,
logout and help. It includes all the funcations of this apllication. User could directly
choose all funcations. And user account information also shows on this screen, and if
user want to change account, application also support this funcation. On the bottom
right of all screen, there is a questionmark, it is a help button. If user has problem of
using application, it will give right answer for it.

Page | 28
5.1 Considerations of standards and HGI’s

Focusing on the Human interaction guidelines, the application will allow the
user to change the theme style for the application. allowing him to choose either
dark or light theme. As mentioned before the interface is designed keeping users
in mind making it easy to use and navigate, guidelines have been followed
while labelling the various text fields and menu fields such as username and
password textbox, menu options and also in other parts of the screen. The
application has also been designed to follow the content placement guidelines
one of the example is permission access guidelines which will be mentioned
later on in the report.

a. Content Guidelines
All the buttons will follow the padding and margin requirements:

Page | 29
b. Permission Access
Since our applications will be making use of the camera, internet and GPS, users will
be asked for their permission before the app can access it. Furthermore, we also
followed the guidelines that is required to display the permission access dialog.
Asking only for permission is required by the app – asking for specific resource
permission needed by the application. Lastly, is being transparent. Our app clearly
states the resources that we need to access and why we need them.

c. Consideration of Accessibility

Although the consideration of accessibility was not needed for any special
accessibility design features. However, for the long term we decided to have these as a
part of our application which was approved by our supervisor, Dr Koren Ward:
 Multilanguage support: Since our application can be used in many other
countries as well it is necessary for it to support the different languages.
 Text Resizing: The user will be given an option to increase or reduce the size
of the text within the application
 Smooth Transitions: Those who may have epileptic seizures, will be able to
safely use the application as we have ensured transitions
 Voice Feedback: The purpose of having voice feedback is to serve people with
autism – having problem in reading the text on screen, also will help other
users as well.

6. Knowledge and Analysis

6.1 Project Timeframe

6.1.1 Current Timeframe

As of now, milestone from Sprint #1, which is to add the core meter reading
functionality for the purpose of demonstration and improvement, and android
application and website application authentication functionality has been completed.
From Sprint #2, based on user feedback, the core meter reading functionality in the
mobile application has been improved, and the presentation layout of both
applications have been modified and improved on, such as colour theme and contrast,
and website structure).

Page | 30
Page | 31
6.1.2 Expected Timeframe

Our expected timeframe for the current sprint (4 weeks sprint duration) is as follows:
Sprint #3 (26th May 2017 – 23rd May 2017)
 GPS functionality to be incorporated when using the core meter reading
functionality.
 Utility consumption to be tracked and its analytics displayed.

Sprint #4 (23rd May onwards)

 Voice feedback implemented when using core meter reading functionality.
 Send feedback and complaints functionality

6.2 Agile Methodology

6.2.1 Issues

The main aim of SnapMeter is to enable users to read meter readings on our
smartphone application through the use of image recognition and vision processing,
which involves understanding image processing libraries and its capabilities, along
with the possible hurdles and time required when learning new technologies. With that
being the main functionality, our client, Dr. Koren, has made developing a prototype
to demonstrate this functionality a priority.
Aside from that, we are to also implement a customer version mobile application, a
retailer version mobile application, and a retailer website application. Given the range
of functionality required and the overlapping of similar functionalities in customer and
retailer versions of the mobile application, it was decided that an incremental
development methodology would be best used to handle this issue.
In addition, while the main functionality is being prototyped, the interface of both
mobile and web application are being designed and implemented. This allows us to
deal with the ever-expanding scope of our applications and its functionality, and also
receive feedback for the implemented functions that are based on the above-
mentioned libraries.

Page | 32
6.3 Concepts

The key concepts on Agile Methodology that allowed us to develop our project in this
manner include:

 Minimum Marketable Features

 Iterative and Incremental Approach
 Time Boxed
 Continuous User Feedback
 Open to Change
 Measurable

Minimum Marketable Features

In Agile Methodology, priority is given by the client and development team to the
product’s most important functional requirement, in that without any other features,
these requirements will still achieve a complete usable product. In relation to our
project, priority is given to the development of basic meter reading functionality.

Iterative and Incremental Approach

From the implementation of minimum marketable features, the methodology involves

repeating the process and adding more functionality throughout the product’s
development life cycle.

Page | 33
The process first involves gathering requirements through backlog grooming and
creating a product backlog. At the start of each iteration, sprint planning is done for
each sprint in order to determine the set of user stories to be prioritized and
implemented. For the duration of the sprint, the user stories are implemented, along
with weekly stand-up, and ending with end-of-sprint review.
This process gets repeated as more user stories or functionalities are added to the
product while having prioritized the above-mentioned minimum marketable features
at the start. With meter reading functionality implemented, more functionalities are
then added to the product, including meter reading analytics and billing features.
The product will then be developed iteratively and incrementally until our Client, Dr.
Koren, is fully satisfied with the implemented functionalities. This development life
cycle will end at the end of the year when the product is to be displayed in the Trade
Show.

Time Boxed

In Agile Methodology, our Scrum Master, Vishal Mishra, specifies time boundaries at
the start of the project, which includes the time for weekly stand-up and the duration
for each sprint. This prevents the process from going over the specified time
restriction in order to keep the product development in track.

Continuous User Feedback

Throughout the development life cycle, frequent user feedback from our Client, Dr.
Koren, is received and incorporated into the product development during each meeting
with client on every Friday 12:30pm. Feedback from Dr. Mark Freeman is also
considered when discussing issues with Dr. Koren.

Open to Change

As we develop the product, there are bound to be changes on user requirements. Due
to the iterative approach of Agile Methodology, we can incorporate this change
request in the follow-up sprint. When changes or additions to the basic meter reading
functionality occur, we simply add the change (e.g. interaction flow and interface
changes) in the next sprint to improve the product.

Page | 34
Measurable

In Agile Methodology, features are broken down into user stories that can be easily
tracked and managed. These user stories are then implemented into the product in
each sprint according to priorities, and added incrementally throughout its
development life cycle.

The user stories that were specified are similar to the functionalities that have been
given priorities in the Software Requirement Specification (SRS) document. This
allows us to measure the progress of the development as more functionalities from the
SRS document gets implemented.

7. Future Work
With the near completion of this project there are several possibilities to expand it.
Below follows a brief description of areas which can be expanded upon to make the
snap meter app smarter and extend the potential of the models

a. GPS Implementation

One of the key features of the snap-meter application is to have a GPS to fetch
location automatically. This feature is mainly used on the retailer’s version whereby
meter readers can accurately pinpoint a customer’s location accurately and to look up
which customer’s meter has been read and then enters it into the database. This will
also help resolve customer disputes, making it convenient for meter readers to locate a
customer house, optimize reader performance and aid in locating meters and other
utility field assets. The design feature of having GPS to fetch in the address
minimises the error rate and fasten up the process by having the minimal user
interaction.

b. Reading Dials on Meter

Up till now, our app is only capable of reading numbers and barcodes from the meter.
In the upcoming semester, we will be enabling the app to read meter dials from the
meter which is more complex and requires a different algorithm. We will be using
OpenCV to read the analogue meters with dials by calculating the pixel value and
calculating the average to get an accurate reading on the dials. This will also be done
on the same concept as reading digits of the meters. Users will just have to scan the
dials within the size of the box depending on what type of meter they selected.

Page | 35
c. Generating Bill Usage

Once our app is able to read all the meter and the dials correctly, we will proceed to
calculating the bill usage of the customer and even predict their future bill usage.
Users will get to see their billing information based on the information in the image
and the billing database. Furthermore, users will also get to track their bill usage from
their previous month to do a comparison on how much energy is consumed in a graph.
This system will enable the user to keep track of their utility bill thus eliminating bill
shock.

d. Publishing the app to Play Store

After finalising all the functions and making sure that the app runs smoothly with zero
error, our app will be ready for deployment. We will use Android Studio as the
official IDE for Android app development. We will be using Android studio to
publish our Smart Phone Meter Reading application on the Google Play Store. In
order to do that we will have to go through the Google Play Developer console which
require us to pay a one-time fee of USD 25 to set up a publisher account. After that
our app will be available to download by the public on Google Play Store.

e. Ability to file complaints

We want customers to have the option of filing complaints to their utility providers on
their application, thus creating a modicum of relationship between customers and their
respective utility companies.

f. Viewing past readings and consumptions

We need to implement a system within the application that allows users to view their
past readings and consumptions to be able to compare utility usages, thus making
users aware of how much utility they ae going through every month/reading cycle.

g. Have guest user access functionality

Customers should be able to read their meter without having to through the sign up
progress thus making the meter reading process faster.

h. Support voice feedback functionality

This accessibility function will be implemented for people with special needs that still
needs to use our application.

Page | 36
i. Search Functionality
Customers should be able to search for their past readings on the application dating
back to the first reading they made.

8. Reflection
This project that this reflection is written about was the development of a meter
reading android platform application. The purpose of this group project was to
develop an android application that reads meters using mobile devices, be it the meter
is an energy, water or gas. The paper is constructed in such a way as to display each
member’s personal perspectives.

Summary of Collaboration

Our group began its journey on March 3rd, this was when the first project class was
conducted and everyone that attended the class was briefed on what to do and what to
expect in the course of their project development. We started out with 3 members that
consisted of 2 BIT members and a CS member, this group later expanded into a group
of 5 members that consists of 2 BIT members and 3 CS members. Based of the set of
skills each of us had in the group, we chose 3 projects we would like to work on and
we were awarded the Smart Phone Meter Reader project led by DR. Koren ward. With
Vishal spearheading the group as the leader, we have made tremendous progress
through incessant communication and sharing of ideas about to make the development
of the application go smoother and faster.

Context:
The majority correspondence took place using Facebook messenger and the Facebook
Group that was created to share files and communicate. The response time to
conversations started by anyone was/is usually responded to within minutes by at least
2 members. However, it was clear which group members were better at time
management. Nevertheless, everyone persevered and the task was accomplished on
time. From my perspective, Vishal and Phillip started it off by suggesting
programming languages we should use in development; Adu, Christopher Tan and
Chris Deng added their research and report writing skills. We all showed our strength
in one way or the other which is how and what a collaborative project should be.

Strengths:
Facebook Messenger correspondence was the quickest way to communicate with
other. Anything that was unclear was clarified or corroborated by another member. No
group members were afraid to ask questions and everyone took on a responsibility.

Page | 37
Weaknesses:
In the early parts of the project, it was difficult to get everyone on board. This was
partly due to everyone getting a feel for the course and for each other. And because
most of the communication was/is done online, there tends to be a massive
miscommunication sometimes. This often causes discords among group members.
Nevertheless, the project is on the right track and that is all that can be expected from
a group of five who have never worked together before.

Page | 38
9. APPENDIX

9.1 Meeting Agenda

After first 6 meetings the group successfully conducted 3 more meetings to carry out the
smooth functioning of the group activities

1. 28th April, 2017 – There were quite a number of tasks that were conducted in the meeting
starting of with the review on the functionality of the prototype that was able to read analog
meters (without dials) and digital meters along with some other functionality like sign and
sign up , also previewing the past read value. The later half of the meeting was more of
assignment oriented, tasks was alloted for assignment 4,5, and 6. Assignment 5 was building
up of a preliminary website, wherein everyone was asked to submit a design (layout) in prior
week, a final design was approved in this week’s meeting.

2. 12th May, 2017 – This meeting focused on reviewing the presentation everyone prepared
(parts of presentation for interface design) later on merging on everyone’s part and getting a
final set of slides ready. Also discussion was made on the report structure of the assignment 6
that focused on planning and initial design of the project.

3. 25th May, 2017 – We had an practise for the presentation that was schedule the next day,
later on we reviewed each others work that they were asked to complete for assignment 6. As
it was the final couple of weeks of university and everyone was caught up with number of
assignments, we made an agreement to discuss the changes over group chat on facebook.

Page | 39
 9.2 Meeting Minutes

MEETING 1 – DATE : 28th April, 2017

Date: 28th April, 2017 , Friday Venue: Building 3 - Front Area

Start: 12:30 P.M Chair: Philip

End: 2:10 P.M Minutes: Philip

Vishal Mishra

Philip

Attendees: Chris Tan Apologies:

Chris Deng

Adu

No Task / Agenda No Sub-Topic Responsible Duration Outcomes

1 Protoype Overview 1.1 Prototype Everyone 40 Minutes During this
Explaination / meeting we
Demonstartio presented our
n prototype to Dr.
Koren Ward,
Explained the
functionality that
we have achieved
at the moment
and what are
plans are for the
coming weeks

We talked about
the methodology
(use of libraries)
we have used
while
explaination.

She then adviced

with the

Page | 40
 alternative easy
to use
technologies that
we can use

2 Prototype Review 2.1 Noting down Adu After having a

the changes look at the
prototype
there were
25 minutes number of
changes that
was asked to
be made.

A rough task
sheet was
prepared
which
pointed out
to the
changes
necessary.

3 Planning And 3.1 Assignment Phillip and Vishal 15 minutes All the assignments
Activities’ Work task were now due in
allotment last few weeks of
the session, and
we couldn’t have
waited for the
date to be around
the corner to get
the tasks done.
As a result we
decided to have
our assignments
done before due
dates.

Tasks was alocated

for upcoming
assignments
4 Website Design 4.1 Finalising the Philip and Chris 20 Minutes One of the
approval design Tan assignment
required a
preliminary

Page | 41
 website to be
designed
containg a lot of
informations , as
a result it was
necessary to have
a proper layout to
represent the
information
asked.

We finalised the
website layout
and design in this
meeting (using
the mockup
layouts we
prepared during
the last meeting)

Action Items
No Item Responsible Deadline Comment
1 Slides on interface Everyone Next Meeting Completed
design (specific on time
section alloted to
each one)
2 Thinking about the Everyone By next Meeting Completed
report Structure on time

MEETING 2 – DATE : 12th May, 2017

Date: 12th May, 2017 , Friday Venue: Building 3 Front Area

Start: 12:30 P.M Chair: Vishal

End: 2:15 P.M Minutes: Vishal

Vishal Mishra
Attendees: Apologies:
Philip

Page | 42
 Chris Tan

Chris Deng

Adu

No Task / Agenda No Sub-Topic Responsible Duration Outcomes

1 Slides review Everyone 30 Everyone showed the
Minutes part of work they did
on the interface
presentation

Everyone analysed
each other parts , also
considering the flow
of presentation and
pointed out the
necessary minor
changes that was
mandatory
2 Refinement Everyone 50 minutes Based on the review we
made the necessary
changes to
presentaation

We then worked
towards achieving a
final presentation ,
i..e we merged all the
slides together
forming the final
version.
3 Report Structure Everyone 20 minutes We discussed over the
topics and sub topics
that we need to put in
the assignment 6
report on planning
and design

Page | 43
 We concluded the
meeting having a final
structure of the
report ready

Action Items
No Item Responsible Deadline Comment
1 Report sections Everyone Next Meeting Completed on
time

MEETING 3 – DATE : 25th May, 2017

Library Group Study Room

Date: 25th May, 2017 , Thursday Venue:
4

Start: 2:30 P.M Chair: Philip

End: 4:00 P.M Minutes: Chris Tan

Vishal Mishra

Philip

Attendees: Chris Tan Apologies:

Chris Deng

Adu

No Task / Agenda No Sub-Topic Responsible Duration Outcomes

1 Report review Everyone 30 Everyone showed the
Minutes part of work they
completed for the
report of assignment
6

Everyone analysed
each other parts , and
necessary changes
were asked to be

Page | 44
 made
2 Presentation Everyone 35 We practised for about
minutes 35 minutes for the
presentation that was
schedule for the next
day

The aim for the practise

was to get the timing
right as the maxium
allowed time for
presentation was 7
Minutes

3 Group Discussion Everyone 20 minutes As we decided this to

be our last meeting
for this sessiona s
everyone was caught
up with loads of
assignment , we had
an discussion over
things that went
wrong during this
session, how we will
be communicating
and getting things
approved till the
submission.

Differences in group
opinions were sorted
out

Date was fixed for next

meeting

Action Items
No Item Responsible Deadline Comment
1 2nd Prototype Vishal Next Meeting

2 Progress report Adu , Chris Tan , Next Meeting

Chris Deng and
Philip

Page | 45
3 Reflection on this Adu By 30th May , 2017 Completed on
session’s work time
and experiences

Page | 46