Team Status Report for 2/21/2026

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.