This chapter outlines the project's evolution, beginning with the initial ideation phase for both the team and the product. After establishing the core concept, including its physical structure, smart systems, and packaging, the focus shifts to the prototyping stage. Here, we detail the key hardware and software adjustments made to the original design, concluding with an analysis of the test results and final performance.

The first Ideation of the team idea can be found in Figure 1.

Here the team already had the idea of keeping the components on the bottom of the bottle, but a more square bottle was kept in mind with a handle that would be comfortable for the user's hand.

The second ideation of TRAQUA already has a more “classic” bottle shape (Figure 2).

For the third design, the team tried to come up with a concept that would either easy fold or just fit inside a backpack very easily. This was quite hard to accomplish, not because of the design but more in terms of the electronic components. It would be very hard to put them into the bottle if the bottle were shaped like in Figure 3.

Flyers

The team also had a few changes in their flyer before coming up with the definite solution. Below we will explore the different flyers the TRAQUA design team came up with.

The team's first flyer had no QR code; the text idea was already there, but the text just lies in boxes that feel out of place alongside the TRAQUA water bottle (Figure 4).

Immediately following the initial presentation, the group gathered to evaluate the proposed project tracks and reach a consensus. Our approach was rooted in an open brainstorming session where we weighed our individual strengths against the potential of each topic. It quickly became clear that the “Smartification of Objects” was the path that generated the most genuine enthusiasm among us.

More specifically, we decided to focus on a smart water bottle. This choice wasn't just based on personal interest; after conducting a preliminary market analysis, we identified a significant gap in the current landscape. We felt we could differentiate our product by consolidating multiple features and services into a single, cohesive solution. This sense of opportunity, combined with the fact that every team member felt comfortable and motivated by the technical challenges involved, made the smart bottle the definitive choice for our project.

Once we settled on the smartification of objects, specifically the smart water bottle, the team held its first dedicated brainstorming session. Because the potential features for a “smart” container are so vast, we needed a way to filter the noise and focus on what actually added value. We turned to Miro to map out these early thoughts, using the boards shown to organize our ideas into functional clusters. This collaborative space was essential not just for tracking our suggestions, but for refining a set of concepts that eventually became the foundation of our final proposal. Figure 5 represents one of the brainstorming activities we did in Miro.

Figures 6, 7 and 8 showcase the result of the initial brainstorming sessions conducted as part of the Design Thinking process.

The primary function of the smart bottle is to encourage consistent and healthy water consumption while, in the meantime, eliminating the hygiene concerns commonly associated with reusable water bottles. To achieve this, the bottle integrates five core features into a single device

First, a built-in UV-C sterilization module automatically disinfects the water and the interior surface of the bottle at regular intervals, removing the need for frequent manual cleaning and reducing bacterial buildup. Second, a temperature sensor continuously monitors the drink's temperature and makes this data available to the user in real time. Third, a hydration tracking system records water intake throughout the day and sends customizable reminders when the user falls behind their hydration goal.

All sensor data is transmitted via Bluetooth to a companion mobile application that serves as the central interface for the end user. The app displays all key aspects mentioned above. This ensures that the user remains actively involved in managing their hydration while the bottle handles the more technical tasks autonomously.

The bottle will be prices at approximately 330 €. For mass production the team could look to reduce the production price up to 140 € per bottle. Meaning the end price of the bottle would be around 160 - 220 €.

MATERIAL SELECTION : “The materials for each component of the smart water bottle were selected based on both functional requirements and aesthetic considerations, ensuring a balance between performance and visual appeal. Polypropylene (PP) is used for the cap due to its durability and ability to withstand repeated use, while also providing a clean and smooth finish that contributes to a modern appearance. The bottle body is made from polished aluminum, chosen not only for its lightweight structure and corrosion resistance, but also for its sleek, reflective surface, which enhances the overall aesthetic and gives the product a premium look. For the compartment containing the electronic components, a plastic material such as polycarbonate is used. This ensures proper electrical insulation and waterproof protection, while also allowing for a precise and refined design that integrates seamlessly with the rest of the bottle. Overall, the combination of these materials supports a design that is durable, safe, and visually appealing for everyday use.”

Figure 9 illustrates the initial structural draft of the product concept. The sketches explore the basic 3-piece concept.

The design contains the main body, which serves as the holder for the water. The top, a removable cap. The cap design also ensures the product can be safely transported without leakage or contamination. A filter integrated at the nozzle is proposed, indicating that the product may be used for dispensing liquids while controlling flow or removing particles. Last, the bottom part that holds all the components. The sketch also demonstrated how the different parts are assembled together, showing connection points and structural alignments.

Overall, these drafts focus on defining the product’s core structure, usability, and functional components before moving into more detailed design stages.

To ensure a coherent and professional presentation of the project, a visual identity was established for TRAQUA. This identity provides consistency across all project deliverables, including the report, presentation, and prototype interfaces.

Logo: The TRAQUA logo combines a water droplet icon with the project name, reflecting the system's core focus on water quality monitoring.

Tagline: “Know your water, trust your bottle.” — summarizing the project's goal of giving users reliable, real-time insight into their water quality.

Color Palette (Monochrome): Three colors form the visual foundation:

• #6377BD — primary dark blue, used for headings and key UI elements
• #D0E3FF — light blue, used for backgrounds and secondary elements
• #FFF9F0 — off-white, used for neutral backgrounds and contrast

The design is summed up in Figure 10.

In order to showcase the appearance of the products, 3D models were created. These models illustrate the structure of the three-part bottle. Figures 11, 12, 13, 14, 15,16,17, 18 present these models.

Add here detailed drawings (with precise dimensions); and 3D model with load and stress analysis of the TRAQUA bottle.

Figure 19 This is a system architecture/block diagram for a smart water bottle. At the core is an ESP32 DEVKIT V1 microcontroller that connects to several peripherals: an LED light, accelerometer (LIS3DHTR), TDS sensor (SEN0244), UV-C light, and a pressure sensor (FSR406) with a capacitor. Power is supplied by a battery through a charging circuit. The ESP32 communicates with a mobile application over BLE (encrypted + bonded) using notify/read/write operations. The legend color-codes the lines: red for energy, green for information, and blue for water-related connections.

Figure 20 presents the initial electronic system architecture of the smart bottle prototype. The diagram outlines the integration of the main components and their interactions, serving as a first iteration of the system design. At the core of the system is the ESP32 microcontroller, which manages data processing and communication between all connected components. Several sensors are included to support the intended functionality of the product. A TDS sensor is used to measure water quality, while a temperature and humidity sensor (DHT11) monitors environmental conditions. Additionally, a motion sensor and a force-sensitive resistor (FSR) are incorporated to detect user interaction and usage patterns. The system also includes a UV-C light module, controlled via a transistor circuit, which is intended for sterilization purposes. A display module (SSD1306) is connected via I²C to provide real-time feedback to the user. Power is supplied through a battery management system (BMS) connected to multiple lithium-ion cells. Voltage regulation is handled by a boost converter and linear regulator to provide stable 5 V and 3,3 V outputs required by different components. A USB-C interface is included for charging.

It is important to note that this design represents an initial draft, created to explore component selection and system integration. Certain aspects, such as power efficiency, component optimization, and circuit simplification, will be revised in later iterations.

To ensure the system operates reliably, a power budget was established for all electronic components. Table 1 outlines the voltage, normal and maximum current draw, and resulting power consumption for each component.

In Figure 21 shows how the application works. The application was made with one key concept in mind. Keep most of the “important” values one click away. With that mindset in mind. The application works in the following way. If the users log in for the first time, they enter their height and weight. This will help us determine how much water that person needs to intake per day. Then with 1 click that person can see the water purity and his or her total water intake. He can also start the cleaning process from the app by clicking on the navigation menu on the bottom of the app.

Figure 22 This is a Level 1 Data Flow Diagram (DFD) for a hydration tracking system. It shows an external entity (Water bottle) sending raw readings to a Sensors process (1.0), which passes data to a Process Data process (1.5). That process sends processed data to a Data store, which feeds into a Display on app process (2.0) that delivers hydration info to the User external entity. There's also a legend in the bottom-left defining the DFD notation (rectangles for external entities, circles for processes, open rectangles for data stores).

Software choices

The system consists of four main components: a mobile application, a web application a backend service and an embedded device based on ESP32.

• Mobile Application – The application was developed using EXPO Go, a framework built on top of React Native. The choice was made due to its rapid development capacity, its cross-platform support (iOS and Android), its ease of testing without the requirement of complex native configuration, and the fewer risks of vulnerabilities that React has. Expo Go also enables efficient prototyping and provides access to device features such as Bluetooth, which is essential for communicating with the ESP32.
• Web application – The shop of TRAQUA was done using Svelte due to its lightweight nature, fast performance, and simple reactive model. Unlike traditional frameworks, Svelte compiles components at build time, resulting in highly optimized and efficient code. Figure 23, Figure 24, Figure 25, Figure 26, Figure 27 are screenshots of the website.
• Backend – The backend is planned to be developed using Python in combination with FastAPI. Due to its simplicity, readability and extensive ecosystem. The backend is responsible for handling business logic, data storage, and communication between the web application and other system components.
• ESP32 – The system uses an ESP32 microcontroller, which is well-suited for IoT applications due to its low cost, built-in Wi-Fi and Bluetooth capabilities, and sufficient processing power. The ESP32 is responsible for interacting with hardware components and executing real-time tasks while communicating with the mobile application.
• Communication – Communication between the mobile application and the ESP32 is established using Bluetooth Low Energy (BLE). BLE was selected because it is energy-efficient, widely supported, and ideal for short-range communication between devices
• Security Considerations – Security is an important aspect of the system, particularly in Bluetooth communication. To ensure secure data exchange, several measures are implemented:
  • Secure pairing and bonding between devices
  • Encryption of Bluetooth communication to prevent interception
  • Authentication mechanisms to restrict unauthorized access
  • Input validation across all components (mobile app, backend, and ESP32)

Additionally, secure development practices are followed in both the frontend and backend to minimize potential vulnerabilities.

Comparing Mobile framework

Web Framework

Backend Framework

Microcontroller

Figure 28 explains how the user interacts with the system .

Present and explain the: (i) initial packaging drafts; (ii) detailed drawings; (iii) 3D model with load and stress analysis, if applicable.

As part of the TRAQUA project, we developed an innovative packaging solution that meets a dual objective: effectively protecting the bottle while offering a useful second life after purchase. Instead of creating disposable packaging, we chose to design a durable solution that can be reused as an everyday accessory.

Our concept takes the form of a textile sleeve inspired by a puffer jacket, made from recycled airbags. This material, originally designed for automotive safety, has highly valuable properties: it is strong, lightweight, and durable, yet difficult to recycle through conventional channels. Reusing it allows us to adopt a meaningful upcycling approach. Unlike a traditional puffer jacket, our design contains no added padding. Protection is achieved through a multi-layer construction of airbag fabric, combined with a quilted stitching pattern. This structure creates natural air pockets that help absorb shocks during transport, while minimizing the use of additional materials. This technical choice strengthens the environmental consistency of the project by reducing product complexity. To further protect the bottle, a soft towel layer is inserted between the airbag material and the bottle surface. This inner layer completely covers the contact area in order to prevent friction, scratches, or impressions caused by the airbag fabric during transport. The towel lining also improves the overall user experience by adding a softer and more protective interior finish. A key objective of this packaging is to move toward a mono-material design. By primarily using polyamide (the material that airbags are made of), including for stitching and straps, we improve end-of-life recyclability and avoid complex material blends that are difficult to process. Beyond its protective function at the point of sale, this packaging is designed to be reused as a carrying accessory. Equipped with an adjustable shoulder strap, it allows users to easily carry the bottle in their daily lives, while also providing space for small personal items such as a phone or keys. In this way, the packaging becomes a useful and long-lasting object, significantly reducing waste. Figure 29 displays the proposed packaging.

In summary, this packaging solution follows an eco-design approach by:

• upcycling a complex waste material (airbags),
• reducing the number of materials used,
• eliminating unnecessary components,
• protecting both the bottle body and cap during transport,
• and extending the product’s lifecycle through reuse.

This approach reflects TRAQUA's ambition to deliver a solution that is innovative, functional, and environmentally responsible.

For the prototype, we use a rigid plastic bottle as the main structure. This material is easy to obtain, lightweight, and resistant, making it suitable for testing our concept. Inside the bottle, we add aluminum foil sheets. The aluminum acts as a reflective surface, allowing the UV-C light emitted by the LED to be reflected throughout the interior of the bottle. This improves the distribution of the light and increases the efficiency of the water disinfection process. We also include a plastic separator at the bottom of the bottle to protect the electronic components. This separator isolates the battery, sensors, and LED from direct contact with the water, ensuring safety and proper functioning during testing. This simple prototype allows us to validate the concept and test the performance of the UV-C cleaning system before developing the final product.

Refer main changes in relation to the designed solution.

During the prototype phase, several modifications were made compared to the original design in order to simplify the construction process, reduce complexity, and make the product more practical for testing and development. The initial concept was based on a custom ergonomic bottle design, but for the prototype we instead used a Stanley Cup–style gym flask. This differed from the original idea because it provided a ready-made and durable structure that could easily house the components without the need to manufacture a completely custom bottle body. Using an existing flask also reduced production time and allowed the team to focus more on testing the electronic functions of the system.

Another major change concerned the bottle base and sensor mounting. In the original design, the system included a separate base structure intended to contain some of the hardware and provide mounting points for the sensors. In the prototype version, this structure was simplified by attaching the sensors directly to the bottom section of the bottle instead of using a detachable or independent base. Although the base structure was removed, the electronic hardware is still protected inside a custom 3D-printed plastic casing. This downscaled the mechanical design and reduced the number of structural parts required for assembly. To secure and seal the components, superglue and silicone were used during assembly. Superglue was mainly used for mounting and fixing components in place, while silicone was applied to improve sealing and provide protection against water and moisture.

An additional modification was the inclusion of an OLED display. The original design did not include a display screen, but during development an OLED module was added because it was supplied as an extra component by the manufacturer. The display improved the functionality of the prototype by allowing real-time system information and sensor readings to be shown directly to the user. Compared to the initial design, this provided a more interactive and user-friendly experience while also making testing and debugging easier during development.

Implementation Changes and Prototype Code

Changes Made in Relation to the Designed Solution Temperature sensing — sensor and library change. The initial design used a DS18B20 digital probe driven by the OneWire and DallasTemperature libraries. This was replaced with an SHT21/Si7021-class sensor on the I²C bus, driven by the Adafruit Si7021 library. The change removed the dedicated OneWire data line and its pull-up resistor, simplified wiring to the shared I²C bus, and added relative-humidity measurement at no extra hardware cost. The temperature value is also reused downstream for temperature-compensating the TDS reading.

Additional sensing and output components. Several components were integrated beyond the original sensor set: an analog pressure sensor (used to estimate the water volume in the bottle and, from that, detect drink events), a Gravity TDS meter (replacing the placeholder TDS value with a real, temperature-compensated reading in ppm), a magnetic reed switch (acting as a safety interlock), a UVC light control output, an SSD1306 OLED display, and two status LEDs (green/red) indicating drinking-water quality. The pH value remains a placeholder pending a calibrated pH probe. Safety architecture. Because the prototype includes a UVC light, a reed-switch interlock was added: the firmware forces the UVC output off at every boot and continuously verifies that a magnet is detected before the device operates. The interlock is fail-safe — an open or broken switch reads as “unsafe” and keeps the UVC off.

Development tools and platforms. The Arduino IDE was upgraded from version 1.8.x to 2.x after the older version produced a package-manager fault and slow, un-cached compiles; version 2.x provides working build caching and noticeably faster recompilation. Firmware is built on the Espressif ESP32 Arduino core. Libraries added during development: Adafruit Si7021, Adafruit GFX, Adafruit SSD1306, and Adafruit BusIO; the BLE stack uses the ESP32 BLE Arduino library bundled with the core. Flashing is performed with esptool; because the development board's automatic reset was unreliable, a manual BOOT/EN download-mode procedure was used. Mobile application platform. The app is built with React Native and Expo (expo-router, TypeScript) and uses react-native-ble-plx for Bluetooth Low Energy. A significant platform change was moving from the Expo Go client to a custom Expo development build, because BLE is a native module that cannot run inside Expo Go. Testing was carried out on a physical Android device, since emulators have no Bluetooth radio. Application-level code changes. Three notable changes were made to the app's BLE layer. First, the connection now negotiates an enlarged MTU (247 bytes); the default 23-byte MTU truncated the JSON sensor payload. Second, device scanning was changed to filter by the service UUID rather than by device name, which proved more reliable on recent Android (Samsung) devices. Third, the data model was extended: the SensorReading type gained humidity and bottleVolumeMl fields, the BLE parser was updated to read them, and the global state provider (BottleProvider) gained logic that automatically logs a drink when the measured bottle volume drops.charts.

Prototype Code Flowcharts

Smart device firmware — initialisation (setup)

Smart device firmware — main loop (loop)

Mobile application — BLE connection and data flow

Perform the hardware tests specified in Tests. These results are usually presented in the form of tables with two columns: Functionality and Test Result (Pass/Fail).

Our software testing framework directly addresses functionality, performance benchmarks, and user experience using the specific strategies and tools from our workflow:Functional Testing: We validate our identified use cases and user stories by verifying the system's core behavior. This includes unit testing our individual JavaScript/TypeScript code modules within Webstorm using Node.js , as well as executing API endpoint tests via Postman. We also conduct integration testing across the ESP32 firmware and the React Native mobile application to ensure these components function correctly as a combined entity. Performance Testing: To evaluate speed, responsiveness, and stability under a workload, we run performance tests focused on data volume, system load, and runtime. These benchmark tests are repeated 10 times to determine precise average results and standard deviations, ensuring the BLE communication link and backend data transmission remain stable over time. Usability Testing: To ensure the system is intuitive and accessible, we conduct usability testing according to the System Usability Scale (SUS). This allows our frontend team to validate interface feedback , evaluate how easily a user can understand their water safety status (Safe, Warning, Unsafe, Unknown) , and confirm that the mobile application provides clear, responsive alerts Software tests comprise: (i) functional tests regarding the identified use cases / user stories; (ii) performance tests regarding exchanged data volume, load and runtime (these tests are usually repeated 10 times to determine the average and standard deviation results); (iii) usability tests according to the System Usability Scale.

Provide here the conclusions of this chapter and make the bridge to the next chapter.