Erika’s Status Report for 04/12/2025

Progress this Week:
This week, I redesigned the model house structure to incorporate finger joints. After observing structural weaknesses during our interim demo, I realized that the original flat-edge design was not sturdy enough, especially when using acrylic sheets for the inner walls that lacked sufficient support. I also met with my team to finalize where we want to include the electronic components so I can include holes for those wire feedthroughs. To address this, I modified the CAD models for all the walls to include finger joints and feedthrough holes for better structural integrity and easy integration. I then regenerated the corresponding DXF files for laser cutting.

Following these updates, I re-laser cut most of the acrylic and wood sheets. This process included completing the full assembly in CAD to ensure the finger joints fit together cleanly.

Challenges
My progress is currently on schedule. While redesigning the house model and re-cutting parts was not initially planned, this adjustment was necessary for the long-term stability and success of our prototype. I have built in buffer time for tasks like this, so I’m confident we are still aligned with our project timeline.

We also placed a lot of orders this past Wednesday, so I hope those arrive early next week so we can continue wrapping up the final pieces of our project.

Next Steps:

  • Finish laser cutting the remaining few acrylic sheets

  • Assemble the redesigned model house

  • Begin integrating the LLM chatbot using the Ollama setup that Maya worked on

  • Set up wiring and begin coding the LED ring to simulate the passage of time in our simulated reality environment (where 1 simulated day = 5 minutes in real time)

Team’s Status Report for 04/12

Risks

  • We are training LSTM/CNN models based off of data polled from sensors.  Retraining the model every request (if the cache fails) can cause lag

  • Home Assistant API latency spikes can delay forecasts. Plotting charts via matplotlib adds overhead (200–300ms)

  • Caching logic failing silently if timestamps are misaligned
  • Infeasible LP results due to overlapping constraints or underforecasted solar

  • LP objective may optimize cost but ignore user experience (e.g., clustering devices)

  • Forecast errors can propagate into LP, yielding poor schedules

Changes

The initial approach used an LSTM network to forecast solar generation based on time-series data from sensor.maya_solar_panel. Main challenge was high latency due to recurrent nature and sequential computation and overfitting on short term trends rather than daily cycles. Transitioned to a 1D Convolutional NN. CNNs capture short-term temporal correlations ( sunrise to peak curve) better.

Progress

  • Successfully polled data from all sensors into backend
  • CNN model produces realistic solar forecasts aligned with production hours

  • Performed testing on API response times

Verification/Validation

  • Used curl requests to profile API timing in the terminal while polling data from sensors

  • Unit tested LP constraints to ensure feasibility and logic correctness
  • Compared cached vs. uncached outputs for CNN model for correctness and stability

  • Compared forecast vs. actual solar power to assess prediction alignment
  • To validate the 15% energy savings, we’ll compare historical baseline energy usage (from fixed schedules) against SmartWatt’s optimized schedules using the same input conditions. Using sensor data (from sensor.maya_fan_power, sensor.maya_solar_panel), we’ll simulate both scenarios over a 1–2 week period and calculate daily energy costs. The optimized case will use CNN-based solar forecasts and LP scheduling. If the average cost reduction exceeds 15% compared to the baseline, the savings target is met.
  • To verify the robust assembly of the house, I will carry the house around and apply reasonable force to ensure it will remain intact during the demo.
  • To validate the integration of the hardware components with the house, I will perform a fit test with the interior components. I will ensure that all feedthrough holes are wide enough and that the components can be neatly and securely placed inside their respective rooms.
  • For validation, we plan to conduct user testing sessions where participants interact with the model house and dashboard to simulate their household energy consumption. This will help us evaluate whether SmartWatt creates a coherent and immersive experience. We will analyze user feedback to determine if the system effectively communicates the intended purpose of the project, the scaled energy usage and passage of time, and feels intuitive to interact with.

 

Anya’s Status Report for 04/12

Accomplishments

  • Integrated real-time sensor polling and displayed it on the dashboard

  •  Developed a responsive FastAPI + HTMX dashboard to display live sensor values

  • Implemented Chart.js charts that auto-refresh every few seconds without full page reloads

  •  Latency about 10s for the API calls, page refreshes every 30s

Progress

Reduced latency by introducing in-memory caching for the a CNN solar forecast endpoint

  •  Forecast results are now cached and refreshed every 10 minutes, eliminating redundant model retraining on every request

  • Slightly behind progress, need to integrate all the charts in the same app with routing
  • Verification

Performed basic verification of the CNN forecasting model to ensure it meets the intended design requirements for solar prediction accuracy.

  • Input Feature Sanity Checks:
    Verified that time-series input includes correct power, sin_hour, and cos_hour features, resampled to 15-minute intervals.
    Resampling was validated via debug logging (len(df), delta distributions).

  • Window + Horizon Coverage:
    Model was trained on sliding windows (e.g., 48 steps = 12 hours) with a 24-step forecast horizon. These parameters were confirmed to provide full diurnal coverage and enough context for trend learning.

  • Envelope Alignment Verification:
    The daylight envelope was implemented and centered around peak solar generation (13:00–14:00) to prevent unrealistic output at midnight. Forecasts before and after masking were compared to confirm correction.

  • Polling Interval Consistency:
    The system pulls data using HA/api/history/period endpoint. I confirmed that sensors such as sensor.maya_solar_panel, sensor.maya_fan_power, sensor.maya_fan_voltage, and sensor.maya_fan_current are polled with sufficient granularity — typically every 5–10 minutes.

  • Each response is parsed to validate:

    • state is numeric and finite

    • last_changed timestamps are increasing and consistent

    • There are no large gaps in time , > 1 hour)

  • Resampling Debug Logs:
    Added internal logging to capture the number of raw and resampled datapoints. This ensures the model always receives enough sequential history for the sliding window.
    Used interpolation (.interpolate()) on the resampled time-series to ensure continuity in data, even if occasional values are missing from Home Assistant.

  • latency tests via time curl http://localhost:5051/api/endpoint to make sure the dashboard refresh updates meet design and usecase requirements

Next Steps

  • Test LP behavior under forecast uncertainty

    • Run LP with low vs. high solar predictions

    • Assess how schedules shift and whether they violate any constraints

  • Stress-test LP under edge-case constraints

    • Zero solar availability

    • Multiple high-power devices requiring overlap

    • Very short vs. very long runtime constraints

Test LP reactivity to live data

  • Feed in updated solar forecast every hour

  • Ensure LP returns updated schedules quickly (<2 sec)

 

Maya’s Progress Report for 2025-04-12

Progress This Week:

  1. Ollama Instance Deployment:

    • Set up an Ollama instance running the DeepSeek-R1-8B model for Erika to use.

    • This model supports reasoning which makes it very good for our usecase
    • Deployed it behind the existing reverse proxy with token verification for secure access.

    • We can access it both over the cli and using the api

  2. Python Backend Development:

    • Continued development of the Python backend to add more features and enhance its functionality.

    • Extended API endpoints and improved data handling for integration with Anya’s code and Home Assistant.

  3. Finalized Components
    • Finalized and purchased components needed for the final house, planning to install the moment the house is ready on Erika’s end

 

As the project enters the verification phase, I am planning the following tests to ensure subsystem reliability and accuracy:

  1. Electronics Subsystem Verification:

    • Conduct repeated tests on the power monitoring electronics.

    • Measure the accuracy of power draw readings under various loads (fans, motors, lights, etc.).

    • Check the robustness of the sensor communication and responsiveness of the system to rapid changes in load.

    • Use comparison against known reference measurements (multimeter and calibrated loads) to verify sensor accuracy.

  2. Backend and Infrastructure Verification:

    • Perform functional tests on the backend APIs to ensure correct data logging, error handling, and performance under stress.

    • Test authentication mechanisms, API response times, and data integrity between the Ollama instance, backend, and Home Assistant integration.

    • Simulate prolonged operation to evaluate system stability and resilience.

Maya’s Progress Report 2025-04-05

  1. Python Backend Development:

    • Began development of a new Python backend designed to log data and facilitate smooth communication between Anya’s code and Home Assistant.

    • Established initial framework for data collection and device interaction.

  2. Faculty Check-In:

    • Had a check-in meeting with the project professors to review current progress and gather feedback for the next stages.

  3. Hardware Integration Planning:

    • Developed a plan to integrate smart hardware components into Erika’s model house.

    • Identified key connection points and strategies for aligning physical devices with the model infrastructure.