Differences
This shows you the differences between two versions of the page.
|
iothings:proiecte:2022:automated_studio [2023/06/15 00:45] madalina.boboc [Introduction] |
iothings:proiecte:2022:automated_studio [2023/06/15 13:03] (current) madalina.boboc [Implementation] |
||
|---|---|---|---|
| Line 5: | Line 5: | ||
| * Master: AAC | * Master: AAC | ||
| * Source code: [[https://github.com/mboboc/iStudio]] | * Source code: [[https://github.com/mboboc/iStudio]] | ||
| + | * Demo video: https://youtu.be/uS9y84kDzKQ | ||
| ==== Introduction ==== | ==== Introduction ==== | ||
| Line 11: | Line 12: | ||
| - | **Problem statement** | + | ==== Problem statement ==== |
| A person who owns a space and wants to monetize it has to invest time and resources in managing it. This might include activities like scheduling the appointments, access and reception of clients, managing infotainment of the studio and assure the space is well-maintained and clean. In other words the owner needs to invest: | A person who owns a space and wants to monetize it has to invest time and resources in managing it. This might include activities like scheduling the appointments, access and reception of clients, managing infotainment of the studio and assure the space is well-maintained and clean. In other words the owner needs to invest: | ||
| Line 22: | Line 23: | ||
| * cleaning | * cleaning | ||
| - | **Proposed solution** | + | ==== Proposed solution ==== |
| The suggested solution is an ecosystem composed of several modules that are meant to function together in order automate the workflow of an appointment. The architecture is separated in 5 modules: access control and check-in, infotainment, cloud, application and cleaning. Each module tackle a certain task. For reservations and check-in, the straightforward approach is to create a web application. The users authenticate inside the app, book an interval and then receive a QR for access. The booking table is safely stored on a cloud server and is accessible by any user that has the application. The QR code is used later for both studio access and check-in. After successfully scanning the code, the user is authenticated inside the studio via the cloud communication and has access to the studio infotainment. | The suggested solution is an ecosystem composed of several modules that are meant to function together in order automate the workflow of an appointment. The architecture is separated in 5 modules: access control and check-in, infotainment, cloud, application and cleaning. Each module tackle a certain task. For reservations and check-in, the straightforward approach is to create a web application. The users authenticate inside the app, book an interval and then receive a QR for access. The booking table is safely stored on a cloud server and is accessible by any user that has the application. The QR code is used later for both studio access and check-in. After successfully scanning the code, the user is authenticated inside the studio via the cloud communication and has access to the studio infotainment. | ||
| Line 35: | Line 36: | ||
| The complexity of the system necessitates a phased approach, thus the objective of this project is to develop a Minimum Viable Product (MVP) that incorporates the access control and the check-in module. | The complexity of the system necessitates a phased approach, thus the objective of this project is to develop a Minimum Viable Product (MVP) that incorporates the access control and the check-in module. | ||
| - | **Workflow** | + | ==== Workflow ==== |
| The user interacts with the website and creates an appointments. The platform generates a QR code and sends it to the user by email. The data of the appointment is kept in the firebase database and it’s accessible by the lock module of the studio. The lock in this case is represented by the ESP32-CAM module. When the user arrives at the location and scans the QR code, the lock module checks if the scheduled appointed matches the time and the QR code provided and opens the door. The user is allowed to enter the room. | The user interacts with the website and creates an appointments. The platform generates a QR code and sends it to the user by email. The data of the appointment is kept in the firebase database and it’s accessible by the lock module of the studio. The lock in this case is represented by the ESP32-CAM module. When the user arrives at the location and scans the QR code, the lock module checks if the scheduled appointed matches the time and the QR code provided and opens the door. The user is allowed to enter the room. | ||
| Line 46: | Line 47: | ||
| \\ | \\ | ||
| - | **Implementation** | + | ==== Implementation ==== |
| //Hardware// | //Hardware// | ||
| Line 90: | Line 91: | ||
| * [[https://drive.google.com/file/d/151IeY4q_suLt7SAYGVkuXzN0IbmFm5n2/view?usp=sharing|Code]] | * [[https://drive.google.com/file/d/151IeY4q_suLt7SAYGVkuXzN0IbmFm5n2/view?usp=sharing|Code]] | ||
| - | * [[ #|Demo]] | + | * [[https://youtu.be/uS9y84kDzKQ|Demo]] |
| - | **Future work** | + | ==== Future work ==== |
| There are multiple improvements that can be done to the system but some future steps would be: | There are multiple improvements that can be done to the system but some future steps would be: | ||
| Line 100: | Line 101: | ||
| * move the website to dedicated server | * move the website to dedicated server | ||
| - | **References** | + | ==== References ==== |
| * [[https://randomnerdtutorials.com/esp32-firebase-realtime-database/ | Firebase for ESP32 ]] | * [[https://randomnerdtutorials.com/esp32-firebase-realtime-database/ | Firebase for ESP32 ]] | ||
| * [[https://www.makeuseof.com/scanning-qr-codes-with-esp32-cam/ | QR scan for ESP32 ]] | * [[https://www.makeuseof.com/scanning-qr-codes-with-esp32-cam/ | QR scan for ESP32 ]] | ||
| * [[https://github.com/PaulStoffregen/Time | Arduino Time Library ]] | * [[https://github.com/PaulStoffregen/Time | Arduino Time Library ]] | ||
| - | |||
| - | |||
