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.