NSY™ | Devpost

2 Minute Video: https://www.youtube.com/watch?v=7YbsF5LEivI Final Project Video: https://www.youtube.com/watch?v=xnEYmvcZLlE

Inspiration

When we were away on vacation, someone tried to get into our door repeatedly. After knowing it was locked, they proceed to smash it with a crowbar and then break it down. Thankfully, due to its steel inner construction, they were unable to get through the bolted door. However, the replacement for the door was quite expensive, and knowing someone tried to break in made us scared to leave the house alone. Even though video surveillance spotted someone, we would have been much more comfortable knowing that a stranger had stopped by.

What it does

RA trying to stop your party? Bounty-hunter looking for you? Sid looking for your final project? We have a product that will have you ready for all these circumstances.

NSY allows you to know when someone is knocking on your dorm room door - even when you’re not there. NSY is a state of the art gadget that attaches to your door, and senses when someone attempts to enter your premises. You and everyone you grant passage to will be given a sensor that allows them to access your quarters without alerting you. If a nosey neighbor, or anyone unequipped with the sensor, try to open your door, or even pick your lock, you will receive a real-time notification, and if need be, you will be able to come to your dorms rescue. You can even set up NSY so that everyone in your home is alerted, and intercept the danger. The other benefit of NSY is that it is an invisible doorbell - your visitor will not know that you know where they are.

How I built it

The building process for NSY took a lot of turns for the better and the worse. The first part of building NSY was properly syncing the door sensor and making sure that the accelerometer would only trigger if the door was actually being opened. To do this, we synced the accelerometer coordinates when it was placed and then used the change in coordinates to dictate if the door was being opened. This allowed us to use position rather than velocity, which meant that no matter how quickly someone opened a door, the accelerometer would be able to check when the door was opened. We had to do this after having problems with how when a door was opened slowly, the accelerometer wouldn't always pick it up.

Once we had the accelerometer built, we went on to Bluetooth testing. While this did not make it to the final design, this was a large learning experience for us. The reason we took this out of the final design was that it was clunky and uncomfortable for the user, and also lowered the security of our design. The idea was that the slave on the door would read if a connection with a paired device was possible, and if so the sensor would not notify the user of anyone trying to open the door. This worked, however the use of another Arduino to make the sensor and the additional module meant that the sensor was large and unwieldy, and it also meant that the user would have to manually shut their Arduino down after they entered the premises. This was removed from the final projected as our team decided that this compromised security, as we could not have the Bluetooth sensor stop working once someone entered the room, because if another person entered with another sensor they would be unable to prevent the notifications.

Using wifi, we created two different HTTP prompts that would use our uploaded data to notify the person. At this point our hardware was complete and we were using our Arduino Uno with Wifi 101 and the accelerometer as our only sensor. We then uploaded the data to ThingSpeak and ran continuous online scripts that would take in this data and have the correct response depending on the situation.

To choose a script, we incorporated a pushbutton in the probe that would switch modes between the two scripts, but we ran into trouble when this set us over the data limit on the Arduino, so we instead made it so that you could simply turn them off in our online ThingSpeak application.

The first one of our scripts we called "NSY Local" and this would send the owner of the NSY probe a simple text message when someone opened the door. When I had this installed on my dorm's front door, I would receive a text that simply said "Hey Alec, someone has entered your front door. Stay safe!". We did this by using a Twilio API key that would only be registered when a boolean we uploaded was read as "true". This message would be resent every 30 seconds for several minutes until the doors open state would sync with the accelerometer position, so you wouldn't continue receiving multitudes of messages if your front door was open, for an event or other reason.

The second script we called "NSY Travel" and its intended purpose was if you were traveling but wanted updates on your house as you traveled. When traveling, you often do not have a cellular connection, and even if you do text messages can be quite expensive. To combat this, "NSY Travel" will automatically send you an updated tweet every two hours, that will tell you the current state of your house, and if you need it to be checked upon. This meant that you had a very low internet data option to check on your house, and if you have anything to worry about, you can share it with someone you trust near your house.

This culminated in a simple, small footprint, and low interference sensor that used minimal energy and would keep you in the loop about your home's safety at all times. The building process had a lot of twists and turns, but we are satisfied with the NSY product we created.

Challenges I ran into

We ran into quite a few challenged with our NSY sensor. The first of which was large, and was incorporating Bluetooth into the sensor. We had the slave and master modules set up on separate Arduinos, one stationary that would act as our "doorbell" and one dynamic that would act as the "key". The "key" however could not work with the NSY sensor, as there were several problems.

The first was that as the door module would try to check if the key was available, it would stop uploading any data to the internet while it was paired with the key. To combat this error, we changed the code in our sketch not to pair with the master, but instead to check if the master was available, using the isAvailable() method in IDE. This worked much better.

Another problem that created a change in our project was connecting to WiFi in order to post data with the Arduino. The issue was that our Arduino WiFi would simply not connect, and it would not allow us to upload code via WiFi. This problem took us several days and lots of hours to solve, and it turned out that the problem had several key parts that we had to solve. The first part of the problem we had to solve was making sure that we had the correct wireless ports on our computer, and that they were not being blocked by the firewall. Having done this, we also had to make sure we could automatically connect to the IP of the Arduino. The final step to connection was using the serial monitor and sketch input through the hostname.local/ portal in to the Arduino.

Once we placed all of our pieces together, we realized that we were way over the data limits. We had 176% usage of the Dynamic data on our Arduino if we were using all the libraries we had to include for Wifi, Twilio (our texting services), the HTTP codes, Bluetooth, and uploading to TeamSpeak. What we ended up doing is running the HTTP codes through TeamSpeak, and cutting out Bluetooth from the entire project. This was a major pain to do after we had invested so much time in Bluetooth, but the cut was necessary to alleviate enough of the memory in order for the WiFi to work. Although we spent hours optimizing the code and trying to use as little memory as possible, we were not able to reincorporate Bluetooth due to memory issues.

Accomplishments that I'm proud of

There were several accomplishments in NSY that our team is quite proud of. The first is that we were able to actually use the product in daily life. During testing, we decided to leave the sensor active, and we were able to know when all my roommates returned at night, as I got text updates when each entered the dorm living room. We did see massive battery drain from our power bank during this, so we moved on to a solution for that, and that is the second part of our project that we were proud of.

We used the Arduino lo energy settings so that we could use almost no energy until the accelerometer sensed movement. This meant that the Arduino barely used any energy unless it was sending out movement data, and since the door is not moving for a much larger amount of time than it is moving, we were able to create a very low energy product, which in our opinion greatly enhances marketability.

What I learned

We learned a lot about the Arduino and applications with this project, but a lot of what we learned we believe applies to further knowledge in the ESE field. Primarily, we saw many limitations, specifically to do with memory, that was composed in the Arduino. We learned how to overcome, and how to plan around such problems so that they will have had as little impact on our final project as possible.

This entire process taught us how important planning was. Having the accelerometer planned out, and how it would work in all our sketches, was great. This is because we knew what we had to incorporate, and what conditions were needed to be met for all of our triggers before we began incorporating what exactly was happening when those conditions were met. This plan meant that we had all of the hardware fully functional before we had to piece it together, and we were not worried at all about patching together already complete pieces. This did mean that when we hit limitations we had to remove work that was already complete, but we were thankful that we had options of what to remove and how.

What's next for NSY™

NSY has several steps that will make it the household security item of the future. Firstly, the members here at NSY are working to implement biometric sensors that will allow those you trust to access the house/room with ease. Then, using the same biometric scanners, we could take data from strangers, and implement in our emails, comparing it with data from our databases, and compiling the possible identity of the visitors.