No Stocks Left Behind

Customized real-time stock portfolio alerts on your wrist so that you never miss a stock rise or drop again! Whether you are a stock enthusiast or professional, this is a wearable you can't miss.

Comment

Inspiration

Wearables are a hot market valued at $115.8 billion in 2021, providing tons of real-time physical health data to its users. But does a wearable exist that enables you to improve your financial and mental wellbeing? In an age where one's mental health is strongly tied to one's financial health (a Money and Mental Health survey showed that 86% of participants with mental health problems said their financial situation made their mental health worse), by providing valuable information on one's stock porfolio's performance in real-time, we enable users to leverage this newfound data to look after themselves and manage their finances.

What it does

The stock-monitoring wearable alerts the user when the price of a stock falls or rises outside of a threshold within a time interval using a colorful LCD screen and buzzer tune. Users can use a web interface to configure the stocks to track, as well as the time interval and threshold for each stock.

How we built it

The frontend was built using ReactJS, and we used Axios as an HTTP client to communicate with our Flask backend written in Python. The Flask backend spawns a process for monitoring each stock using the yfinance library, and adds/updates/terminates processes based on user requests received from the frontend. When a thread detects that a stock price has risen or fallen outside of the user-set threshold, it publishes an MQTT message under a topic specific to the user's device ID, which will be queued and received by the wearable device. We also used AWS DynamoDB for storing user account metadata and the stocks/tracking settings for each user. System Diagram

Challenges we ran into

  • MQTT with Python multiprocessing and Flask. We wanted to interface the wearable with a web app to be more accessible, so we figured that the best way to communicate with the wearable was through MQTT. However, to be able to monitor multiple stocks for different users at customized settings, we needed to dynamically launch Python multiprocesses, and had some difficulty with getting MQTT to work with this system initially.
  • Finding compatible hardware and libraries for the wearable. We needed a WiFi compatible board to be able to send and receive messages, and initially tried several options including the SparkCores available at the hardware desk. Due to connection and compatibility issues, we ended up migrating to an ESP32 microcontroller, but it didn't support the uLCD library for the 128x128 color LCD we had. As a result, we rented out the one and only LCD screen available at the hardware desk, but unfortunately couldn't find a compatible connector. Luckily, we were able crimp our own wires for the molex terminal at the Hive (after a few failed attempts).
  • Async/Await JavaScript functions. We had some problems working with async/await JS functions in the frontend, as the default event was being triggered unknowingly, causing some weird behavior. After lots of troubleshooting, we were able to resolve the issue.
  • Connecting to AWS. We also initially had difficulty figuring out how to use the boto3 Python API for database CRUD operations.

Accomplishments that we're proud of

We are proud of being able to complete a truly full-stack application within 36 hours. Not only did we develop the frontend and backend of the web app, but we also configured cloud resources in AWS, wrote firmware, and put together the hardware for the wearable. It was pretty cool to see how we individually worked on different parts and were able to merge our work into a cohesive project.

We are also proud of the approach we used to send data and update the wearable's state. Initially, we were going to have a background Python script that monitors all stocks in an infinite loop, but we realized that this approach has many limitations. For example, the user wouldn't be able to customize the refresh rate (how often each stock is checked), and it requires the script to do a full scan of the database in each loop iteration (super costly and slow). As a result, we used a different approach that spawns/updates threads from the Flask backend for monitoring each stock. Updates to the threads can be triggered from requests from the frontend, since those are the only times that alert settings are changed. This webhook-like model avoids having to constantly scan the database.

What we learned

  • When creating a full-stack application, planning and then building significantly reduces bugs during integration. We spent the first evening fully brainstorming and writing mock programs, but we were very pleased and surprised when our microcontroller-backend-frontend were able to communicate stock prices successfully during our first attempt at integration.
  • Our team came together each from a very diverse background; even though some of us individually had experience with a specific technology (e.g. AWS, React), when we needed to put everything together, we understood each others' domains of knowledge better.
  • Understand when a blockage cannot be resolved, and pivot fast. We had a plan about the electrical system of the wearable, but understanding that we were handicapped to a particular microcontroller and LCD screen meant we needed to search out connectors and libraries ASAP. Knowing that the common threading library in Python would not meet our requirements of dynamic thread scheduling meant that we need to find and integrate a more complex library in multiprocessing.

What's next for No Stocks Left Behind

  • Prove AWS auto-scaling works with multiple users/devices
  • Market the product as SaaS (Software as a Service) to integrate with existing wearables instead of BYO hardware.
  • Change MQTT port to secure-TCP instead of unsecure to provide MQTT message spoofing by a fake client. Provide a handshake protocol and CRC for data integrity.
  • Protect against invalid user input in the frontend as to not crash Yahoo-Finance or DynamoDB queries.
  • For hardware improvements (in the absence of conversion to SaaS), we would use a haptics motor instead of piezo buzzer; this is more discrete and generally how wearables notify their users. We would also reduce the form factor and provide an on-board rechargeable battery instead of using a wired power supply.
Share this project:

Updates