How UC Santa Cruz Students Are Using EdgeLake and AI to Build a Smarter, Self-Sufficient Home
- Project Advisor: Dr. Roy Shadmon, AnyLog
- Students: Harsh Ranjan, Dean McCulloh, Swadhi Sathish Kumar
- Faculty Advisors: Dr. Patrick Mantey & Dr. Richard Julig, UC Santa Cruz
Homes are becoming their own energy systems, evolving from passive consumers of electricity into increasingly self-sufficient microgrids. Solar panels generate power, batteries store it, and appliances and critical health devices depend on it. During an outage, understanding how much energy is being generated, how much remains stored, and what must be prioritized becomes essential to extending availability and protecting critical systems. At the same time, a changing climate and an aging electrical grid are making outages more frequent, longer, and more consequential, particularly as wildfires, extreme weather, and other natural disasters place greater strain on critical infrastructure.
As homes take on greater responsibility for producing and storing their own energy, they must also take on the responsibility of managing it. A home microgrid must continuously monitor and respond to changing conditions, intelligently balancing available energy, critical needs, and everyday use to preserve as much normalcy and quality of life as possible. But that management cannot become another job for the homeowner. When the grid is down, or communications are disrupted, the microgrid must still be able to monitor itself, preserve critical loads, optimize limited energy, and keep the home operating safely.
For example, a home may show that it is drawing power from its battery, but that alone does not explain what is using the energy, whether the load is essential, or how many hours of runtime remain. Appliance-level intelligence adds that context by identifying where energy is going and how changing certain loads would affect battery runtime. This becomes especially important during an outage, because any dependency on cloud-based analytics will fail at exactly the moment it’s needed, due to the very disconnect the system exists to survive.
This requires an edge-based operational platform that keeps data, storage, processing, and intelligence within the environment where the physical systems operate. Just as a microgrid cannot depend on the electrical grid during an outage, its ability to understand and manage itself cannot depend on continuous access to external platforms such as the cloud. Our vision is to make the microgrid of the future simple to operate, autonomous in how it manages energy, and resilient when the systems around it are not, so it continues to work when we need it most.
The Architecture
The microgrid constraint came first: managing, accessing, and using home energy data could not depend on any external service. During a grid or internet outage, the microgrid must continue monitoring local energy conditions, guiding load decisions, and supporting the home’s operation without interruption.
EdgeLake provides one local operating environment
EdgeLake is a lightweight software agent that runs on local hardware, from a Raspberry Pi or mini PC to an industrial server. A home can start with one device and add nodes as new sensors are added and more storage, processing power, or redundancy is required.
Together, these nodes present the home’s distributed data, compute, storage, and services as a Single System Image. The Microgrid Manager application, AI agents, and other applications access all the data and home metadata through one API, without needing to know where data is stored or where a model is running.
Without EdgeLake, every battery, inverter, meter, sensor, and automation platform would require a separate integration, data pipeline, and database. A cloud-based alternative would also introduce recurring data-transfer and storage costs while making essential functions dependent on internet connectivity that may be unavailable during the very outage the system is designed to manage. EdgeLake replaces this complexity with one local platform that operates inside the home and remains available during the actual outage.
Three sources give the system its picture of the home
Solar Assistant runs on a small computer on the home network and speaks directly to the inverter and battery system. It measures PV output (electricity produced by a solar panel system) and battery state of charge, and publishes them over an EdgeLake-managed MQTT broker on the LAN. This is ground truth on the generation and storage side, and it’s what makes runtime forecasting a real number rather than a notional one.
Home Assistant is the local automation platform and the control surface. It reports state directly for connected devices and sensors and provides a vendor-neutral place to act. It runs entirely on the home network and needs no cloud account, which keeps the architecture honest and entirely at the edge.
A revenue-grade eGauge meter instruments the house at panel level, reporting real power for every subpanel every six seconds, plus current on the utility tie. A utility tie is the electrical connection between the home’s microgrid and the external utility distribution system. Measurements at this point show how much power the home is importing from or exporting to the grid, and provide important information about the home’s operating condition. Combined with inverter or transfer-system status, these measurements can also help determine when the home has transitioned from grid-connected operation into an islanded state. That tie current is the tell. The instant the house islands, the system knows, without asking anyone.
Local weather and solar energy capture complete the input set.
EdgeLake manages the data layer
Readings stream through Kafka into EdgeLake running on an edge device inside the house. EdgeLake automatically derives schemas directly from the incoming JSON, so adding a new sensor, or an entirely new source, is as simple as publishing the data stream to EdgeLake.
As data is ingested across edge nodes in the home running EdgeLake software, EdgeLake presents that distributed data as a Single System Image. You query the home as if all the data were hosted in a single logical system, through one API, without needing to know which edge nodes host the queried data.
There is no upload step. There is no cloud round trip. All the data is hosted and managed entirely inside the house, so no third party ever holds a minute-by-minute record of when the family cooks, showers, and sleeps. Privacy here is not a policy that can be rewritten next quarter. It is a property of the architecture.
Fusion is where the value appears
When a user needs to know information, such as how many energy hours remain or are being utilized, they don’t need to know which edge node hosts the relevant data. They simply submit the request to any node running EdgeLake, and EdgeLake manages the query planning and distribution automatically, whether the data is hosted on a single node or fragmented across a thousand nodes. The user always gets a complete result set, as if the data were hosted in a single cloud database.
The Research Layer: Adding Appliance-Level Awareness
Even with connected device data, most of a home’s consumption comes from equipment that is simply a consumer of energy. Without smart plugs, rewiring, or a hardware budget that scales with the size of the house, the system infers appliance activity from the panel signal using a technique called Non-Intrusive Load Monitoring.
Appliances leave electrical fingerprints. A refrigerator compressor surges on inrush and settles into a characteristic cycle. A dishwasher moves through a recognizable fill, heat, and drain sequence. A heat pump ramps rather than snaps. Non-Intrusive Load Monitoring, or NILM, is a technique for estimating the operation of individual appliances from electrical measurements taken at a shared location, such as a whole-home meter or electrical subpanel. Instead of installing a dedicated sensor or smart plug on every appliance, NILM analyzes how the combined electrical signal changes over time and determines which loads are likely responsible for those changes.
A refrigerator compressor, for example, repeatedly turns on and off in a characteristic cycle. A dishwasher progresses through longer heating, pumping, and idle periods. A microwave produces a comparatively short, high-power event, while HVAC equipment can create much longer operating cycles. The system learns these patterns from the home’s panel-level measurements and uses them to estimate appliance activity. That gives the Microgrid Manager visibility into both network-connected devices and conventional electrical equipment that has no digital interface of its own.
Three neural models, one per subpanel
Appliance inference is performed using Bidirectional Long Short-Term Memory (BiLSTM) neural networks running on the home’s edge compute infrastructure. An LSTM is a type of recurrent neural network designed to recognize patterns across sequences rather than evaluating each measurement independently. The bidirectional architecture allows the model to learn relationships throughout the measurement window, which is useful for appliances whose operating state is better identified from a sequence of electrical behavior than from one instantaneous power reading.
Each BiLSTM analyzes a rolling sequence of approximately 100 consecutive measurements sampled every six seconds, representing about ten minutes of recent household activity. Rather than using panel power alone, the model combines electrical demand with contextual features such as recent changes in power, time-of-day and day-of-week encodings, utility-tie measurements, temperature, and solar or irradiance context.
The output is a set of appliance-level probabilities. Instead of selecting one appliance from a mutually exclusive list, each appliance has an independent output, for example, a probability that the refrigerator is on, another for the dishwasher, and another for the microwave. This is important because several appliances can operate at the same time.
Model training strategy
The appliance models are trained using electrical data collected from the home in which they will operate. This matters because NILM is highly dependent on the physical environment: two refrigerators may serve the same purpose but have different compressors, power levels, cycling behavior, installation conditions, and interactions with other loads.
The training pipeline combines the home’s own panel measurements with house-specific appliance signatures and physics-informed labeling rules. These signatures describe expected characteristics such as operating power, cycling behavior, duration, and changes in electrical demand. Those labels are then used to train the BiLSTM models in PyTorch. Samples for which the system cannot establish a sufficiently reliable appliance state are treated as ambiguous rather than forced into an incorrect training label. After training, the models are exported to ONNX so the resulting inference engine can execute locally on the home’s CPU.
The model learns the characteristics of the environment it operates within, this specific house.
This is where most NILM deployments quietly fail. Public datasets were collected in other people’s homes, with other people’s appliances, wired in other people’s ways. Models trained on them transfer poorly, and the failure is not dramatic. It’s a steady drizzle of plausible-looking false detections.
Training is based on weeks to months of local operating history rather than a short calibration snapshot. The amount of useful data differs by appliance. A refrigerator may generate dozens of observable cycles every day, while a dryer, oven, or other infrequently used load may produce only a small number of positive examples over the same period. As additional data accumulates, the training set becomes more representative of different operating conditions, including different times of day, weather conditions, solar-generation levels, and combinations of simultaneously operating appliances.
For this reason, the system is designed to improve as the home’s own history grows, rather than assuming that every appliance can be learned equally well from the same fixed amount of data. Earlier training experiments used tens of thousands of six-second observations collected over several weeks, and the current pipeline can train against a larger archive spanning multiple months. The important quantity, however, is not simply the number of measurements. A model also needs enough examples of the appliance actually operating, which is why model quality differs by load. Frequently operating appliances provide many examples from which the model can learn, while appliances used only occasionally may remain data-constrained even after weeks of household monitoring.
The project therefore combines learned models with physical rules, instead of assuming that a neural network with limited examples will always produce a reliable answer.
So instead of importing someone else’s labels, the solution uses a physics-informed labeler. Every appliance in the house is described by a canonical electrical signature covering steady-state draw, cycling behavior, ramp characteristics, and duty cycle, fitted to the equipment actually present. Those physical models generate training labels directly from the home’s own data.
The house trains its own model.
Rules make the intelligence trustworthy
Model output is never accepted on faith. Every prediction passes through a rules engine enforcing physical and behavioral constraints: mutual exclusion between loads that cannot run at once, time-of-day gates, confidence-based demotion. A model that is confident and wrong gets caught by a rule that knows better.
The Microgrid Manager turns all of it into decisions
A rule-based decision layer evaluates solar production, battery state, household demand, grid availability, device state, and inferred appliance activity together, then produces ranked recommendations for managing energy, especially during outages or stretches of limited solar. Because the logic is explicit, every recommendation arrives with a reason the homeowner can read, question, and overrule.
That matters more than it sounds. An energy system that cannot explain itself will not be trusted at two in the morning on the second day of an outage, which is precisely when it needs to be.
Why This Needs to Happen at the Edge
A residential microgrid becomes most valuable when the utility grid is unavailable or unreliable. The software responsible for understanding and managing that microgrid should not make continuous access to external infrastructure a requirement for its core operation. Keeping the primary monitoring and inference loop at the edge changes that dependency. Electrical measurements are generated inside the home, energy data can be stored and queried locally, and the appliance models can execute on local compute resources. As long as the microgrid continues powering those devices and the home’s internal network, the system can continue describing what is happening inside the house even if the external internet connection is degraded.
The advantage becomes clearer when looking at the information a homeowner actually needs. Knowing that the house is consuming 4.2 kW tells the homeowner the magnitude of demand. Knowing that the battery is at 40 percent, and that a heat pump, water heater, or other large flexible load is contributing to that demand, provides the context needed to make an energy-management decision. The edge architecture therefore supports more than low latency. It keeps the home’s operational intelligence close to the physical system it is responsible for managing.
Disaggregation over a rolling ten-minute window at six-second resolution is a continuous inference problem, not an occasional query. Shipping every window to a remote endpoint and waiting on it is slow when the network is healthy and useless when it is not. Local inference returns in milliseconds, so a recommendation describes what the house is doing right now, not forty seconds ago.
Appliance-level energy data is the most revealing telemetry a home produces. It exposes occupancy, sleep schedules, meal times, medical device usage, and exactly when the house is empty. Keeping that data resident on the property is not a feature bullet. It is the point.
EdgeLake preserves the same cloud-like database experience, the Single System Image, without the data ever being centralized, so nobody has to trust a privacy policy that can be rewritten next quarter.
And there is no per-home cloud subscription, no mandatory account, no service that can be sunset out from under a homeowner who bought a twenty-year system and expected it to last twenty years.
What the Project Has Achieved So Far
The project is being developed against a real residential microgrid at Dr. Patrick Mantey’s home in the Los Gatos mountains. The property combines rooftop solar generation, battery storage, backup generation, a utility connection capable of supporting islanded operation, and several separately monitored electrical panels. That makes it possible to evaluate the system against the variability and complexity of an actual household rather than a simulated laboratory load.
In under a year, the project went from an experimental data pipeline to a working system living in a real house, collecting real data, making real predictions, and surviving real conditions. Progress ran on two tracks that had to meet in the middle.
The first major achievement has been establishing the end-to-end local data pipeline. Household energy data flows from the eGauge meter through Kafka into EdgeLake, running on three nodes at six-second intervals. Solar Assistant streams inverter and battery telemetry into the EdgeLake data layer, and Home Assistant presents dashboards by querying EdgeLake.
The second achievement is appliance-level inference. Three per-panel BiLSTM models have been trained, exported to ONNX (an open standard for machine learning interoperability), and integrated into an inference service that runs on the home’s CPU and writes appliance-state predictions back into the EdgeLake data layer every thirty seconds. The house keeps thinking when nobody is watching. A physics-informed labeling pipeline generates training labels from canonical appliance signatures fitted to the equipment actually installed in this home, not borrowed from someone else’s dataset in someone else’s house.
The third achievement is making the measurements and predictions presentable in real-time dashboards that combine generation, battery state, household demand, inferred appliance activity, and decision-support information in one interface, with load-shedding strategies for outage conditions organized by tiered load priorities. This is the difference between a dark house and a house that keeps the refrigerator and the medical equipment running.
Refrigerator behavior has been validated four independent ways, converging on a 37.9 percent duty cycle, compressor on-time near thirteen minutes, and roughly thirty-three cycles per day. All are consistent with the physical unit and with published reference ranges. That convergence is the strongest evidence to date that the system is learning real appliance behavior rather than fitting noise.
The deployment has also produced an important research lesson: model performance depends strongly on how often a particular appliance appears in the training data. Frequently operating loads can become well characterized relatively quickly, while rare appliances require substantially more history. That finding has helped motivate the project’s hybrid AI-and-physics architecture.
This dashboard presents real-time data and metrics of the microgrid. It operates inside the home, connects to any EdgeLake node, and presents the distributed data as if it were centralized on a single logical system, all through one API.
What Happens When the Power Grid Goes Down
The home becomes self-reliant and operates like an entirely independent island. When utility service is disrupted, the local inverter automatically supplies power from the battery and solar panels. The generator remains in reserve if those resources become insufficient. For the homeowner, the transition is automatic, and daily life continues without interruption.
The practical advantage of local intelligence appears at exactly this moment. The eGauge measurements, Solar Assistant telemetry, local data services, ONNX appliance models, and the Microgrid Manager are all designed to operate within the home’s internal network. When the home is operating from solar and battery storage, those computing and networking devices become small loads on the same microgrid they are monitoring. Inference costs single-digit milliseconds of CPU per panel, a rounding error against a refrigerator. The internet is almost certainly gone, because the neighborhood equipment it depends on has no battery behind it. That’s fine. Nothing in the monitoring or decision path was ever reaching outside the walls. The system that tells you how long you can last is running on the thing it’s measuring.
This means the system responsible for estimating the home’s remaining energy, and understanding where that energy is being used, does not disappear when external connectivity does.
The transition is detected within seconds through the utility tie current channel: no manual switch, no homeowner action, no cloud confirming what just happened. The Microgrid Manager reads the tie going to zero, confirms the inverter has assumed the load, and changes its objective completely.
Off grid, the Microgrid Manager projects how long the battery lasts at current draw using measured state of charge from Solar Assistant, factors in forecast solar recovery from local irradiance, and uses the NILM models to see which appliances are actually running right now, including the ones that report nothing about themselves. The system identifies the specific running loads eating the runway and ranks them by how many hours turning each one off actually returns: the water heater is drawing power now, it will cost four hours, and here’s a recommended action or alternative. Critical loads are never on the shed list.
And when the battery is high and midday solar is producing more than the house is consuming, the correct move isn’t conservation. It’s spending the surplus before it goes to waste. The system will recommend starting the dishwasher at eleven in the morning, pulling the heat pump forward while the sun is up, and charging what needs charging, so the evening starts from a full battery and a house that has already done its work.
When your home intelligence lives in a data center, an outage takes away access to your own information at exactly the moment you need it most. You’re left guessing about your own house, holding a phone with no signal, looking at an app that can’t reach its server. Here, nothing stops. Monitoring, analysis, and recommendations keep running on the internal network, powered by the same batteries keeping the lights on.
Does the System Still Work If the Internet Goes Down?
Yes. And that’s a design guarantee, not a lucky outcome.
The important distinction is between the home’s internal network and its connection to the external internet. The primary energy systems communicate over the internal network. The meter produces electrical measurements locally. Solar Assistant provides inverter and battery telemetry locally. EdgeLake manages the home’s data locally, the trained appliance models execute on local compute resources, and the dashboard and Home Assistant interfaces are hosted within the same environment. Not one step of monitoring, disaggregation, or recommendation touches the internet. There is no round trip to lose.
As a result, an internet outage does not remove access to the measurements describing current generation, battery state, household demand, or appliance inference. Some external information can still improve the system: weather and solar forecasts, for example, provide useful context about expected future generation. If those external services become unavailable, forecast quality may decrease, but the system degrades gracefully rather than failing, falling back to recent history and seasonal patterns. Solar forecasts get a little softer. Everything else runs exactly as it did before the outage.
That distinction gives the system a graceful degradation path: external connectivity can improve its view of the future without becoming the sole source of information about what the microgrid is doing right now. Whether a homeowner can understand what’s happening inside their own energy system should never depend on whether a cable outside their property is intact.
How Does the Microgrid Decide What to Even Turn Off During an Outage?
EdgeLake makes these decisions intelligently by unifying and managing data from across the entire microgrid, including battery state, solar production, household demand, forecasts, device priorities, and inferred activity from appliances that don’t report their own status, within a single local environment.
The Microgrid Manager uses this context to protect critical loads, defer flexible loads, and present clear choices for comfort loads. Refrigeration, medical devices, water pressure, networking, and essential lighting remain powered. Dishwashers, dryers, water heaters, pumps, and EV charging can shift to periods with more solar production or greater battery capacity.
Instead of merely reporting high consumption, the system identifies the dryer as the source and calculates how much battery runtime deferring it would recover. A rule-engine layer prevents counterproductive actions, such as interrupting an appliance when restarting it would consume more energy than allowing it to finish.
Homeowners see each recommendation, its expected benefit, and the reason behind it, while retaining control over household priorities. Initially, EdgeLake provides recommendations and Home Assistant provides the control path; automated load management can then be introduced gradually. This moves the home from basic load control to explainable, context-aware energy management that remains available locally during an outage.
How Easy Is It to Make My Home a Smart Microgrid Without Depending on the Cloud?
For a home with compatible solar, battery, inverter, or other monitored energy equipment, the additional requirements are modest: a whole-home energy meter installed by an electrician, and one always-on, low-power computer, such as a mini PC or capable single-board computer.
EdgeLake provides the data and AI services locally out of the box. Its software agents collect, organize, store, and analyze the home’s energy data, while Solar Assistant and Home Assistant connect supported energy systems and devices. This eliminates the need to build separate pipelines, databases, and cloud integrations. There is no required cloud account, subscription, or internet connection for normal operation.
The only commissioning necessary is pointing the data streams to EdgeLake. Once that’s complete, the underlying software-engineering burden is eliminated.
The appliance-learning process is also designed for simple deployment. Homeowners don’t need to manually label months of data or depend on a generic model trained in another environment. The system starts with a description of the home’s appliances, collects several weeks of local electrical measurements, and trains its models inside the home using physics-informed appliance signatures. It learns the behavior of that home’s refrigerator, HVAC system, and other loads, then improves as more history accumulates. No technician needs to repeatedly visit, and no household data needs to be uploaded.
What’s Next
The system is operational today. EdgeLake already unifies energy measurements, appliance-level inference, local AI, and decision support, while Home Assistant provides the control path to supported household devices.
The next phase will focus on incremental improvements: expanding Home Assistant integration, converting validated recommendations into safe automated actions, and simplifying the homeowner experience. Users will continue to define priorities and retain control over which actions are automated.
The appliance models will also be updated as more local history becomes available and as equipment is added, replaced, or removed. The Decision Support System will translate this information into concise guidance that explains what happened, why it matters, the recommended response, and its expected benefit, for example, delaying water heating to preserve battery capacity, or running a dishwasher while excess solar is available.
