# Project Proposal

## Group 13
✔ Jakob Aschauer, k12007322
✔ Matthias Heiden, k12104028
✔ Stefan Gabriel, k12008194
✔ Christian Dattinger, k12031039
✔ Mohamad Khabour, k12005283
✔ Victoria Plöckinger, k12108435
✔ Mehmet Tasdemir, k11910284

## Motivation

**Idea behind our project:**

In offices, the air quality is often not ideal for productive working. Therefore, a service, that detects bad air quality and takes suitable actions, may provide an increase in productivity. If the measured air quality is below the threshold value, then the person will be notified and the windows will be opened automatically. Furthermore, a coffee will be prepared, so that the person is forced to take a quick break.
Additionally, the person can open the windows and order the coffee manually through a Web-Interface.
The user can modify the features according to his needs, e.g. no automatic coffee, but still notification for break.

**Why is this important, and how can people benefit from it?**

Poor air quality can cause discomfort, irritations, headaches, and fatigue, which makes it harder to concentrate and work effectively. Our project saves companies a lot of money, by tackling these issues.
Regular breaks help people focus, reduce stress and fatigue, and improve their mental well-being. Additionally, it can make sure that windows are closed at the end of the day (saves money on energy).

**TLDR**:
- Boost productivity
- Increases (mental) health and quality of life
- Reducing waiting time for coffee to get ready
- Air Quality + Coffee machine

**Air Quality is used to detect when you need a break**
- Oxygen/Temperature/Light Sensors
- Suggest a break -> Automatically brew a coffee
- Open window with a servo motor
- Visualize historic data

**Coffee Machine Features:**
- turn on/off
- order small/big coffee
- automatic mug placement under coffee spout
- (optional: displaying the warning messages of machine)

## Approach

**Hardware components:**
- 1 Servo Motor (Window Control)
- 1 Servo Motor (Blinds Control)
- 1 Oxygen/Temperature/Humidity sensor (Air Quality)
- 1 Light sensor (Light amount for control of blinds)
- 1 Speaker (Alert User)
- 3 LEDs (red, orange, green)
- 1 LCD (Alert User,Disply Progress and/or Climate Information)

**Hardware components for coffee machine:**
- Sensor to check whether there's a cup
- 3 motors for the buttons
- 1 motor for placing the cup

### Services

We are planning to use 2 Raspberry Pis which run multiple services. Each of these services can be all run on a single device, or every service can be run on an individual device. We decided to separate the coffee machine logic from the rest, because you might not want to have the coffee machine at the same place where the air quality is measured. In a real world scenario, you would also move the visualization with LEDs and opening of a window to separate devices.


**Storage Service:** Used to store data from sensors and delegate commands.
- Database
- Send commands (e.g. Web Interface wants to turn off opening of the window)
- Receives data from the measuring service

**Measuring:** Uses sensors and send data to storage service. Doesn't do any processing with the data.
- Oxygen
- Temperature
- Humidity
- Light

**Analysis:** Analyzes the data and visualizes it with hardware components.
- LED (Red/Green/Yellow):
- Red: Very bad quality
- Green: Everything is fine.
- Yellow: Average. Not too good and not too bad.
- LCD: Displays captured data / metrics (temperature, ...)
- Predictive analysis (optional, if we have time)

**Mitigation:** Analyzes the air quality (with the data from the storage service) and tries to improve it.
- Open window
- Control fan
- Control blinds

**Web Interface:** Visualizes the data and provides controls.
- Display historic data
- How often a coffee was taken
- Air Quality
- Manually trigger features (brew coffee)
- Configuration
- Enable/Disable features
- Prepare coffee

**Coffee Machine:**
- Detect if a cup is already in place
- Press the right button to brew a coffee

## Implementation Details

**Protocols involved**:
- **MQTT**: Used for services that need real-time data (analysis, mitigation, website services).
- **Protobuf**: Serialization data format which supports many different languages. This allows us to use different languages, without having to convert the data between different formats.
- **REST:** Used to create/read/update/delete data from the storage service (e.g. measuring service sends data with this to the storage service)

**Tech Stack for the Services**:
- Storage (Matthias): Rust, [SurrealDB](https://surrealdb.com/),
- Measuring (Vicky): Python
- Analysis (Stefan): Python, Pandas, matplotlib
- Mitigation (Mohamad): Python
- Web Interface (Jakob): Vue, Typescript, [Highcharts](https://github.com/highcharts/highcharts-vue)
- Coffee Machine (Mehmet, Christian): Python,

**Docker/Docker-compose:** Used for easy deployment of services. Allows us to just run the services, without having to install dependencies and worry about version conflicts.
**Github:** Code will be hosted on Github for easy collaboration and project management.

## Verification

**Mock Data:** We can replace the Measuring Service with a script that produces mock data for testing purposes. The Storage Service and all following services that get data from it should behave exactly the same.

**Unit Tests:** To ensure correctness and prevent bug, we'll use tests to make sure our code does what it's supposed to do. This is useful for the services that analyze data, because there might be edge cases that are only hit in very special scenarios, making these kinds of bugs hard to reproduce. Because of our service-based design, we can easily test individual services ensuring maximum correctness.