## Inspiration

Our team was inspired to work on this project mainly due to two reasons:

1. As a Google Home owner, I regularly use voice-commands to control my smart home devices such as my Philips Hue lights and Wemo Smart Plugs. However, one Saturday morning, after a night of alcohol and karaoke, I opened my mouth in an attempt to turn on the lights, but the only sounds that came out of my mouth were “hey ggg...gg…, t…the...lights”. I’ve lost my voice, and along with it, my ability to turn on the lights! And then another thought hit me: how can the 18 million US adults (8% of the US population) who had suffered from voice problems in 2015, or the other billions of people who don't speak the language or have speech impairments, turn on and off their lights? Bam! An idea was born.
2. After experimenting with its capabilities and data output, our team immediately decided to create a hardware-integrated hack involving the Myo Armband. As a team of 4 mechanical engineers and 1 programmer, it was clear from the beginning that our best chances of success would be a hardware hack with either a web or mobile app GUI.

## What it does

Using the **Myo Armband**, users can control their smart home devices such as lights and fans at the flick of their wrist and arm. Based on how many devices there are, users can use the **MyoHome web app** to configure the gestures for each device, and save those customized gestures to a user profile. Although there are only 5 basic gestures built in to the **Myo Connect** app, there are essentially an infinite number of gestures that could be configured based on the raw data output from the **accelerometer**, **EMG sensors**, and **gyroscope**.

## How we built it

At first, we performed diagnostic tests to determine the accuracy, range, and capabilities of the Myo Armband through Myo Connect to get a feel of the range of motions and the capabilities of this armband. We then split into sub-teams to tackle the different challenges, including: **website and interface design, electronics control, mock house model design, and demo/presentation strategy**. Finally it all came back together with our completed prototype that shows how the Myo armband can truly be integrated into our lives and enable everyone - whether you’re mute or having speech difficulties - to fully enjoy smart home technologies.

## Challenges we ran into

* Designing a C++ application that could smoothly and efficiently bind to Myo’s C++ bindings

## Accomplishments that I'm proud of

* Prepared a powerful presentation of our proof-of-concept demonstration with our beautifully-built home
* Developed gesture combinations that are not native to the Myo SDK based on sensors data

## What we learned

* How to control hardware using a Myo Armband and Arduino

## What's next for MyoHome

Due to time constraint, the MyoHome app currently only works with hacked arduino-enabled LEDs and motors. The natural progression of this project would be towards enabling integration with smart home products and apps currently on the market from tech giants like Google and Samsung, as well as from other companies like Philips, TP-Link, and Wemo.
## Inspiration

With COVID-19, the world has been forced to stay safe inside their homes and avoid social contact, a measure which has taken a noticeable toll on everyone’s mental well being. With All of the Lights, individuals can connect in new and fun ways with products that they likely already own - RGB light strips.

## What it does

All of the Lights is a web-enabled LED strip control system. It allows friends to synchronize their lights and remotely participate in each other's lives.

**Note:** The devices made for this project use only a short LED strip as proof of concept. In real use, the device would be mounted with the user's LED strip that typically runs around the perimeter of their ceiling, controlling the lights for an entire room.

Users access our web app to choose a different light pattern depending on whether they want to study together, party, or just chill. Each All of the Lights device is updated with the new pattern, immediately changing everyone's lights.

All of the Lights has several different modes or patterns, including:

* White Light (On or Off)
* Slow colour fading for vibing
* Fast colour jumping for parties
* Custom colour patterns (such as Blue-Orange fading)
* Pomodoro Study Mode
With the Pomodoro Study Mode, users can use their LED lights as a way to boost their productivity by changing colour when they should take a break from studying, then returning to the original colour to notify the user to resume studying.

## How we built it

All of the Lights is primarily a hardware hack. We began with a rough device circuit diagram to determine the necessary components and used CAD to design a enclosure to be 3D printed. While waiting for the prints, we split up to work on the two major components: creating a circuit to control high-power LEDs and interfacing between Raspberry Pi's to synchronize the devices.

The control circuit uses an ATtiny84 microcontroller to drive 3 MOSFET transistors which adjust the brightness of each 12V RGB channel. This utilizes Pulse Width Modulation (PWM) to access the entire range of colour values. To control the light patterns, the Raspberry Pi sends a 32 bit serial packet to the ATtiny. This packet contains the red, green, and blue values, as well as information about whether the colours should fade or not and the duration of the current pattern element. Using a system inspired by floating point integers, an accurate duration between 10 milliseconds and 3 hours can be specified using just 9 bits.

All of the Lights supports several nodes in the local network using Python threading and sockets combined with Flask to submit GET requests from the localhost. One Raspberry Pi is used as the server node, which retrieves a string from the Flask server containing information about desired light pattern. The server Pi supports multiple client Pi’s to join its network and updates each with the pattern data upon a new POST to the server. The clients and the server all send a serial message to the ATTiny on the LED driver board to change the light colours.

## Challenges we ran into

With the tight time constraints of this Hackathon, waiting for 3D prints to finish could be the difference between complete a product and not. To avoid this, we had to design our 3D printed case before having a concrete list of parts that would be enclosed. This required making intelligent design decisions to estimate how parts would eventually fit together in the case, without being too tight or oversized.

The serial communication between the Raspberry Pi web client and ATtiny LED driver board was made difficult by the different logic levels of the two devices. A voltage step-up circuit was needed to convert the 3.3V serial output from the Pi to a 5V serial input for the ATtiny. This required several prototype circuits that tried using diodes or MOSFETs, but the finally solution uses a double bipolar transistor inverter to accomplish the step up.

With the current system, one of the All of the Lights devices acts as both a client to the web app and a server to the other devices. This means that it must simultaneously fetch data from the web app, relay this information to each client, and control its own LEDs via serial. Organizing all of these concurrent tasks required lots of integration testing to get right.

## Accomplishments that we're proud of

We focused heavily on modularizing both the hardware and software components of this project to facilitate future development. This was a rewarding endeavour as we got to see all of the modules, such as the LED driver board, power circuit and LED strip being seamlessly integrated.

As a project that required many interactions between hardware and software, there were many challenges and bugs during the Hackathon. However, after finally fixing all of the issues, it was a great accomplishment to see a physical, real world device behaving exactly as we had designed, even if that meant pulling an all-nighter to see it work at 7:30am! We are especially excited about this device since we intend on further developing All of the Lights for us and friends to use.

## What we learned

One of the main features of this project is the various device interactions. We learned how to use sockets to interface between Raspberry Pi's, how to collect information from a web server with Flask, and how to communicate over serial between devices with different logic levels.

We also improved our engineering soft skills, primarily teamwork and communication. Throughout the competition, our team members frequently discussed the objective of each component of the project, allowing us to work in parallel and design hardware or code that would be relatively easy to integrate later on.

## What's next for All of the Lights

With all of the technical groundwork complete, All of the Lights possessed the necessary hardware and software requirements to expand out and create more intricate and useful LED patterns. The localhost server is a crucial aspect to the build, and currently allows people of the same household to connect to and control the lights from any browser. The server will eventually be deployed to the web, allowing people to connect their lights from anywhere in the world. Additionally, All of the Lights will allow users to use the Spotify API to synchronize music on a device with their LED lights. Finally, more productivity features will be implemented to allow users to structure their day. All of the Lights will launch a custom alarm setting, and let users be naturally woken with lights simulating the sunrise. Thanks to its modular design, launching custom settings on a device has never been easier!
## Inspiration

**75% of adults over the age of 50** take prescription medication on a regular basis. Of these people, **over half** do not take their medication as prescribed - either taking them too early (causing toxic effects) or taking them too late (non-therapeutic). This type of medication non-adherence causes adverse drug reactions which is costing the Canadian government over **$8 billion** in hospitalization fees every year. Further, the current process of prescription between physicians and patients is extremely time-consuming and lacks transparency and accountability. There's a huge opportunity for a product to help facilitate the **medication adherence and refill process** between these two parties to not only reduce the effects of non-adherence but also to help save tremendous amounts of tax-paying dollars.

## What it does

**EZPill** is a platform that consists of a **web application** (for physicians) and a **mobile app** (for patients). Doctors first create a prescription in the web app by filling in information including the medication name and indications such as dosage quantity, dosage timing, total quantity, etc. This prescription generates a unique prescription ID and is translated into a QR code that practitioners can print and attach to their physical prescriptions. The patient then has two choices: 1) to either create an account on **EZPill** and scan the QR code (which automatically loads all prescription data to their account and connects with the web app), or 2) choose to not use EZPill (prescription will not be tied to the patient). This choice of data assignment method not only provides a mechanism for easy onboarding to **EZPill**, but makes sure that the privacy of the patients’ data is not compromised by not tying the prescription data to any patient **UNTIL** the patient consents by scanning the QR code and agreeing to the terms and conditions.

Once the patient has signed up, the mobile app acts as a simple **tracking tool** while the medicines are consumed, but also serves as a quick **communication tool** to quickly reach physicians to either request a refill or to schedule the next check-up once all the medication has been consumed.

## How we built it

We split our team into 4 roles: API, Mobile, Web, and UI/UX Design.

* **API**: A Golang Web Server on an Alpine Linux Docker image. The Docker image is built from a laptop and pushed to DockerHub; our **Azure App Service** deployment can then pull it and update the deployment. This process was automated with use of Makefiles and the **Azure** (az) **CLI** (Command Line Interface). The db implementation is a wrapper around MongoDB (**Azure CosmosDB**).
* **Mobile Client**: A client targeted exclusively at patients, written in swift for iOS.
* **Web Client**: A client targeted exclusively at healthcare providers, written in HTML & JavaScript. The Web Client is also hosted on **Azure**.
* **UI/UX Design**: Userflow was first mapped with the entire team's input. The wireframes were then created using Adobe XD in parallel with development, and the icons were vectorized using Gravit Designer to build a custom assets inventory.

## Challenges we ran into

* Using AJAX to build dynamically rendering websites

## Accomplishments that we're proud of

* Built an efficient privacy-conscious QR sign-up flow
* Wrote a custom MongoDB driver in Go to use Azure's CosmosDB
* Recognized the needs of our two customers and tailored the delivery of the platform to their needs

## What we learned

* We learned the concept of "Collections" and "Documents" in the Mongo(NoSQL)DB

## What's next for EZPill

There are a few startups in Toronto (such as MedMe, Livi, etc.) that are trying to solve this same problem through a pure hardware solution using a physical pill dispenser. We hope to **collaborate** with them by providing the software solution in addition to their hardware solution to create a more **complete product**.