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.