Category: Mario’s Status Reports

Key contributions included
This week I advanced project wrap-up and demo readiness by preparing the Monday presentation (slides, flow, and talking points), developing poster board content and layout (including supporting visuals and alignment with the project narrative), and revising the final report (documentation of outcomes, method, and results).

Is your progress on schedule or behind?
The progress for the poster and final report are more than enough to stay on schedule. The firmware and finalization of our actual demo, the MVP, is lagging behind.

What deliverables do you hope to complete in the next week?
In the next week I aim to complete and print out everything for the poster board as required. I’ll also continue to work on the final report. I will also address any feedback from instructors or peers on these items before the due dates.

Key contributions included

• Successfully flashed the ESP32-S3 devices and resolved all dependency errors blocking setup.
• Improved web dashboard legibility so users can clearly understand what each metric is measuring.
• Added clear separation between Demo Mode and Live Mode to improve usability and presentation clarity. As part of this I implemented automatic population of 12 hours of simulated data points to better showcase data collection behavior.
• Established successful connections across all API ports, verified through the API health endpoint.
• Completed the full final presentation slideshow and began drafting the final written report.

Is your progress on schedule or behind?
Progress is lagging behind schedule. This week’s work closed key technical blockers (firmware flashing and API connectivity), improved dashboard quality, and completed major final-deliverable prep (presentation + report start), which barely allows for room to finish our firmware/hardware wiring.

What deliverables do you hope to complete in the next week?
Complete end-to-end validation of live data flow and dashboard behavior.
Perform final QA pass on dashboard readability and Demo/Live mode transitions and rehearse the final presentation.

What new tools did you find necessary to learn about?
To design, implement, and debug this project I used several tools and workflows across both embedded systems and web development. For hardware, I learned more about the ESP32-S3 flashing process, how to diagnose and resolve dependency/environment issues that can prevent firmware deployment. For software, I had to look into dashboard design for readability, data presentation techniques (including simulated/faux data generation for demo scenarios), and API service verification through health endpoints and port connectivity checks.

What learning strategies did you use?
I relied heavily on iterative troubleshooting (testing, identifying specific errors, and refining fixes), official documentation for ESP32/toolchain setup and API behavior, and forum threads.

A major part of my process was using AI. I used it to talk through problems step-by-step, learn unfamiliar concepts quickly, brainstorm and evaluate feature ideas, and iterate on improvements from a stakeholder/user perspective. This made it easier to move from technical fixes to user-centered decisions, especially when refining dashboard clarity and deciding which features would best communicate value in demo and live use cases.

Key contributions included
I fixed the wiring documentation so the hardware setup is clearer, safer, and easier to follow during bring-up. That should make it much easier for the team to avoid bad connections when we start flashing and testing devices.

I also fixed the connections between the database and MQTT so the backend services communicate more reliably. That work was important for making sure the system behaves correctly before more live hardware is introduced.

Another part of my work was setting up the config and env files on my local repo clone in preparation for firmware setup and flashing. That helped get the development environment into a ready state for the next phase of testing.

I also ran extensive checks to make sure the system is working properly and to reduce the risk of damaging any components during testing. The goal was to catch issues early and make the transition into hardware validation as safe as possible.

Is your progress on schedule or behind?
On schedule for this phase. The wiring documentation has been improved, the database and MQTT integration issues have been addressed, and the local environment is now prepared for firmware setup and flashing. The validation work also puts us in a much safer position before moving further into hardware testing.

What deliverables do you hope to complete in the next week?
I hope to complete the firmware flashing setup and begin testing on actual hardware. I also want to verify end-to-end communication between the firmware, MQTT, and the backend after the recent integration fixes.

In addition, I want to use the updated wiring documentation during bring-up to confirm that the documented connections match the real hardware setup. After that, I plan to finish another round of validation checks so the team can move into hardware testing with more confidence and less risk.

• Materials and BOM: Sorted and verified purchased hardware against the project bill of materials so the team knows exactly what is available for build and test.

• Raspberry Pi 5 / IoT setup: Started installing and configuring dependencies on the Raspberry Pi 5 for the IoT backend environment.

• System integration: Worked through how the separate software pieces connect, specifically the Docker containers and how services depend on each other in the overall pipeline.

• Electrical safety and wiring: Researched a careful approach to power, grounding, and load connections so we avoid wrong voltages, excessive current, or damage to ESP32s, sensors, and actuators.

• Software validation: Ran tests on the software pipeline to validate behavior before attaching live hardware.

Is your progress on schedule or behind?

On schedule for this phase. Materials are organized, Pi-side setup and container integration review are in progress, and we are ready to shift to first-node hardware bring-up next week. Parallel work on wiring safety and pipeline testing keeps integration risk manageable.

What deliverables do you hope to complete in the next week?

This week I focused on stabilizing the Raspberry Pi 5 Python environment so our backend dependencies install cleanly, collecting and organizing delivered materials, and refactoring the codebase and documentation to match our current use case.

Key contributions included:

• Raspberry Pi 5 virtual environment and dependencies: I spent most of my time getting a venv on the RPi5 set up so that installing from requirements.txt completes without failures or crashes. The goal was a repeatable, smooth setup path for FastAPI, database drivers, MQTT-related packages, and the rest of the stack we need for integration on the Pi.
• Materials pickup and organization: I picked up materials that were delivered to the front office and sorted everything so we know what we have on hand for the physical demo and wiring (and what still might be pending).
• Codebase refactor for current use case: I refactored a large portion of the code to align with the system we’re building now (web-first building control, MQTT, subsystems as we’ve scoped them in the Design Report). This included cleaning up structure and behavior so it’s easier to maintain as we hook up hardware.
• Documentation and polish: I improved overall code quality where it touched the refactor and updated the README so setup on the Pi, repo layout, and how to run things match the current project state.

Is your progress on schedule or behind?
I am on schedule relative to my own track: the RPi5 environment is in a much better place for backend install and testing, materials are accounted for, and the repo reflects our current architecture and use case. The next bottleneck is joint progress on physical assembly and firmware bring-up with Cindy, but my software and Pi-side prep are moving forward as planned.

What deliverables do you hope to complete in the next week?

• Backend on RPi5: Finish or verify full backend bring-up over SSH (FastAPI, MQTT broker, TimescaleDB/Docker as applicable) using the working venv, and run at least one end-to-end smoke test (e.g., health check + MQTT publish/subscribe or a single API path).
• Hardware integration support: As soon as the frame and nodes are ready, help wire or validate one path (e.g., access control or one room’s environmental node) against the live backend on the Pi.
• CI and tests: Keep GitHub Actions green after the refactor; add or adjust tests for any new MQTT/API paths or settings so coverage stays above our target and regressions are caught during integration.

This is the CAD file I was able to create through FreeCAD

Despite spring break and our exam schedules limiting what we could get done with the hardware, substantial progress was made toward our upcoming deliverables. The brunt of it was achieved through the team design report.

Key contributions included:
Most of this was done in an effort to get the Design Report ready for submission. It was more of an urgency than a scheduled completion.

• Design Report Writing: I contributed roughly half of the content for our team’s Design Report (docs/Team_A4_Belmonte_Chen_design_report.pdf), focusing on polishing the Implementation, Testing, and Buy List sections. This included formalizing how our access control, lighting, and temperature subsystems interface through the backend and MQTT-based communication, as well as documenting architectural trade studies and our PID-based HVAC temperature regulation addition.
• Comprehensive Buy List & Sourcing: Compiled a full parts buy list for the physical demo, including sensors, and actuators. I researched hefty amount for vendors for microcontrollers, lighting modules, and RFID readers, ensuring that we have procurement plans in place and concrete pricing for each item.
• Schedule Management: Created and updated our Gantt chart to reflect new phase breakdowns, hardware procurement milestones, and division of labor for both demo construction and final system integration.
• System Documentation: Ensured documentation of architectural decisions and trade-offs. This included sampling rates, communication architecture (transitioning to MQTT), and firmware structure. This was all integrated into both the GitHub repo and the report, providing clear technical references for future builds and troubleshooting.
• Parts Handling & Security: Helped secure newly acquired RFID modules and the RPI 5 by locking them in the designated Hamerschlag lab storage. This prevents loss or damage before integration and ensures responsible stewardship of valuable components.

Is your progress on schedule or behind?
We are still on schedule, though spring break and exam prep did slightly slow hands-on progress. Most deliverables are either completed or actively in progress. The next step is waiting on the arrival of the materials for the house model.

What deliverables do you hope to complete in the next week?

• Physical Demo Preparation: Finalize the physical house layout design, secure the remaining wood panels, and begin house frame construction. This will set us up for hardware component integration and system validation.
• CI/CD Pipeline Improvements: Aim for >50% code coverage on the GitHub repo, further establishing confidence in the reliability of our codebase.
• Raspberry Pi Familiarization: Dedicate time to hands-on testing with the Raspberry Pi 5, installing necessary software and verifying communication with the backend and nodes.
• Parts Integration: Begin wiring and integrating sensors and actuators, starting with the RFID modules and lighting system if structural progress allows.

No deliverable contributions were made this week. Looking back on last week’s report, I severely over estimated what we could accomplish in 7 days; mostly because of upcoming exams I’ve been studying for. Even so, considerable progress was still made.

Key contributions included:
Much of what was “contributed” was just learning in preparation for certain modules of our project.

• CI/CD: In my AI ML class we’ve spent a considerable amount of time discussing how to do complete test coverage of code we create. Now I feel extremely comfortable approaching and establishing a robust CI pipeline for our GitHub monorepo.
• System Design: After having an extensive discussion with one of the lead capstone class professors, I’ve realized a key error in our tech stack for this project. Due to the nature by which I’ve learned system design up to this point, the software stack I created for the IoT has an overengineered message broker (Redis). I now realize this is overkill and we could potentially opt for a less intricate solution like MQTT.
• Parts: Our requested RFID modules and the RPI 5 have arrived and are in our possession. I went ahead and locked these parts inside one of the red boxes provided to us at the Hamerschlag lab hall.

Is your progress on schedule or behind?
We’re still way ahead of schedule so I’m not worried that we went one week without a deliverable.

What deliverables do you hope to complete in the next week?
Here’s what I plan to hopefully get done by the end of next week; to be honest it’ll probably drag on to the week after since it’ll be spring break!

• CI Pipeline: I’ll try and get at least 50% code coverage on the current GitHub repo we have. That way we’ll be certain there aren’t any vital tests gone awry.
• Software Stack: I’ll figure out a way to use an MQTT instead of a Redis stream. Since it’s already implemented as such, the MQTT will most likely be a separate (alternate) to our message broker of choice.
• RPI 5: We need to get accustomed to using the RPI software. At least 2-3 hours will be dedicated to familiarizing myself with the coding language and its CLI.

This week marked a significant transition from planning and architecture into active implementation. My primary focus was building out the full software stack; initializing the repository scaffolding, implementing the backend API and lighting control subsystem, and making a semi-decent frontend dashboard. I managed the development workflow using AI-assisted tools, which I detail transparently below.

AI Tool Usage Disclosure: I used GitHub Copilot coding agent and Cursor (AI-powered IDE) as development accelerators throughout the week. Specifically:

• GitHub Copilot coding agent was used to generate initial scaffolding code (PR #1), implement lighting control backend services and database schemas (PRs #2, #4), update README documentation (PR #3), and fix targeted bugs in the frontend utilities and WebSocket logic that surfaced during code review (PRs #6, #7, #8, #9). I authored every prompt, defined the scope and requirements for each PR, reviewed all generated code for correctness, and merged only after verifying the output met our system’s architectural standards.
• Cursor Agent was used to generate the full dashboard frontend UI overhaul (PR #5), producing React components, page layouts, service integrations, and the theme system. I provided the design specification (dark flat aesthetic, Mosaic-inspired), directed the component structure, and made iterative refinements including a follow-up manual CSS overhaul to remove beveled corners (PR #10, authored entirely by me).
• This status report itself was drafted with the assistance of GitHub Copilot Chat (Claude), which I prompted with my repository context and previous report format. I reviewed, edited, and verified all content for accuracy.

Key contributions included:

• Repository Initialization & Project Scaffolding: Designed and prompted the complete project architecture; a monorepo folder structure spanning firmware/, backend/, frontend/, infrastructure/, docs/, certs/, hardware/, and scripts/. I authored the detailed specification that dictated every file, dependency, and configuration template (PR #1). This included defining all FastAPI entry points, PlatformIO project configs for three ESP32 nodes, the React app skeleton, Docker Compose files for TimescaleDB and Redis, CI/CD workflows, and comprehensive documentation stubs (ARCHITECTURE.md, API.md, SETUP.md, USER_GUIDE.md, TESTING.md, productReqDoc.md, projectDescription.md).
• Lighting Control Subsystem: Architected and directed the implementation of our third subsystem (lighting control with daylight harvesting). This involved specifying the firmware structure for ESP32 #3 (TEMT6000 ambient light sensor, PWM dimmer via LEDC, 4-channel relay control), the backend API endpoints (/api/lighting/dimmer, /api/lighting/relay, /api/lighting/daylight-harvest), the TimescaleDB hypertables (lighting_sensor_data, relay_state, dimmer_state) with continuous aggregates and 90-day retention policies, and the Pydantic validation schemas (PRs #2, #4). I defined all hardware GPIO pin assignments, the BOM for the TEMT6000, IRF520/540 MOSFET dimmer, and SRD-05VDC relay module, and updated the power budget from 4.88W to 13.0W peak.
• Backend API & Services Layer: Directed the implementation of the FastAPI backend with the WebSocket manager for bidirectional device/client communication, the database client with session management, sensor data endpoints with real-time broadcast, and the full lighting control API (12+ endpoints documented in API.md). I configured CORS, Pydantic Settings for environment management, and the startup/shutdown lifecycle hooks.
• Frontend Dashboard – Design & Implementation: Specified and directed the build of the complete React dashboard (PR #5), replacing the minimal skeleton with a multi-page application featuring: real-time temperature and lighting graphs (Recharts), access control with RFID policy management, dimmer/relay controls, admin authentication, CSV export, and WebSocket live telemetry. I ripped the initial web page design from one of my previous TartanHacks Hackathon projects. I steered towards a dark-theme flat UI and then manually authored the CSS theme overhaul (PR #10) getting rid of all rounded corners/bevels and retuning the color palette to match our project’s aesthetic. This was the only PR where I wrote every line of code myself without AI assistance.
• Code Review & Bug Resolution: Went through and reviewed every single AI-generated pull requests for correctness where I identified and filed issues for four specific bugs: toIsoTimestamp treating epoch-zero as falsy (PR #6), WebSocket URL fallback hardcoded to localhost (PR #7), createOrCheckAccessEvent returning raw unnormalized data (PR #8), and filterSeriesByRange breaking on epoch-zero timestamps (PR #9). I wrote the problem descriptions and directed the fixes.
• Documentation: Updated the main README.md to show the new three-subsystem architecture (PR #3), which includes hardware wiring specs, data flow diagrams, and updated performance targets. I also authored and reviewed updates to SETUP.md (15+ troubleshooting scenarios), API.md (12 endpoint specs with request/response examples), and the file-architecture.md implementation status tracker.
• Infrastructure: Configured the Docker Compose stack (TimescaleDB + Redis) with proper volume mounts, health checks, and networking. Set up the GitHub Actions CI pipeline for backend linting (flake8, black, mypy, bandit, safety).

Is your progress on schedule or behind?
I’m ahead of schedule. The original plan was to test for backend environment initialization and initial MQTT broker this week. I’ve delivered a nearly complete full-stack implementation with a working backend, 12+ API endpoints, a pretty good frontend dashboard, three firmware project structures, CI/CD, and comprehensive documentation. The lighting control subsystem that was supposed to be done later is basically complete.

What deliverables do you hope to complete in the next week?

• Firmware Flashing & Hardware Integration: Flash the ESP32 firmware onto physical hardware, wire the RFID-RC522, BME280, TEMT6000, solenoid lock, and relay module, and validate end-to-end communication with the backend.
• Access Control API Completion: Implement the remaining backend endpoints for RFID-based access control (/api/access, /api/policies) and remove the frontend’s local mock fallbacks.
• TLS Certificate Infrastructure: Generate the CA and server/device certificates for the secure handshake protocol between ESP32 nodes and the backend.
• WebSocket Real-Time Testing: Validate bidirectional WebSocket communication between the dashboard and physical ESP32 devices over the local network.

Following our initial consultations with the course staff, my primary focus was finalizing the architecture of the software stack for the proposal and making sure to define the system requirements. I moved away from a simple collection of sensors and more toward having an emphasis on a cohesive web infrastructure built to scale.

Key contributions included:

• Requirement Specifications: Defined the quantitative targets for our system, including the 0.5°C deviation accuracy for temperature sensing and the <2s latency for remote door actuation.
• System Architecture: Developed the high-level block diagram, specifically architecting the interaction between the ESP32 nodes (firmware), the Raspberry Pi Gateway, and the Web Application.
• Software Stack Selection: Researched and selected our tech stack, choosing React.js for the frontend, Node.js/Express for the backend, and MQTT as our primary communication protocol to ensure low-latency data transmission.
• Use Case Refinement: Worked with the team to narrow our focus to a web-first building control platform, ensuring our abstract and problem statement reflected a professional-grade solution rather than a simple hobbyist sensor kit.

Is your progress on schedule or behind?
I am currently on schedule. While my partner finalized the Gantt chart and labor division, I provided the technical milestones necessary to populate that schedule, ensuring the software development phases are realistically timed.

What deliverables do you hope to complete in the next week?
In the upcoming week, I plan to focus on the following software-specific tasks:

• Subsystem Interfacing: Define the specific JSON schemas for MQTT messages passing between the sensors and the gateway.
• Backend Environment: Initialize the Node.js server environment and set up the project’s GitHub repository.
• Hardware Setup: Assist in the initial configuration of the Raspberry Pi to begin testing the local MQTT broker.