Cindy’s Status Report for 4/4/2026

Contributions:

Additional hardware procurement: Ordered the remaining hardware components needed for the next phase of integration, including parts for actuation and lighting/fan control, so we can continue expanding beyond the interim demo setup.

Node compatibility stress testing: Continued testing each ESP32 node under more realistic room level combinations to make sure the hardware choices are compatible before final integration. This includes checking whether multiple sensors can share one ESP32 reliably and whether the same node can also control an additional component without causing wiring or communication issues.

Firmware and hardware validation under combined loads: Extended bringup work from basic one component tests into more integrated node testing so that each room controller can support the intended mix of sensors and actuators. This is helping identify which component combinations are practical for the final house and which require different wiring or purchased hardware.

Final demo house fabrication: Continued designing and laser cutting the final version of the demo house so the hardware can be mounted in a cleaner and more realistic room-by-room layout instead of only being tested on the bench. Currently, I am modifying the one room/box shape into a full house design.

MCU packaging and room integration planning: Started organizing how each MCU and its attached wiring will be packaged into a more compact room-level assembly. Because the current wiring and breakout setup is not compact enough to mount neatly in the house, this week’s work also involved planning how to repackage the ESP32 nodes, sensors, and connections into smaller units that can be attached within each room.

Software-hardware integration planning: Reached the stage where the project now needs integration between the working hardware nodes and the software stack. In addition to validating the physical nodes, we are now focused on preparing for integration so the ESP32 room controllers, Raspberry Pi/backend software, and final house hardware all operate together as one system.

Is your progress on schedule or behind?

On schedule for this phase. The interim demo nodes are already functional, and this week’s work has moved the project from isolated prototype testing toward full-house integration. Ordering additional components, validating compatible node configurations, beginning fabrication of the final demo house, and preparing for software-hardware integration all support the transition into the next stage of assembly.

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

Finish compatibility testing for room nodes: Complete stress testing of which sensors and actuators can reliably share a single ESP32 so the final room node design can be fixed with confidence.

Continue final house fabrication: Finish laser cutting and assembling the final demo house structure so it is ready to receive the hardware.

Package hardware into room-ready modules: Rework the current loose wiring and MCU setups into more compact assemblies that can be mounted cleanly inside each room of the house.

Integrate new hardware components as they arrive: Bring the newly ordered parts into the test setup, verify that they work with the existing ESP32 nodes, and incorporate them into the expanding full house hardware design.

Begin software-hardware integration: Start connecting the tested room nodes to the backend flow so the hardware and software are no longer being validated separately, but instead as one combined system.

Cindy’s Status Report for 3/28/2026

Contributions:

Demo MCU wiring and bring-up: Wired the interim demo ESP32 nodes and verified the hardware connections for both subsystems. One ESP32 was set up as the environmental node with the BME280 and BH1750 sensors, and a second ESP32 was set up as the access-control node with the RC522 RFID reader, relay, and solenoid lock.
Firmware testing and validation: Wrote and uploaded test programs for each stage of bring-up to isolate problems safely. This included I2C scanner and sensor-read code for the BME280/BH1750 node, RC522 only test code for the RFID node, relay-only test code, and a combined RFID + lock control program using authorized card UIDs.
Hardware debugging and troubleshooting: Worked through wiring and boot issues during bring-up, including identifying incorrect or unstable breadboard/sensor connections, verifying the correct ESP32-S3 pin usage, confirming relay operation before attaching the lock, and testing the lock with proper relay switching and protective diode placement.
Interim demo assembly: Brought the demo hardware to a working state so that both main node types are now functioning: the sensor node successfully reads environmental data, and the door node successfully reads authorized RFID cards and actuates the lock.
Physical model construction: Built the model house structure for the project demo and prepared it as the physical platform for integrating the working nodes.
Planning for expansion: Continued organizing how the rest of the hardware will be extended across additional rooms so the remaining sensors, controls, and room-level components can be added consistently to the full house system.

Is your progress on schedule or behind?

On schedule for this phase. The interim demo hardware is now functioning, both ESP32 nodes have been wired and tested successfully, and the model house has been built. That puts the project in a good position to move from isolated bench testing into broader physical integration across the house layout.

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

Continue hardware integration for additional rooms: Expand beyond the current demo nodes by wiring and testing more room hardware so the system better reflects the final multi-room design.
Complete the full house build-out: Finish the remaining physical house construction and integrate the electronics cleanly into the full model.
Refine and extend firmware bring-up: Adapt the working demo code into a more complete multi-node setup and verify that the same testing approach works reliably as more devices are added.
Document repeatable hardware setup: Record the final wiring, power, and configuration choices used for the demo nodes so the team can reproduce them safely while finishing the rest of the house.

Team Status Report for 3/21/2026

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.

Cindy’s Status Report for 3/21/2026

This week, my main focus was bringing up the hardware for one room node (under github: smartHome/firmware/room-node). With the specifications, I reviewed the cpp code, which initializes the environmental and light sensors, manages Wi-Fi and WebSocket connectivity, periodically transmits room telemetry, and processes incoming control commands for the dimmer, fan, and relays. Full functionality still needs to be confirmed through hardware and integration testing when we finish backend set up on the Raspberry Pi.

Additionally, I continued working on the construction of our demo from the CAD design. Here are the specifications and parts (found/using + still need to purchase):

Overall Dimension

  • Overall exterior footprint: 18.0 in × 18.0 in
  • Wall height: 10.0 in
  • Maximum overall height: about 12.0 in
  • Outer wall thickness: 0.25 in
  • Inner wall thickness: 0.25 in
  • Base thickness: 0.375 in to 0.50 in
  • Interior clear footprint: 17.5 in × 17.5 in

Room Dimensions

  • Living Room: 9.0 in × 17.5 in
  • Kitchen: 8.25 in × 8.5 in
  • Bedroom: 8.25 in × 8.75 in

Window Dimensions

  • Viewing opening width: 2.5 in to 3.0 in
  • Viewing opening height: 8.5 in to 9.0 in
  • Bottom clearance from floor: 0.5 in to 0.75 in
  • Top structural margin: 0.5 in to 1.0 in

Door and Lock Dimensions

  • Door opening: 3.0 in × 5.0 in
  • Door leaf: 3.25 in × 5.25 in
  • Reserved lock mounting zone: at least 4.0 in wide
  • Door lock size reference: about 2.1 in to 2.6 in long, 1.65 in to 1.7 in wide, and 1.1 in deep

Electronics / Wiring Clearance

  • Small wire-routing holes: 0.25 in diameter
  • Main service hole: 0.5 in diameter
  • Optional under-base cavity: 1.0 in to 1.5 in

The “window” will be the only part of the physical model that I still currently cannot find materials for, and I plan to order acrylic sheets that provide a clear view into the demo house rather than function as a realistic window.

I am currently on schedule/catching up from next week, and I hope to have the living room sensors/parts wired to the ESP32 first, then attached to the actual demo to check for fit and determine if anything needs adjusting.

 

Cindy’s Status Report for 3/14/2026

This week, my main focus was on finding materials and starting construction of the physical demo. I have currently obtained potential material for the room walls from TechSpark but need to speak to the wood shop to construct the house. Additionally, I am hoping to convert my partner’s CAD model into real measurements and start setting out parts for construction. Unfortunately, due to traveling back from Spring Break/an illness that lasted through the week, I was unable to make great progress.

I am currently behind schedule, but I hope to receive the sensor/actuator parts and get them hooked up to the ESP32. With the backend expected to be working by next week (from my partner), I also expect to wire up a subsystem to be integrated with that.

Cindy’s Status Report for 2/28/2026

My focus this week was completing significant portions of our design review paper and refining the documentation of our system architecture, design trade studies, and implementation details. A large portion of my time was spent translating the work from our design review materials and project documentation into the structured sections required by the report template. In particular, I worked on writing and organizing the Architecture, Design Requirements, Design Trade Studies, System Implementation, and Testing sections. This involved clearly describing how the access control, lighting, and temperature subsystems interact through the backend and communication infrastructure. Additionally, I formalized the reasoning behind several design decisions such as sampling rates, PWM configuration, and communication architecture. I also ensured that the report aligns with the updated system design, including the transition to MQTT-based communication and the addition of PID-based HVAC temperature regulation.

During spring break, I began preparing for the physical demonstration of our system by attempting to model the house structure in CAD software. The goal of this model was to design a clear physical layout for the sensors, lighting system, and access control components used – as well as have a physical structure that meets an impressive final demo. However, I found that learning the CAD software and producing a complete model required more time than I was able to dedicate during the break. As a result, I shifted to sketching a detailed paper layout of the house structure. I have also started reaching out to potential sources for wood panels that we can use to construct the physical house frame, so that we can begin assembling the demonstration structure once materials are obtained.

I am currently on schedule. While the CAD modeling progress was slower than expected due to the learning curve of the software, the report writing and system documentation progressed well this week. I was able to complete the report, and the paper layout and material sourcing efforts ensure that progress toward the physical demo will continue.

I plan to continue preparing for the physical demo by finalizing the house layout design, securing wood panels for the structure, and beginning the initial construction of the house frame. Completing these tasks will allow us to focus on integrating the hardware components and validating the full system during the final stages of the project.

Cindy’s Status Report for 2/21/2026

My focus this week was preparing and delivering our Design Review presentation, as well as beginning the transition from planning to physical implementation. A large portion of my time was spent consolidating our project architecture into clear presentation materials, refining our system block diagram to include the updated lighting, access control, and environmental subsystems, and formalizing our implementation, testing, and project management plans. I also reorganized our task schedule into a proper Gantt chart showing work division between firmware/hardware and backend/frontend. I incorporated faculty and peer feedback from the proposal phase, particularly around scalability, safety, and system integration, and translated those concerns into concrete design explanations and validation strategies for the presentation.

We also received several key hardware components this week, including the Raspberry Pi, RFID reader modules, and sensor. I organized and inventoried these parts and began preparing for hardware bring-up by reviewing datasheets, confirming GPIO pin assignments, and planning wiring layouts for each node. I ensured that our firmware structure aligns with the physical hardware configuration so that integration can proceed smoothly once wiring is complete. While I have not yet begun full hardware assembly, the preparation work completed this week puts us in a good position to begin firmware flashing and subsystem validation soon.

Is your progress on schedule or behind?
I am currently on schedule. Completing the Design Review presentation and receiving the hardware were both major milestones, and we are now ready to begin the implementation phase of the project.

What deliverables do you hope to complete in the next week?
My primary goal for next week is to begin hardware bring up and firmware deployment. This includes wiring and testing the ESP32 nodes with the RFID reader, relay module, and lighting dimmer hardware, and validating basic functionality such as sensor readings and actuator control. I also plan to flash and debug the firmware structure I previously outlined, ensuring reliable communication between the ESP32 nodes and the Raspberry Pi backend. Successfully bringing up these components will allow us to begin full system integration and start validating our latency and functionality requirements.

Cindy’s Status Report for 2/14/2026

This week focused on finalizing our Design Review materials and formalizing the firmware architecture for all three ESP32 subsystems (Access, Environmental, and Lighting). I rebuilt the full system specification diagram to clearly partition the Web Dashboard, Raspberry Pi backend, event/data layer, and House Model hardware nodes, explicitly showing sensing → compute → actuation flows and labeled interfaces (Wi-Fi, HTTPS/WSS, I2C, ADC, PWM, GPIO). I expanded our quantitative use-case and design requirements to include detailed latency targets for access control (<500 ms 95th percentile), permission revocation (<100 ms), dashboard updates (<1 s), manual dimmer response (<300 ms), and automatic daylight harvesting (<1 s), and mapped each to a corresponding validation method for the Design Review. I also refined Slide 9 and Slide 10 content to clearly separate buy/build/integrate responsibilities and define measurable pass/fail criteria without overcrowding the slides.

On the firmware side, I defined a consistent monorepo structure under with separate directories. I finalized GPIO assignments, clarified SPI/I2C/ADC/PWM boundaries, and incorporated a local control loop within the lighting node so daylight harvesting remains responsive even if backend latency fluctuates. I also updated the power budget to account for PWM dimming loads and relay-driven devices.

I am on schedule and slightly ahead in terms of architectural readiness. While hardware integration is the next major milestone, the system partitioning, validation strategy, and firmware structure are now clearly defined and review-ready. Next week I plan to flash firmware onto physical ESP32 boards, wire the RFID reader, BME280, TEMT6000, solenoid lock, and relay modules, validate secure WebSocket communication with the backend, generate TLS certificates for device authentication, and begin collecting baseline latency measurements for access control and lighting response.

Team Status Report for 2/7/2026

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. 

Cindy’s Status Report for 2/7/2026

For the past few weeks, after finalizing our project idea and speaking with our TA/FAC, I focused on developing the technical backbone of our proposal with my partner and helped refine the system scope and requirements.

Meeting – Refining Proposal and Discussing Abstract
Date: 1/26/2026

  • Focused on refining and narrowing the use-case requirements
  • Helped converge the project scope to four main high-level requirements
  • Coordinated division of proposal slide responsibilities among the team
  • Discussed how to better position our system as a web-first building control platform rather than a collection of isolated sensors

Meeting – With TA/Faculty
Date: 1/28/2026

  • Walked through the high level block diagram with course staff
  • Refined how we should frame quantitative targets for requirements
  • Received guidance to narrow feature focus for the MVP, especially on:
    • environmental sensing (temperature)
    • access-control functionality
  • Discussed early hardware planning and concerns regarding MVP component choices

For the proposal presentation, I specifically contributed to the tasks and division of labor, the identification of major component parts, and the construction of the Gantt chart schedule. I worked with my teammates to break the project into concrete, week-sized tasks, assign clear ownership for each task across the team, and ensure that all major technical areas (embedded firmware, backend/web infrastructure, hardware integration, and system integration/testing) were covered without overlap or gaps. I also helped decide between the major hardware and software component parts needed for the MVP (pros vs. cons), and organized these tasks into a structured Gantt chart.

For the upcoming week, I plan to complete the following:

  • Help convert the proposal level solution approach into a clearer subsystem-level block diagram
  • Assist with:
    • Defining interface boundaries between embedded nodes and backend services
    • Early communication protocol definitions
  • Set up initial hardware parts as soon as possible