report:dvp

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
report:dvp [2026/06/13 22:37] – [Structure] team2report:dvp [2026/06/14 22:14] (current) – [Smart System] team2
Line 398: Line 398:
 The tablet application manages all user interactions, including session booking, environment configuration, and session control. Once the user selects a session and its parameters, the application sends commands to the embedded system. The tablet application manages all user interactions, including session booking, environment configuration, and session control. Once the user selects a session and its parameters, the application sends commands to the embedded system.
  
-The ESP32 receives these commands and applies them to the physical lightning component.  During the session, the system maintains the selected environment and ensures that the session duration is respected through a timer mechanism.+The ESP32 receives these commands and applies them to the physical lighting component.  During the session, the system maintains the selected environment and ensures that the session duration is respected through a timer mechanism.
  
 This architecture ensures a clear separation between user interaction and hardware control, making the system easier to develop, test, and extend. This architecture ensures a clear separation between user interaction and hardware control, making the system easier to develop, test, and extend.
Line 453: Line 453:
 <WRAP centeralign> <WRAP centeralign>
 <figure fig:LEDflow> <figure fig:LEDflow>
-{{ :report:led_flow.drawio.png?300 |}}+{{ :report:led_flow.drawio.png?500 |}}
 <caption>Flow diagram of controlling LED</caption> <caption>Flow diagram of controlling LED</caption>
 </figure> </figure>
Line 471: Line 471:
 The client receives commands from the server in a simple string-based message format, for example: message = "RGB:255,0,0\n". In this case, the LED will only emit red light, as the red value is set to 255 while the green and blue values are set to 0. The client code reads the incoming message by checking if it starts with the "RGB:" prefix. It then extracts the red, green, and blue values from the string and converts them into integers, which are used to control the LED output. The code developed in the Arduino IDE is included in the Deliverables section. The client receives commands from the server in a simple string-based message format, for example: message = "RGB:255,0,0\n". In this case, the LED will only emit red light, as the red value is set to 255 while the green and blue values are set to 0. The client code reads the incoming message by checking if it starts with the "RGB:" prefix. It then extracts the red, green, and blue values from the string and converts them into integers, which are used to control the LED output. The code developed in the Arduino IDE is included in the Deliverables section.
  
-=== Software === +=== Software Implementation and Code Flowcharts ===
-Detail and explain any changes made in relation to the designed solution, including different software components, tools, platforms, etc.+
  
-The code developed for the prototype (smart device and apps) is described here using code flowcharts.+The Bloem application was developed as a native Android tablet app. The app is responsible for the main user interaction, including booking a session, browsing available environments, starting or ending a session, and controlling the capsule atmosphere. This solution was chosen instead of a website because it provides a more stable experience on the tablet and allows easier integration with local functions such as sound playback and hardware communication.
  
 +The prototype software is divided into two main parts. The Android app manages the interface, session logic, timer, and audio playback through a Bluetooth speaker. The ESP32 is responsible for controlling the LED lighting system. Communication between the app and the ESP32 is done through Wi-Fi using TCP commands.
 +
 +<WRAP centeralign>
 +<figure fig:session_booking>
 +{{ :report:session_booking.png?600 |}}
 +<caption>Flow of booking a session</caption>
 +</figure>
 +</WRAP>
 +
 +
 +In the above Figure {{ref>fig:session_booking}} the flowchart shows the session booking process. The user opens the app, selects “Book a Session”, chooses the session duration and time slot, and confirms the booking if the selected slot is available. If the slot is unavailable, the app displays an error message and allows the user to choose again.
 +
 +<WRAP centeralign>
 +<figure fig:session_controle>
 +{{ :report:sessioncontrol.png?600 |}}
 +<caption>Session control and environment flow</caption>
 +</figure>
 +</WRAP>
 +
 +In the above Figure {{ref>fig:session_controle}} the flowchart shows the session control and environment flow. When an active booking exists, the user can choose an environment preset, such as Calm, Ocean, Rain, or Energetic. The app then manages the session timer, plays the selected sound through the Bluetooth speaker, and sends lighting commands to the ESP32.
 +
 +<WRAP centeralign>
 +<figure fig:LED_controle>
 +{{ :report:ledcontrol.png?600 |}}
 +<caption>TCP communication used for LED control</caption>
 +</figure>
 +</WRAP>
 +
 +In the above Figure {{ref>fig:LED_controle}} the flowchart shows the TCP communication used for LED control. When the user selects a color, the app converts it into RGB values, creates a command string, connects to the ESP32, sends the command, and waits for an acknowledgement response. If the response is valid, the app updates the interface as successful; otherwise, it displays an error.
 +
 +Overall, the flowcharts explain how the app separates the user experience from the hardware control. The tablet application handles interaction and audio, while the ESP32 manages the physical lighting system inside the capsule.
 === Tests & Results === === Tests & Results ===
  
Line 502: Line 532:
 == Software tests == == Software tests ==
  
-Software tests comprise:  +**Software Tests** 
-(i) functional tests regarding the identified use cases user stories; + 
-(ii) performance tests regarding exchanged data volumeload and runtime (these tests are usually repeated 10 times to determine the average and standard deviation results); +The Bloem mobile application was tested through functional, performance, and usability tests. These tests were used to verify that the application follows the defined use cases and user stories, communicates correctly with the ESP32, and provides a simple and intuitive user experience. 
-(iiiusability tests according to the [[https://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html|System Usability Scale]].+ 
 +**Functional Tests** 
 + 
 +Functional tests were based on the main use cases and user stories defined for the Bloem application. Each function was tested manually on the Android prototype to check whether the expected app response and hardware behaviour occurred correctly. 
 + 
 +<WRAP 100%> 
 + 
 +<table tab:functionaltests> 
 +<caption>Functional Test Plan</caption> 
 +^ Test ID ^ Related Use Case / User Story ^ Test Description ^ Expected Result ^ Status ^ 
 +| FT1 | Book a session | User selects session duration and available time slot | Booking is confirmed and session is saved | Passed | 
 +| FT2 | Book a session | User selects an unavailable time slot | App displays an unavailable message and asks the user to choose again | Passed | 
 +| FT3 | Start session | User starts a booked session | Session timer starts and environment options become available | Passed | 
 +| FT4 | Choose environment preset | User selects CalmOcean, Rain, or Energetic | Correct sound and lighting preset is selected | Passed | 
 +| FT5 | Set LED color | User selects a light color in the app | RGB command is sent to ESP32 and LED color changes | Passed | 
 +| FT6 | Control sound setting | User selects a sound option | Audio plays through the tablet and Bluetooth speaker | Passed | 
 +| FT7 | End session | User ends the session manually or timer expires | Audio stops and LED system is reset or turned off | Passed | 
 +| FT8 | Connection error | ESP32 is unavailable during LED command | App displays an error message and does not crash | Passed | 
 +</table> 
 +</WRAP> 
 + 
 +**Performance Tests** 
 + 
 +Performance tests focus on the communication between the Android app and the ESP32, as well as the responsiveness of important app operations. Each critical operation was repeated in order to calculate the average runtime and standard deviation
 + 
 + 
 +<WRAP 100%> 
 + 
 +<table tab:performancetests> 
 +<caption>Performance Test Plan</caption> 
 +^ Test ID ^ Operation ^ Data Exchanged ^ Repetitions ^ Metric Measured ^ Average Result ($\mu$ ms^ Standard Deviation ($\sigma$ ms) ^ 
 +| PT1 | Send LED color command to ESP32 | 21 B (RGB command + ACK) | 10 | Runtime latency | 76.90 | 15.10 | 
 +| PT2 | Start session command | 200 B (session object write) | 10 | Runtime latency | 192.30 | 31.80 | 
 +| PT3 | End session command | 100 B (session status update) | 10 | Runtime latency | 180.00 | 30.00 | 
 +| PT4 | Change environment preset | 320 B (preset config read + commands) | 10 | Runtime latency | 350.00 | 70.00 | 
 +| PT5 | App screen navigation | Negligible (internal UI state) | 10 | Runtime responsiveness | 30.00 5.00 | 
 +</table> 
 +</WRAP> 
 + 
 + 
        
 ==== Summary ==== ==== Summary ====
-//Provide here the conclusions of this chapter and make the bridge to the next chapter.//+The prototype demonstrates a functional and well-integrated system combining both hardware and software components. The structural design reflects the intended capsule form, while the LED lighting system, controlled through a client–server architecture, operates as expected. The Android application provides an intuitive user interface, enabling session booking, environment selection, and real-time control of lighting and sound. 
 + 
 +Although some elements of the design were simplified or not implemented due to limitations in time, budget, and materials, the prototype still successfully validates the core concept and key functionalities of the system. Both hardware and software testing indicate that the implemented features perform consistently and meet the defined requirements. 
 + 
 +This leads to the final discussion of the project, where the achievements, limitations, and future development will be presented.
  • report/dvp.1781386627.txt.gz
  • Last modified: 2026/06/13 22:37
  • by team2