Category: Team Status Reports

Most Significant Risks and Mitigation
Hardware and demo integration risk: the live demo still depends on firmware and wiring behaving on the actual build, not only on the bench. Cindy is prioritizing a stable MVP firmware path for demo day. Mario will keep time for at least one full rehearsal with the stack we plan to show (backend, broker, dashboard, and nodes).

Documentation and deliverables risk: poster, slides, and final report all have hard deadlines close together. Mario is working on the poster early and treating the written final report as parallel work, not something that waits until the last night.

Design Changes
No major architecture change this week. We are mostly polishing how we present the system (poster layout, figures tied to requirements, presentation flow). Where test evidence shows something is only validated on the software path or with mocks, we say that clearly on the poster so we do not overclaim.

Schedule Updates
Overall we are behind on the firmware side and final MVP demo readiness, but writing and presentation prep are in decent shape. Next week we need to finish poster submission, refine the final report, and confirm the demo path with Cindy’s firmware build.

Progress and Technical Highlights
Backend testing remains part of our routine: pytest covers sensor ingest, lighting and fan commands, RFID and door access flows, schemas, broker setup, health routes, websocket manager behavior, and modular paths for room node, BME280, TEMT6000, dimmer, fans, RFID, door node, and websocket comms. Those runs give us repeatable checks before demos.

For system level experimentation we documented timing and behavior for things like dashboard updates, history loads, unauthorized card denies, permission revoke, ingest cadence, and lighting command paths. Findings were mostly that measured latencies stayed inside the targets we advertise on the poster for the paths we could measure end to end, and we labeled anything that was only partially exercised (like commands without a real lamp on the hardware). That analysis fed small wording and chart choices on the poster rather than big product changes.

Tests and experimentation
Unit and automated tests: We run the backend pytest suite under backend/tests/, including modular tests under backend/tests/modular/. That includes API and validation tests for sensors, lighting, access, door flows, room node payloads, environmental and light sensors, dimmer and fan relays, RFID scenarios, websocket handshake checks, broker factory behavior, health endpoints, pydantic schemas, and websocket manager logic.

System style runs: Manual or instrumented checks for the demo story, timed where it mattered, with results summarized on the poster (dashboard refresh, history query, denied swipes, revoke timing, periodic ingest, lighting commands).

Findings: Automated tests caught edge cases early (bad payloads, offline device paths, fail secure access). Timing runs supported our poster claims where we had real numbers, and pushed us to split “fully demonstrated” versus “software path only” so the report and poster stay honest.

Most Significant Risks and Mitigation
Hardware integration risk: Since most physical build progress this week centered on the model house, there is a risk of uneven progress between hardware presentation and software/system integration.
Mitigation: Prioritize an integration checkpoint next week (ESP32-S3, dashboard, and API verification) and assign clear owner tasks for each subsystem.
Demo readiness risk: If demo/live workflows are not fully aligned before final delivery, there is a risk of confusion during presentation.
Mitigation: Continue using separated Demo Mode/Live Mode flows and run a full end-to-end rehearsal with both paths.
Time compression risk on final documentation: With technical work still active, report polish could be delayed.
Mitigation: Block dedicated writing/review time early next week and finalize report sections in parallel with final QA.

Design Changes
Refined dashboard design for improved metric legibility and easier user interpretation. Additionally, added custom rule creation.
Introduced a clearer separation between Demo Mode and Live Mode to support stakeholder-facing demonstrations.
Added automatic loading of 12 hours of simulated data in demo scenarios to better communicate system behavior when live data is limited.
Team physical prototype now includes the model house build (completed by partner), improving overall demonstration context.

Schedule Updates

• Overall project status is a little behind schedule, but doable.
• Major blockers were removed this week (ESP32-S3 flashing/dependency fixes and API port connectivity verification).
• Presentation slides are complete, and final report drafting is underway.
• Next week will focus on integration validation, final documentation completion, and rehearsal.

Progress and Technical Highlights

• Successfully flashed ESP32-S3 devices and resolved dependency/toolchain errors.
• Established successful API connectivity across required ports, confirmed via health checks.
  Improved dashboard UX/readability so metrics are more understandable to users.
• Implemented demo data generation to auto-populate 12 hours of faux telemetry.
• Completed final presentation deck and initiated final report writing.
  Cindy completed the model house for the physical demo setup.

Most Significant Risks and Mitigation
The biggest risk right now is hardware integration, especially making sure the ESP32 room nodes can safely support the intended mix of sensors and actuators without wiring conflicts, power issues, or unstable communication. To reduce that risk, the team has been doing more realistic node compatibility and combined-load testing instead of only validating one component at a time. We also updated the wiring documentation and ran extensive software and configuration checks so that when the hardware is powered and connected, there is much less chance of incorrect wiring or a backend-side integration failure.

Another important risk is integration between the firmware, MQTT, database, and backend services. Since a lot of the upcoming work depends on those pieces behaving consistently together, we spent time fixing the database and MQTT connections and preparing local config and env files ahead of firmware flashing. That gives us a more stable foundation before full system bring-up.

A final risk is physical integration into the final demo house. Bench testing is useful, but it does not fully reflect the packaging and mounting constraints of the real build. To address that, work is already underway on the final house fabrication and on reorganizing MCU and wiring layouts into more compact room-level assemblies that can actually fit into the final structure.

Design Changes
The project is moving from isolated prototype validation toward a more room-based system design. Instead of treating each ESP32 setup as a simple standalone test, the team is now validating which combinations of sensors and actuators can reliably share one node and still fit into a practical room-level package. That is shaping both the firmware plan and the physical hardware layout.

There have also been design improvements on the documentation and integration side. The wiring documentation has been revised to better reflect safe and repeatable setup, and the software stack has been adjusted so the database and MQTT layers connect more reliably. These are not cosmetic changes. They directly support safer hardware bring-up and smoother end-to-end integration.

On the physical side, the demo structure is also evolving from a simple one-room or box-style setup into a more complete house design. That change better supports the final system goals because it allows hardware to be mounted and demonstrated in a more realistic room-by-room layout.

Schedule Updates
The team appears to be on schedule for this phase. Based on the planned transition from subsystem work into integration and build preparation, the current work lines up well with what should be happening now. Hardware procurement is continuing, node stress testing is progressing, the final demo house is being fabricated, and the software side is being prepared for firmware flashing and backend integration.

The hardware side is no longer limited to basic bench testing, and the software side is no longer only being validated in isolation. That parallel progress lowers the chance of a late integration crunch and keeps the team aligned with the next stage of full system integration.

Progress and Technical Highlights
This week’s progress shows clear movement toward full system integration. On the software side, wiring documentation was improved, the database and MQTT connections were fixed, local config and env files were set up for firmware flashing, and extensive checks were run to make sure the system is stable before attaching more live hardware. That work strengthens the backend foundation and reduces avoidable issues during bring-up.

On the hardware side, additional parts were ordered for the next integration phase, and node compatibility testing continued under more realistic conditions. Instead of only confirming that individual pieces work, the team is now checking which combinations of sensors, actuators, and control functions can coexist reliably on the same ESP32. That is helping define the practical room-node design for the final system.

There was also solid progress on the physical demo environment. Work continued on designing and fabricating the final demo house, while planning also began for packaging MCUs and wiring into cleaner room-level modules. Together, these efforts show that the project is moving beyond separate prototype pieces and toward a complete, integrated smart home demonstration.

Verification (Individual Subsystem)
We have begun verification on my subsystem by testing wiring correctness, MQTT/database connectivity, and local config/env setup needed for firmware flashing and backend communication. Next, we’ll will run repeatable tests for flash success, message delivery, reconnect behavior after interruptions, and basic latency from node publish to backend handling. We will analyze results using a requirement-to-test matrix, where each engineering requirement has a measurable pass/fail criterion (for example delivery success rate, recovery time, and acceptable latency range). Verification will be considered complete when repeated runs consistently meet those thresholds and no safety-critical wiring or configuration issues remain.

Validation (Team System-Level Use Cases)
For validation, the team is moving from isolated subsystem checks to full end-to-end use-case testing across firmware, MQTT, backend services, and mounted hardware nodes. Planned validation includes multi-node operation, command/response flows, fault-recovery scenarios (broker/backend restart or temporary network loss), and sustained runtime checks in the demo setup. We will analyze measured results against use-case acceptance criteria such as end-to-end success rate, system response time, stability over time, and recovery performance. Validation is successful when the integrated system reliably performs the required user-facing smart-home behaviors under realistic conditions.

Most Significant Risks and Mitigation

We could damage boards or the lock if voltage, ground, relay wiring, or GPIO use is wrong. We are reducing that by bringing hardware up in steps (sensors first, then RFID, then relay alone, then the lock), double checking ESP32 S3 pins, proving the relay before the solenoid is in circuit, using a diode across the lock coil, and writing down power and wiring rules before we add more nodes.

Hooking the Pi, Docker, backend, and firmware together can fail in small ways once real devices are on the network. We are testing the software path on its own while the demo hardware runs, mapping which services talk to which, and connecting one node at a time so problems are easier to find.

Putting more electronics into the model house can create flaky connections or messy routing. We plan to reuse the same test approach as the interim demo, keep room wiring consistent, and log how each room is built so we can repeat it.

Design Changes

We focused first on two working node types on the bench and in the model instead of wiring the whole house at once. That is a deliberate stepwise plan so each part is proven before we scale.

The demo environmental node uses BME280 and BH1750. If the final design standardizes on different parts for all rooms, we will align the documentation and firmware so everything matches.

The Pi side may need small edits to ports, compose files, or environment variables as real traffic appears. Those are config tweaks, not a full redesign.

Schedule Updates

We are on track for this phase. The interim demo works for both node types, the house model is built, and work continues on the Pi, containers, parts list, and pipeline tests.

Next we move from bench demos to hooking nodes through the full stack and adding more room hardware in the model. Nothing major has slipped so far.

Progress and Technical Highlights

The environmental ESP32 is wired with BME280 and BH1750. I2C and sensor reads were checked with small test programs. The node reads environmental data in the demo setup.

The door ESP32 uses RC522, a relay, and the solenoid. Firmware was built in stages (RFID only, relay only, then card plus lock). The lock opens only for authorized UIDs and the relay and diode were verified before relying on the full path.

We fixed real bring up issues: bad or loose breadboard ties, pin mistakes, and relay behavior before the lock was fully in loop.

The physical model house is assembled. Both demo node types run for the interim demo.

Separately, parts are organized against the BOM, the Pi 5 and IoT dependencies are underway, Docker service connections are clearer, and we ran tests on the software pipeline to support safer integration.

Next we add more rooms, finish integrating the house, grow firmware from the demo toward a full multi node setup, and write down wiring and config so the team can copy it.

Most Significant Risks & Mitigation
The main risk is that end-to-end validation is still blocked on a stable backend on the Raspberry Pi 5. Cindy has brought up the room-node firmware path (smartHome/firmware/room-node) and reviewed the C++ for sensor init, Wi‑Fi/WebSocket connectivity, telemetry, and dimmer/fan/relay commands, but full functionality cannot be confirmed until Mario finishes dependency setup and we run hardware plus integration tests against the live stack. Mario has been stabilizing the Python venv and requirements.txt installs on the RPi so installs don’t fail or crash, mitigation for environment fragility. A second risk is physical demo fit and materials: construction follows the CAD/specs (18×18 in footprint, three rooms, defined door/window/clearances); the window glazing is still TBD. Cindy plans to order acrylic sheets for visibility rather than a realistic window. Mitigation: order acrylic early and dry-fit the living room node on the structure before final glue/screws.

Design Changes
No change to the overall three-subsystem architecture (access, environmental/HVAC, lighting) or to the room-node’s intended role. Physical dimensions and openings are now documented explicitly (overall size, room splits, wire holes, lock zone, window/door ranges) so construction and electronics stay aligned. Code changes on Mario’s side are refactors and README updates to match the current use case, not a scope change.

Schedule Updates
Mario is on track, RPi venv/requirements.txt work, materials received and sorted, repo refactor and README updates. Cindy reports she’s catching up after earlier slips where hardware bring-up for one room node and demo construction are advancing. Joint milestone remains: backend running reliably on the Pi, then room-node ↔ backend integration and living room wired first for fit check on the demo. For next week, prioritize RPi backend smoke tests and first room wiring on the structure.

Progress & Technical Highlights

• Raspberry Pi 5 environment (Mario): Worked through Python venv setup so pip install -r requirements.txt completes without failures/crashes, aiming for a smooth, repeatable path to FastAPI, DB clients, MQTT-related packages, and the rest of the backend stack on the Pi.
• Materials (Mario): Picked up deliveries at the front office and sorted inventory for build-out and wiring.
• Codebase and docs (Mario): Refactored a large portion of the codebase for the current web-first building-control use case; improved structure/readability where touched; README updated to match how to run and configure the project today.
• Room-node firmware (Cindy): Focus on firmware/room-node: reviewed/iterated on C++ that initializes environmental and light sensors, manages Wi‑Fi and WebSocket connectivity, sends periodic room telemetry, and handles incoming commands for dimmer, fan, and relays. Full validation awaits Pi backend readiness and bench/integration testing.
• Physical demo (Cindy): Continued construction from the CAD design with locked dimensions (e.g., 18.0 in x 18.0 in footprint, 10 in wall height, three rooms with listed sizes, door/window and wiring hole specs, lock mounting zone). For the window material, plan to use ordered acrylic for a clear view into the model. Next: wire living room sensors/parts to the ESP32 first, then mount to the demo for fit and adjustment.

Most Significant Risks & Mitigation
The main risk is delayed progress on the physical demo and firmware. Cindy was set back by post Spring Break travel and illness, so materials sourcing and construction moved more slowly and firmware work was limited. Mario’s work on RPi5 SSH, fan sourcing, CAD reference, and CI keeps backend and tooling on track, but we are still dependent on materials (including replacement fan parts after our previous provider was banned/restricted by CMU through Amazon) and on coordinating with the wood shop for construction. Mitigation: we are splitting work so that Mario drives RPi/backend and CI while Cindy leads materials, wood shop coordination, and once parts arrive sensor/actuator wiring on the ESP32s. We will prioritize getting one subsystem (e.g., access control or one room’s environmental node) wired and talking to the backend so we can validate end-to-end even if full house assembly lags slightly.

Design Changes
No design or scope changes this week. The three-subsystem architecture (access control, environmental/HVAC, lighting), MQTT-based backend, and physical house layout remain as in the Design Report. The new CAD model in FreeCAD is a reference only and does not change the design; it clarifies the intended layout (walls, partitions, windows, door openings) for construction.

Schedule Updates
Cindy is behind schedule due to travel and illness; Mario is on schedule with infrastructure and CI. As a team we are slightly behind on physical construction and firmware bring-up but ahead on backend tooling and coverage. The Gantt and milestones are unchanged; we will reassess after the wood shop discussion and once replacement fan parts and sensor/actuator orders arrive. Next two weeks: complete RPi5 backend install and first ESP32 communication tests (Mario), secure materials and wood shop support and begin wiring when parts are in hand (Cindy).

Progress & Technical Highlights

• Raspberry Pi 5 SSH: Mario set up headless SSH access for the RPi5 so the team can install and test the backend (FastAPI, MQTT broker, TimescaleDB) and run communication tests with ESP32 nodes without a monitor/keyboard.
• Fan and procurement: Mario identified replacement sources for the 30×30×10 mm 5 V brushless fans and related items after the previous provider was banned/restricted by CMU through Amazon, keeping HVAC and physical demo procurement on track.
• CAD reference for house model: Mario produced a FreeCAD model of the house structure (exterior walls, internal partitions, window and door openings) as a construction reference. FreeCAD had a steep learning curve, so the model is intentionally basic; further CAD refinement is deprioritized in favor of building and wiring the physical model.
• CI pipeline and code coverage: Mario completed the GitHub Actions CI pipeline for the repo and reached the target of >50% code coverage, with backend linting and tests in place to catch regressions during integration.
• Materials and physical demo: Cindy obtained potential material for room walls from TechSpark and is planning to coordinate with the wood shop to build the house structure. Progress was limited by post–Spring Break travel and illness; next step is to confirm wood shop support and, once sensor/actuator parts arrive, to hook them up to the ESP32s and begin subsystem validation.

Mario’s basic CAD model for the demo structure

Most Significant Risks & Mitigation
The most significant risk we’re worried about is the timely construction of the physical demo structure. Spring break and exam schedules delayed some  progress, and there’s uncertainty regarding the sourcing of wood panels needed to assemble the house frame. To mitigate this, we’re just going to advance as far as possible with subsystem wiring, CAD/paper layout, and simulation testing if structural materials remain delayed. Additionally, we remain ready to fall back on a more modular demo setup (individual sensor boards and actuators on breadboards) if assembly cannot be completed on time. Another managed risk is adapting the communication protocol as we transition fully to MQTT from Redis; extensive documentation and incremental backend code changes ensure we can revert or patch as needed without service downtime.

Design Changes
A notable change this week was the migration of our backend communication method from Redis streams to MQTT, prompted by reassessment of system complexity and scalability. This reduces architectural overhead and improves reliability, but requires updates to documentation and firmware integration. Cindy also formalized the addition of PID-based HVAC temperature regulation, expanding the temperature subsystem to actively control environmental comfort, not just passive sensing. These design shifts (reflected in the team Design Report and Gantt chart) incur temporary setup costs, additional research, code adjustment, and test cases, but are mitigated by the modularity of our codebase and the incremental implementation process that allows feature toggling and isolated system testing.

Schedule Updates
We remain on schedule relative to our original plan, with adjustments for spring break and exam periods reflected in the revised Gantt chart. The updated schedule now includes dedicated blocks for procurement of demo materials, CAD modeling and layout, backend MQTT migration, and integration of PID regulation control. Next week’s focus will be finalizing the house structure, beginning frame construction, and ramping up code coverage and automated CI/CD tests. Key milestones for sensor and actuator wiring, Raspberry Pi backend verification, and software stack documentation are also updated.

Progress & Technical Highlights

• Design Report Completion: Both Mario and Cindy contributed to the team Design Report (docs/Team_A4_Belmonte_Chen_design_report.pdf), with Mario focusing on Implementation, Testing, Buy List, and scheduling; Cindy on architecture, requirements, and trade studies. Documentation now clearly describes subsystem interaction through MQTT and backend integration, as well as justifies design trade-offs.
• Buy List & Sourcing: Mario compiled a complete buy list and pricing plan for physical demo components, and began vendor research/contact for panel materials and electronics.
• CAD & Demo Prep: Cindy started CAD modeling for the house but shifted to detailed paper layouts after facing software challenges, ensuring continued progress on demo structure planning. Efforts are underway to source wood panels and begin assembly.
• Schedule Management: Mario revised the Gantt chart for updated phase breakdowns and integration milestones, accounting for timeline adjustments imposed by spring break.
• Parts Handling: RFID modules and the new Raspberry Pi 5 were secured in Hamerschlag lab, ensuring early safeguard of key hardware.
• Communication Migration: Backend protocol shifted to MQTT for streamlined message delivery and future scalability.
• Documentation: Major architectural decisions, software trade-offs, and system implementation details are now formalized both in the GitHub repo and the team Design Report.

Part A (Cindy): Global Factors
The smart building platform we are developing addresses needs that extend beyond a local academic setting by providing centralized monitoring and control of access, lighting, and environmental conditions through a web-based interface. Building management and access control are global challenges faced by organizations such as offices, residential complexes, and shared workspaces. In many parts of the world, building infrastructure contain multiple systems that are difficult to manage, alter, or upgrade. Our design emphasizes adaptive hardware nodes and a web-based control system so that similar architectures could be deployed in different environments/rooms without requiring specialized local software installations. Also, because the system uses widely available components such as Wi-Fi-enabled microcontrollers and standard web technologies, it can be adapted for use in buildings across different geographic regions where centralized control and remote monitoring are desirable.

Global considerations also include differences in user expertise and infrastructure reliability. Our design prioritizes a web-based dashboard that can be accessed from common devices such as smartphones or laptops, reducing the need for specialized training or technical knowledge. Additionally, the use of lightweight communication protocols and distributed sensing nodes allows the system to function even in environments where computing resources are limited. Features such as automated lighting control and temperature regulation also support global energy conservation goals by reducing unnecessary power consumption.

Part B (Mario): Cultural Factors
Cultural considerations play somewhat of a role in the system design. Recognizing the diversity of beliefs, practices, and social expectations around privacy and communal living, the system features flexible access policies and transparent event logging. For example, the dashboard can be localized or adapted for users from different language backgrounds, and our policy management allows for nuanced permissions in households, dorms, or co-working spaces. Our open-source documentation supports cultural adaptation, allowing communities to modify security and comfort parameters to suit local customs. Additionally, we took special care to ensure the audit log of access events is visible to users, not just administrators, fostering a sense of shared trust and responsibility, which aligns with community-driven values.

Part C (Mario): Environmental Factors
Environmental impacts are a core design consideration. The lighting control subsystem employs daylight harvesting and PID temperature regulation to optimize energy use, reducing electricity consumption by dimming artificial lights when ambient sunlight is sufficient and maintaining thermal comfort with minimal HVAC usage. The system’s modular architecture promotes upgradeability and longevity. This means components can be replaced rather than entire units discarded, minimizing e-waste. Documentation encourages users to calibrate energy-saving features in diverse ecological settings and provides tools for analyzing environmental data, to support sustainability both locally and globally.

Most Significant Risks & Mitigation

The main risk this period is uneven bandwidth during the transition from Design Review to implementation. Mario was focused on exams and had limited deliverable output, while Cindy completed the Design Review and hardware prep.

Mitigation: we are dividing work clearly. Cindy is leading hardware bring-up and firmware deployment on the ESP32 nodes; Mario is owning CI pipeline coverage, MQTT evaluation, and Raspberry Pi familiarization. Spring break may push some of Mario’s deliverables into the following week but we’re still ahead of schedule overall, so we’re not adjusting milestones yet.

 

A second risk is scope creep around the message broker. After a professor’s feedback that Redis may be overkill, we’re considering MQTT as a simpler alternative.

Mitigation: We will treat MQTT as an optional/alternate path rather than a full swap so that hardware integration and latency validation can proceed on the existing stack. Any MQTT adoption will be phased in so it does not block bring-up.

 

Design Changes

As mentioned, we are evaluating MQTT as an alternative to Redis for device-to-backend messaging. No other design or scope changes this week. The three-subsystem architecture (access control, environmental, lighting) and validation strategy remain as presented in the Design Review.

 

Schedule Updates

We completed the Design Review and received key hardware (Raspberry Pi 5, RFID modules, sensors). Parts are inventoried and stored in the designated lab storage. We remain ahead of schedule. The Gantt chart showed that we were in the backend/RPi/MQTT setup and early implementation; we instead had a full stack in place and have now finished the Design Review and hardware prep. The next two weeks are allocated to hardware bring-up (Cindy) and CI/MQTT/RPi work (Mario). Spring break may shift some of Mario’s deliverables (e.g., 50% coverage, MQTT exploration) by about a week; we will reassess after break if needed.

 

Progress & Technical Highlights

• Design Review: Architecture was consolidated into clear presentation materials, including updated system block diagrams for all three subsystems (lighting, access control, environmental). Implementation, testing, and project management plans were formalized, and the task schedule was reorganized into a Gantt chart with clear firmware/hardware and backend/frontend division. Faculty and peer feedback from the proposal (scalability, safety, integration) was incorporated into the design narrative and validation approach.

• Hardware readiness: Raspberry Pi 5, RFID reader modules, and sensors were received, inventoried, and secured in the Hamerschlag lab storage. Datasheets were reviewed, GPIO pin assignments confirmed, and wiring layouts planned for each node. Firmware structure was aligned with the physical hardware so that flashing and subsystem validation can start as soon as wiring is complete.

• Technical positioning (no direct code deliverables): CI/CD approach was refined in line with coverage practices from another course, with the goal of applying that to the monorepo. Redis vs. MQTT was identified as a design trade-off to resolve in the coming weeks; MQTT will be explored as an alternate broker without blocking current integration work.

Planned next steps: Hardware bring-up and firmware deployment (wiring ESP32s to RFID, relay, and dimmer; validating sensor reads and actuator control; debugging firmware and ESP32–RPi communication). In parallel: push toward ~50% test coverage on the repo, evaluate MQTT integration path, and dedicate 2–3 hours to RPi 5 setup and CLI familiarization.

Most Significant Risks & Mitigation
The primary risk this week shifts from architectural uncertainty (now resolved) to hardware integration reliability. With the full software stack now implemented, the next phase requires all three ESP32 subsystems to communicate reliably with the backend over Wi-Fi via WebSocket. If any node experiences connectivity issues, dropped packets, or firmware crashes, it could delay our end-to-end validation timeline. Our mitigation plan is as follows: (1) the frontend dashboard already includes local fallback logic so the UI remains fully demonstrable even if a hardware node is offline, and (2) we will bring up one subsystem at a time (access control first, then environmental, then lighting) rather than attempting all three simultaneously, isolating integration failures to a single node.

A secondary risk is meeting our defined latency targets (<500 ms for access control, <300 ms for manual dimmer, <1 s for daylight harvesting) once real network hops and TLS overhead are introduced. We plan to start collecting baseline latency measurements immediately after firmware flashing to detect any performance gaps early, giving us time to optimize before the demo.

Design Changes
We expanded the project scope from two subsystems (access control + environmental sensing) to three by adding a full intelligent lighting control subsystem with daylight harvesting. This decision was made because the lighting hardware (TEMT6000, PWM dimmer, 4-channel relay) was affordable and the architectural pattern mirrors the existing subsystems closely, allowing us to demonstrate a more compelling “smart building” narrative at low additional risk. The backend, frontend, firmware structure, and documentation have all been updated to reflect this addition.

Schedule Updates
We are currently ahead of the original schedule. The Gantt chart called for backend environment initialization, MQTT schema definition, and initial Raspberry Pi setup this week. Instead, we delivered a nearly complete full-stack implementation. This puts us in a strong position to dedicate the coming weeks entirely to hardware integration, testing, and optimization rather than splitting time between software and hardware.

Progress & Technical Highlights
This was our most productive week to date. The repository went from a bare initial commit to a fully structured monorepo with 10 merged pull requests spanning every layer of the system. Highlights include:

• A working FastAPI backend with 12+ REST/WebSocket endpoints for sensor ingestion, lighting control, and device management
• A production-ready React dashboard with real-time analytics, access control management, lighting controls, and admin authentication
• Three fully scaffolded PlatformIO firmware projects with defined GPIO assignments, communication protocols, and local control loops
• Docker Compose infrastructure (TimescaleDB with hypertables + Redis) and a GitHub Actions CI pipeline
• Comprehensive documentation: API reference, architecture guide, setup/troubleshooting guide, user guide, and testing strategy
• AI-assisted development was used extensively (GitHub Copilot agent and Cursor) for code generation, with all output reviewed, bug-fixed, and integrated by Mario. Cindy independently finalized the firmware architecture, system specification diagram, and Design Review materials.

Part A (Mario): Public Health, Safety, and Welfare
Safety-wise, one of the main deliverables for this project is the access control subsystem (RFID + electromagnetic door lock). It’s supposed to mimic the entrance of a house and provides security for those within by ensuring that only authorized people can enter. Even if someone tampers with the ESP32 node, since it has a web-first architecture, the door can’t be actuated without server-side authorization. As for the fail-safe, I’m unsure of whether it should default to locked or unlocked in case of a fire or an attempted break-in.

From a health and welfare standpoint, the environmental monitoring subsystem (BME280 temperature/humidity/pressure sensor) provides real-time indoor climate data with ±0.5°C accuracy. This directly helps better an occupant’s comfort and can potentially detect HVAC failures. The lighting control subsystem with daylight harvesting automatically adjusts artificial lighting to maintain normalized (300 lux) light levels, which research has shown impacts occupant circadian rhythms and psychological well-being. Since the entire system is designed to be remotely operable via a web dashboard, if used for a massive building, this could support building managers in maintaining healthy indoor environments even when they’re away.

Part B (Mario): Social Factors
Our platform’s web-first design philosophy has meaningful social implications. By requiring that all building functions route through a centralized, authenticated web dashboard, we are creating a system that promotes transparency and accountability. Every door access event is logged with timestamps, user ID, and grant/deny reasons, creating an extensive auditable record. In a shared living environment, this could have the fallback of nurturing a feeling of overbearing security.

The dashboard’s policy management interface allows building administrators to define super specific access rules (time-of-day restrictions, per-user permissions), which empowers communities to collectively govern their shared spaces. However, we also realize that such systems can be used for surveillance or discriminatory access control. Our design mitigates this by making the audit log visible to all authorized users and making it use role-based access for the policy engine itself. Culturally, the project reflects a societal shift toward “smart” living environments; we have intentionally designed the UI to be accessible and intuitive (flat design, clear visual hierarchy, real-time feedback) so that it doesn’t create a digital divide between tech-savvy and laymen occupants.

Part C (Cindy): Economic Factors
The smart home system addresses economic factors primarily through energy cost reduction and scalable infrastructure design. The lighting control subsystem’s daylight harvesting feature automatically dims artificial lights when sufficient natural light is detected, directly reducing electricity consumption. Studies estimate that daylight-responsive dimming can reduce lighting energy use by 20-60%, which translates to meaningful cost savings for building operators — especially at commercial scale.

Our technology stack was selected with economic efficiency in mind: we use open-source software throughout (FastAPI, React, TimescaleDB, Redis, PlatformIO) with zero licensing costs, and commodity hardware (ESP32-S3 at ~$7/unit, BME280 at ~$3, TEMT6000 at ~$2). The total bill of materials for our prototype is under $80, demonstrating that intelligent building management is achievable at a fraction of the cost of proprietary commercial solutions (which can run $10,000+ for a single building). By publishing our system under the MIT License and documenting a reproducible architecture, we contribute to the broader ecosystem of affordable building automation, lowering the economic barrier for small property owners, educational institutions, and developing communities to implement professional-grade building controls.

Most Significant Risks & Mitigation
The most significant risks to the success of our project are meeting our latency targets for real-time control and monitoring, maintaining reliable concurrency, and ensuring that the secure device provisioning and the permission revocation pipeline does not introduce unacceptable delays. We defined concrete, quantitative stress, latency, and security tests so performance and failure modes can be detected early. Our contingency plan is to scale down the number of simultaneously active devices and features during the demo if performance becomes unstable, and to temporarily relax non-critical features so that real-time access control and monitoring remain within specification.

Design Changes
Since our early discussions, we made a deliberate design change to narrow the MVP scope and system focus to environmental sensing and access control (temperature sensor and door lock). This change was necessary to reduce technical risk and ensure we can reliably meet latency and security requirements within the semester schedule.

Schedule Updates
We have established a structured Gantt chart schedule that breaks the project into concrete, week-sized tasks. At this time, the team is on track with the initial schedule as we move from the proposal phase into early communication protocol definitions and hardware setup.

Progress & Technical Highlights
We have successfully transitioned the project from a collection of isolated sensors to a cohesive, web-first building control platform. We are particularly proud of our high-level block diagram, which clearly defines the interface boundaries between our ESP32 nodes, the Raspberry Pi gateway, and the web-based backend services.