PIC-IoT WG Pool Security System

This project was developed as a Senior Design project between Indiana University - Purdue University - Indianapolis and Microchip.

Contributing members: Ian Bowling, Raj Dhavalikar, Nicholas Molargik, Suketu Patel, and Jake Stauffer.

Project Sponsor: Mark Lowden of Microchip Technology Inc.

Submitted to: Professor Seemein Shayesteh Electrical Computer Engineering Department, IUPUI.

Project to be submitted on May 1st, 2020.

Introduction and Project Motivation:

The motivation for this project is to develop an alarm system for backyard pools to keep pools secure and children safe. This is achieved by utilizing Microchip IoT microcontrollers and MIKROELEKTRONIKA ClickBoard sensors to monitor entrances and the pool.

Backyard pools are widely used by many individuals, especially children. A tragic reality is that children falling into these pools has become a rampant issue. Unfortunately, there is minimal access to low-cost, efficient monitoring systems for pools.

Microchip Technology Inc. would like a prototype system that monitors and secures backyard pools. This system will have multiple components that will be connected to the homeowner's internet. These components will consist of Microchip IoT boards paired with Mikroe ClickBoard sensors. These attached sensors will provide information on motion, pool entry, and system states to a cloud environment and alert the homeowner instantly if anything happens through audible alarms and mobile messages.

Project Requirements:

The system shall be reliable, shall communicate over WIFI with Google Cloud, shall be scalable to a variety of pool sizes, shall provide audible alarms, shall provide mobile notifications, and the system shall increase pool safety.

The system members shall have access to a homeowner's WIFI signal and be protected from the elements where necessary.

The cloud shall handle the sorting of subsystem information which shall be accessible to the user through a GUI, shall communicate with all other subsystems and send texts to a chosen mobile device.

Design Choices:

• Gate Subsystem

The entry sensor should use a magnetometer, provide an outdoor alarm system, share information with all other sensors through the cloud, and be powered via USB. It shall be able to mount to an entry point and should also serve as the outdoors alarm.

To meet these requirements, the gate subsystem was developed with the Mikroe UNI HALL Click Board. This board allowed us to detect a magnet, indicating the position of a gate or door. A piezo buzzer was used as the outdoor alarm for testing purposes. Additionally, for the sake of testing, the gate enclosure is not waterproof, but this would be an important addition to a final product.

If any of the three alarms are raised, the device begins beeping the piezo buzzer. It is important that this buzzer reacts to all three alarms, as the pool subsystem does not include an audible component.

• Pool / Floating Subsystem

The pool subsystem shall be powered via rechargeable battery, use sensor fusion to detect ambient motion and pool entry, shall be protected from the elements and shall not drift to the corners of the pool. It also needs to be placed within range of a WIFI signal.

To meet these requirements, the pool subsystem utilizes the Mikroe PIR Click Board and Gyro Click Board, along with a rechargeable battery. The pool subsystem handles two separate "alarms": a patio alarm and pool alarm. The patio alarm, when armed, uses the PIR sensor to watch for specific human infrared light. The pool alarm measures the rate of change of three axes on the Gyro sensor, which measures wave activity. Threshold values were measured to differentiate between normal wave activity and alarming activity.

The two separate alarms allow for various scenarios of pool security. One can allow a small child to play near the pool without raising an alarm, but if the child were to fall in, the second alarm would trigger.

The pool housing was designed to float on water, 3D printed, and then sealed with a rubber coating to waterproof. It should be noted that 3D prints are not typically waterproof without post-processing such as this. For the PIR sensor, the housing needed a clear lid, and this was developed using an acrylic lid machines on a CNC router. Additionally, keeping the pool enclosure from drifting was not developed, but the enclosure includes an area for attaching such a solution on the bottom.

• Indoor Hub Subsystem

The indoor hub shall act as a secondary user interface for the system, away from the website. The indoor hub shall allow for arming and disarming of the system and provide an audible indoor alarm. It shall take up a minimal amount of space, be powered via USB, and must have access to WIFI.

To meet these requirements, the Indoor Hub was developed with an OLED screen, analog thumbstick, and piezo buzzer. For navigation, our team developed a series of side-scrolling menus. After startup, the user is presented with a homepage that details a few aspects of the system. To access menus, the thumbstick is thrown in a direction and the user must enter a PIN, also by moving the thumbstick. This takes the user to a horizontally-scrolling menu where they can arm or disarm our three system alarms. The user can also change their PIN.

If at any time a system alarm is raised, the Indoor Hub screen changes to reflect where the alarm took place. The device also starts beeping the piezo buzzer, creating our indoor audible alarm. Alarms can be cleared by entering the PIN, which will reset all three alarms across the entire system.

Web Development:

The following picture shows the result of our web development. The website watches the values in our Firebase Realtime Database and updates toggles or icons accordingly. It can be used to reset the system alarms, check weather, arm or disarm devices, and also register a phone number to receive text messages when an alarm is triggered or reset.

Software:

• Google Cloud Software:

On Google Cloud we have four Cloud Functions. These functions come together to create our communication and data storage system. Descriptions of each function are as follows:

• recordMessage: This function is triggered by an IoT PubSub event. When devices have a message to send, they publish an MQTT message to our IoT topic. recordMessage triggers at each receive event, grabs the data contained in the message, and writes values to our Firebase Realtime Database. The website then mirrors these values to update the control panel. recordMessage then pushes the message in JSON format to updateDevices through an HTML call.
• updateDevices: This function is triggered by an HTML call. When updateDevices gets a message, it analyzes what information is contained in the message and determines which devices need to receive the message. It then sends MQTT messages to all necessary devices.
• WebsiteRelay: This function is triggered by a change to the Firebase Realtime Database. When a change is made on the website, Firebase is updated and this function is called. This function makes sure that changes made on the website to not conflict with changes made on devices. It creates a message in a similar JSON format to those messages sent by physical devices and pushes it to recordMessage.
• textManager: This function is triggered by a change to the website or Firebase Realtime Database. Specifically, the function watches for an alarm to be triggered or reset. When this event occurs, the function uses a Twilio API to send an alarm via text message to a registered phone number, thus alerting the user that an alarm has been modified.
• Physical Device Code

The software architecture can best be described as an object oriented architecture that is driven by message passing between objects. Within the architecture, two main software design patterns are used to accomplish system functionality. The first pattern is the Observer pattern. For example, the CloudHelper and the SensorHelper will act as mediators between the device and the cloud and the device and the sensor respectively.

Most importantly these mediators will notify the device of any changes seen on the cloud or the device. The second pattern used is the State pattern. This will allow each device to keep track of the current state of the system.

Based on the state the system is in, only certain functionality can be carried out (eg. if the system is armed then the device can raise the alarm, otherwise it cannot). By utilizing this architecture, maximum organization and minimal coupling is achieved.

• Software Test Plan

Software testing will consist of three phases. The first phase will entail component testing for each software feature that will be included on each device (e.g. pushing/pulling data from the Google Cloud) which will ensure each feature works correctly and efficiently. The second phase will be integration testing which will test if components can work together (e.g. sensors and devices). The third and final phase will be a full systems test which will consist of end-to-end testing in order to ensure everything is working together properly. All tests are conducted and verified manually.

Testing Plan:

• Safety Measures and Precautions

The system shall be supplied no more than maximum input voltage to any component. The pool subsystem will be enclosed in a protective housing to prevent electric shock. All subsystems shall be placed in correct locations around the pool to eliminate tripping hazards and achieve reliable sensing. All final audible alarms shall sound at a safe yet alerting volume. System shall not represent or be presented by group members as a perfect system.

• Gate Sensor Subsystem Test Plan

The Gate Sensor Subsystem is composed of a magnet, the UNI HALL Click, and an IOT microcontroller. Testing will consist of observing and using the recorded effects of magnetic poles against the UNI HALL Click. Ideally, the presence of a magnetic field will raise the logic on the UNI HALL, thus representing a closed pool area entry point. The lack of a magnetic field will represent an open entry point. This logic will later be used in Cloud communication for notifications, system states, and alarm raising.

• Pool Sensor Subsystem Test Plan

Testing of the Pool Sensor Subsystem will be the longest testing phase. It will begin by testing individual sensor components before finally combining sensor information into a single package.

• Gyro Click Test Plan

Gyro Click testing will involve analyzing how tilt information is sent from the Gyro Click to the IoT device. From there, a variety of weather/pool conditions will be simulated using various means to log how the tilt information changes. This set of data will allow us to create a baseline and limits which the live Gyro Click data will need to exceed to be considered an alarming state.

• PIR Click Test Plan

PIR Click testing will consist of moving various objects within the range of the sensor to discover ideal sensing radius, format of generated data, and reliability. Ideally, a PIR sensor only triggers upon detecting the distinct infrared signal of a live object. This, matched with our data, will allow us to define the detection of a living object as alarming.

• Full Pool Subsystem Test Plan

With the Gyro Click and PIR Click tested individually, we will then be able to mount these sensors to a single enclosure and begin researching how to use sensor fusion to detect and confirm an alarming event.

• Indoor Hub Subsystem Test Plan

Testing the Indoor Hub will involve implementing a scrollable menu interface and confirming easy navigation through this menu using a thumbstick module. Testing will also involve confirming that the state of all other subsystems are transmitted to and from the indoor hub through the Google Cloud.

Testing:

The pool subsystem had to be tested for gyroscopic data, infrared data, and water-tightness.

Testing on gyroscopic and infrared data was conducted by placing the floating subsystem into a tub of water. Gyroscopic values were recorded over serial communication during different wave conditions in an attempt to find possible threshold values. These tests were executed across a period of two minutes to determine minimum, maximum, and average gyroscopic values on all three axes. Water tightness was tested by aggressively throwing and pouring water at potentially vulnerable locations on the enclosure.

After testing, the following values were recorded:

Using these thresholds in our software, we considered medium wave activity and above to be alarming data.

In the system, each subsystem uses the Google Cloud to relay messages to other appropriate subsystems. For example, whenever an alarm is triggered on either the pool or gate subsystem, a message is sent to the cloud and relayed to the indoor hub so that the display can be updated and the audible alarm sounded. To test all device-to-device communication, we used our project throughout its development. As the project code progressed, we began by testing communication from the cloud to each of our devices. Communication at either end arrives in the form of a JSON string, and by using the Google Cloud terminal and a serial terminal we were able to see messages being sent and received at each end.

By using existing code from a sample Google Cloud project, we were then able to use a message received at the cloud as a function trigger. This triggered function would then send a message to a device. By using this methodology, we could then send a message to the cloud from one device and have the cloud relay to a second device, therefore achieving device-to-device communication in its simplest form. From there, the next step was to modify our cloud function to determine the type of values it was receiving inside messages and relay those values only to appropriate devices. For example, if an alarm is raised at the gate, only the indoor hub needs to know. This simplified communication and allowed us to filter messages in the cloud rather than bombard each device with unnecessary messages.

Full system testing involves testing and verifying all major inputs and outputs of the system. All of the major inputs and outputs consist of the website and the separate hardware devices (e.g. pool, gate, indoor hub). Tests were conducted by interacting with one or many of the inputs and verifying the correct result occurs on the corresponding output(s). For example, if a device is armed or disarmed on the indoor hub, the website and the corresponding device should reflect that with an updated arm state for that device.

Results and Analysis

From the threshold data, we found that the mild wave activity closely simulated wind or rain activity, and that anything greater should be considered an alarming condition. The medium wave activity values were therefore set in our code as alarming gyroscopic values. During initial testing, there was also a slight water leak from the lid of the enclosure. This leak was patched and retested to confirm a tight seal.

Additionally, we found that the PIR sensor outputs a distinct value of when motion is detected. This essentially represents a boolean true or false value for when motion is found, and this mindset was implemented in the device code.

An indirect and asynchronous device-to-device communication was achieved that met the needs of our project by using Google Cloud Functions. Messages can be sent from any of the three devices or from the website to whichever device needs to be informed.

An example that highlights the complexity of message filtering is an alarm raised by pool motion. The pool sensor detects alarming motion and sends a message to the cloud to raise a system alarm. The cloud receives the message and determines that the pool is trying to raise an alarm. The cloud sends a message to the Indoor Hub, which reacts by determining the source of the alarm, updating the display appropriately, and raising the indoor audible alarm. Knowing that the pool enclosure does not contain its own audible alarm, the cloud also sends a message to the gate subsystem to raise the outdoor alarm. All messages flowing through the system are handled in a similar fashion.

Testing communication directly during development aided in discovering bugs or unnecessary redundancy. Once this communication met our requirements, we could move on to performing an end-to-end system test.

By using the methodology described previously, all system inputs resulted in their corresponding outputs. All arm, disarm, alarm, and reset events were correctly triggered by their corresponding inputs and reflected on the website and indoor hub. For example, when the gate was opened while it was armed an alarm message was sent to the cloud and relayed to the pool and indoor hub. Also, this activity was reflected on the cloud and the indoor hub by indicating that the gate was alarmed. In addition, the user's phone number was notified of this event.

Repeatedly performing tests for all types of inputs and outputs allowed us to exhaustively test the system and therefore verify its functionality was complete.

Lessons Learned

Waterproofing the 3D Printed Designs:

• 3D printed objects are not waterproof and must be sealed to ensure they don’t become waterlogged if they are intended to come into contact with water.

MPLAB X:

• I2C, as it is generated by MCC, works well, until it needs to be modified or expanded upon. In regards to communication protocols, it is important to not rely solely on GUIs such as MCC, but rather to step back and learn about the protocol’s fundamentals.
• If an unknown bug or issue is occuring with MPLAB X, attempt to resolve it by unplugging the device and restarting MPLAB X. Ensure that the device is plugged in first and recognized by the computer before you start up MPLAB X again.

Google Cloud:

• Have many print statements throughout the code in order to debug and understand what the code is doing.
• The IoT device must be connected to the Google Cloud before it can send or receive messages. Test the connection of the cloud and device by sending a command to the registered device.

Google Cloud Shell - Website:

• There is always an example available on the web that provides solutions to HTML, CSS and JS issues. Best way to find a solution is to either search for the outcome of the desired solution or an existing problem.
• A deployed website may not always contain the updated code. This can be resolved by clearing the cache data of the particular web browser, on which the website was deployed.

Software:

• Resist the temptation to create hacks in code whether small or large. Any hacks will lead to bugs and ridgid code.

Conclusion and Future Work

In conclusion, the final system demonstrates the ability of the sensor fusion to detect unauthorized activity in and around the users pool and to notify the user of such activity via audible alarm and text notification. It also allows users to control the system through a website that can be accessed on any device as well as through a physical indoor hub. The website lets the user enable or disable activity detection for the different subsystems, control the alarms, and edit the phone number to which the text notifications are sent. The indoor hub is password protected and allows the user to enable or disable activity detection as well view and control alarm states of the different subsystems. We believe this system serves as a concept, which when full developed could serve as a low-cost pool safety and security system.

For future work, there are five areas of work that would greatly contribute to the success of this system. The first area is testing the safety of the system. For example, the system is highly dependent on the cloud and having a stable WiFi connection. Future work must include having a fail safe in case WiFi connectivity is lost. Excessive testing of the cloud connection must also be done to see the full limitations of the system. Another safety feature that needs to be implemented is a secure website login system. There are toggles on the website that can manipulate the hardware, so a secure website that prevents unauthorized users from getting in is essential to the safety of the system. The second area of work involves improving the setup procedure for ease of use. The third area is ensuring the housing design is economically manufacturable. Designing housing for testing and manufacturing are very different processes. Our designs were mainly built for testing purposes, prioritizing adaptability and ease of use. For manufacturing purposes, it becomes much more important to focus on weatherproofing, quality of design, and minimization. The fourth area of work involves investigating cost reduction to ensure the most affordable product. Again, the testing phase of any project is usually more expensive than manufacturing a final product. While our project uses mikroelektronika ClickBoards, using individual sensor hardware on a final design would greatly decrease cost. The final area of work is automated testing. Testing, along with development, is critical to the success of any system especially when there are many components and when the system is upgraded. Future work in this area must include creating software test suites for the embedded device code, the cloud function code, and the website code. Automated testing would greatly speed up the testing process and ensure any new changes did not damage other parts of the system.