DontComeIn | Devpost

Track

Track - General

Inspiration

Living with roomates can be hard. It can be especially hard when you need the room to yourself for something - be it an important meeting, consoling a friend, or getting hot and heavy ;). You wouldn't want your roomates to just walk in during the middle of something important to you. You also wouldn't want them to noisily barge in the room and turn on the lights when you're doing something sensitive like sleeping. We have long felt the need to convey messages to roomates for these things.

Most people send messages to their roomates to convey this information. However, we've found:

Roomates may not check their phones.
There's usually not information about how long you'll need the room.
A message is not convincing enough and causes annoyance.

In addition to room privacy among roommates, we also found that, in our first semesters as freshmen, there isn't really an effective method for communicating dorm parties and other social events. This problem inspires the "Come In" feature of the app.

What it does

To address this problem, we've a created a device for people to stick on their doors, which can convey the state of the person using the room. We've also created an app alongside this device to control it and recieve updates from roomates.

The device is an ESP32 with an RGB Led connected. Once you pair with the device from the cross platform mobile application, you'll be able to set the state of the device. You'll also be able to add your roomates to the device, and they'll control it as well. Your roomates will get notified when you start an activity, and this activity will be reflected by the color of the LED on the device, which is attached to the door. Here, the two barriers to room entry are the push notification and the physical state of the LED, where previously there was just a (probably ignored) message.

The mobile app acts as a remote for the device and as a social networking platform for advertising dorm events. When a user changes the room's state, it notifies their roommates of the state change. Additionally, when a user changes the room's state to a "Come In" state, the backend notifies all of the user's friends and puts the room in a discoverable mode.

How we built it

Architecture

We used the Arduino framework to run software on the ESP32. The ESP32 communicated via Bluetooth Low Energy as a peripherial to the phones, which would write state to a bluetooth characteristic representing the state of the room. The bluetooth characteristic stored the RGB values of the LED, along with an expiry time for when the state ends.

The mobile app uses the Flutter framework to enable cross-platform development. We abstracted the basic UI components of most apps (Scaffolds, Buttons, TextFields, page transitions etc.) and wrote them in their native styles (Material/Cupertino).

For our backend, we used Google Cloud Functions, which are serverless runtimes that enabled quick iteration and development. The six functions we had were:

createUser
deleteUer
createRoom
shareRoom
notifyState
addFriends

The mobile app queried these functions to reflect state to the backend and to the other mobile devices. We used Firebase Cloud Messaging to send push notifcations to the mobile devices.

As for our database, we used Firebase Firestore, which is a JSON document database. Our app either directly queried this database, or used HTTP functions as a proxy.

Challenges we ran into

Firmware

The ESP32's default advertisement protocol is not visible on IoS. We had to set custom connection options with bluetooth GATT, and keepalive timeouts to actually hold the connections.
The connection would randomly drop after a certain sequence of events was written to our characteristic, so we had to filter by those events and drop those packets so our entire connection did not drop.

Mobile

Apple does not allow for push notifications to be sent (even for developement) for free -- you have to pay $100 to get an APN. We realized this pretty late into our development, so we had to pivot and start testing on androids, where we were previously only testing on iPhones. Good thing we were using flutter - being cross-platform saved us.

Backend

Firestore just crashes if you ever write a null value to any document, and doesn't really give you any relevant error messages, so we had to debug that for a while.