Skip to content

Repositório com o projeto final para a Cadeira de Introdução à Engenharia de Software UA 2023/24

Notifications You must be signed in to change notification settings

zegameiro/IES_MySweetHome_G2

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

My Sweet Home

Our repository for the project of the IES class of 2023/2024 in UA

 

All Contributors PRs Welcome PRs Welcome

Description

My Sweet Home
Home Automation Management System

  • Our aim with My Sweet Home is to develop a system where a user can associate input devices in his house to certain actions.
  • This project involves several receivers (inputs, such as thermostats, daylight-sensors, biometric-sensors, etc...) to be associated to output actions defined by the user and executed by a set of output devices.
  • The actions would be tailor made for each specific user and would need to verify if, for example, a user's action would interfere with another user's preference, like if a user turns on music at 11:00h but another user which we know is inside the same house doesn't want to be bothered by music until later.
  • One example of a simple task would be to close the windows if the temperature got too cold for the specification of the users inside the house, or to turn pass the music streaming of a user's phone to the house's speakers after he arrives home.
  • In the front-end we would be able to set these acttion-reaction pairs.

Architecture Diagram

How to run

Our production environment is up and running most of the time at http://deti-ies-17.ua.pt ( you will need to be inside UA's network or with VPN for this to work )

If you wanna run the project locally, clone the main branch and do the following:

cd proj
docker compose up

You will need to have your localhost tcp port 3000 free for this to work or you may change this port in the MSH-frontend dockerfile.

Then, simply navigate to localhost:3000 to access the front-end application.

Docker implementation

The project will run in a 4 container setup, all connected via a predefined set of ports and all managed by a single docker compose implementation. The containers used are as follows:

  • Message Broker container: RabbitMQ runs on ports 5672 and 15672

  • Database container: MongoDB runs on port 27017;

  • Backend container: The Spring Boot API runs on port 8080 along with some default sensors;

  • Frontend container: React + Vite runs on port 3000 and the NGINX server proxy runs on port 80;

API Documentation

You can acess our api documentation while running the project locally:
- http://localhost:8080/swagger-ui/index.html

Or when the production environment is running:
- http://deti-ies-17:8080/swagger-ui/index.html

Sensor integration

One of the principles for this project is making sensor integration as simple as possible, with very few hard coded parts. For this purpose, the communication between sensors and the relevant back-end processes are entirely made through RabbitMQ messages. This allows our final sensor integration to be language agnostic and for all makes of sensors to be able to communicate to our service, as long as the sensor is capable of throwing out RabbitMQ messages.

Our default back-end comes with some extra java classes inside that are created on spring bootup and act just like regular sensors, to make sure we always have some running.

To integrate outside sensors, we first need to send a register message to the RabbitMQ queue. All messages should be sent to the "sensor_queue" queue, with an empty "exchange" parameter and "sensor_queue" as the routing key, and all message contents must be in s JSON string format. The register message should have the following fields:

{
    "register_msg": "1",
    "device_id": -device_UUID-, 
    "device_category": -category_integer-, 
    "device_name": -external_device_name-
    "reading_type": -information_description-
}

Example:

{
    "register_msg": "1",
    "device_id": generateUUID(), 
    "device_category": 1, 
    "device_name": "Electricity Monitor"
    "reading_type": "Eletricity Usage"
}

After the register message is sent, we can send as much data messages as we want, as long as these fields are present:

{
    "device_id": -device_uuid-, 
    "timestamp": -EPOCH_integer-, 
    "sensor_information": -double_value-, 
    "unit": -string_unit-
}

Example:

{
    "device_id": self.uuid, 
    "timestamp": 1702750526, 
    "sensor_information": 0.2163785, 
    "unit": "Kwh"
}

The back-end is responsible for sensor handling in case of communication loss with the sensors and only provides real values to the front-end.

Bookmarks

Github repository

Project Specification Report

Github Project

Figma Mockup

Figma Prototype

Our Team ✨

Ramos
Pedro Ramos
107348

Architect
💻 ⚠️ 🔧
Madureira
Daniel Madureira
107603

Team Manager
💻🎨🔧
Gameiro
José Gameiro
108840

DevOps Master
💻📝🔧
Aguiar
Rodrigo Aguiar
108969

Product Owner
💻🔀🔧

About

Repositório com o projeto final para a Cadeira de Introdução à Engenharia de Software UA 2023/24

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 4

  •  
  •  
  •  
  •