Energy Dispatch & Management — The Operational Intelligence of the Microgrid | LuxeAutonomy/title> <meta name="description" content="Dispatch and energy management is the operational intelligence layer of the sovereign-estate microgrid."> <link rel="stylesheet" href="includes/luxeautonomy.css"> <link rel="icon" type="image/png" href="favicon-96x96.png" sizes="96x96" /> <link rel="icon" type="image/svg+xml" href="favicon.svg" /> <link rel="shortcut icon" href="favicon.ico" /> <link rel="apple-touch-icon" sizes="180x180" href="apple-touch-icon.png" /> <script async data-id="101506538" src="//static.getclicky.com/js"></script> </head> <body>  <header class="la-header"> <div class="la-header__inner"> <a href="/" aria-label="LuxeAutonomy home"> <svg class="la-monogram" viewBox="0 0 100 100" role="img" aria-label="LuxeAutonomy"> <path d="M22 18 L34 18 L34 70 L62 70 L62 82 L22 82 Z"/> <path d="M52 18 L66 18 L86 82 L73 82 L68 64 L50 64 L54 53 L65 53 L59 32 Z"/> </svg> </a> <nav class="la-nav" aria-label="Primary"> <a href="energy-autonomy.html">Energy</a> <a href="mobility-autonomy.html">Mobility</a> <a href="intelligence-autonomy.html">Intelligence</a> <a href="estate-environment.html">Environment</a> <a href="estate-experience.html">Experience</a> </nav> <div class="la-header__right"> <a href="estate-ops.html" class="la-estateops-tab">EstateOps</a> <button class="la-burger" aria-label="Menu" aria-expanded="false" aria-controls="la-nav"> <span></span><span></span><span></span> </button> </div> </div> </header>  <nav class="la-crumb" aria-label="Breadcrumb"> <a href="/">Home</a><span class="la-crumb__sep">/</span> <a href="energy-autonomy.html">Energy</a><span class="la-crumb__sep">/</span> <span>Dispatch & Energy Management</span> </nav>  <section class="la-imghero"> <div class="la-imgslot la-imgslot--dark"> <div class="la-imgslot__ratio">Leaf hero</div> <div class="la-imgslot__note">Microgrid controller interface · the operational brain of the estate</div> </div> <div class="la-imghero__scrim"></div> <div class="la-imghero__inner"> <span class="la-eyebrow">Energy · 06</span> <h1 class="la-imghero__title">Dispatch & Energy Management</h1> <p class="la-imghero__sub">The operational intelligence layer of the microgrid — the framework and the moment-to-moment logic that turns generation, storage, and loads into one coordinated system.</p> </div> </section>  <article class="la-article"> <div class="la-article__body"> <p>The five preceding pages of the energy section describe what the system <em>has</em>. <a href="estate-energy-generation.html">Generation</a> produces electricity from a portfolio of sources. <a href="energy-autonomy.htmlstorage/">Storage</a> holds the surplus. <a href="estate-charging-infrastructure.html">Charging infrastructure</a> moves electricity into the fleet. <a href="estate-lifestyle-hobby-loads.html">Lifestyle and hobby loads</a> consume electricity for the household’s actual life. The <a href="estate-microgrids.html">microgrid architecture</a> assembles all of this into one electrical system with a defined boundary. What this page describes is what the system <em>does</em> — how the components are operated as one coordinated whole, who or what makes the decisions, against what objectives, on what timescales.</p> <p><strong>Dispatch</strong> is the practice of deciding what runs when, from which source, at what rate. <strong>Energy management</strong> is the broader discipline that includes dispatch plus the optimization objectives, the forecasting, the planning, and the integration with the rest of the residence’s operation. The two are paired because they are meaningless apart. Dispatch without management is reactive twitching against immediate conditions; management without dispatch is unexecuted policy. Together they are what turns a collection of equipment into an operating power system.</p> <p>The page that follows resolves this. The three timescales on which dispatch happens. The seven objectives a sovereign-estate dispatch optimizes against. The forecasting that feeds the optimization. The role of <a href="estate-ai.html">EstateAI</a> as the optimization layer above the microgrid controller. Grid interaction as one tactic among many. What the dispatch decisions actually look like in operation. And the architectural decisions that shape the whole.</p> <h2>The three timescales of dispatch</h2> <p>Dispatch decisions happen continuously at three distinct timescales, and the architecture that handles all three is the architecture that makes the rest of the energy system work. The timescales were named briefly in <a href="estate-microgrids.html">microgrid architecture</a>; here they are addressed in depth.</p> <div class="la-scanlist"> <div class="la-scanlist__item"><p><strong>Sub-second</strong> — protection actions, transition decisions, voltage and frequency stability. The microgrid controller acts autonomously against pre-established rules and protective settings. Inverters respond to grid faults in cycles measured in milliseconds; the controller transitions between grid-connected and islanded operation in sub-cycle timescales when the macro grid faults. No human or higher-level system is in this loop. The controller is engineered, tested, and certified to make these decisions correctly, and the rest of the system depends on it doing so silently.</p></div> <div class="la-scanlist__item"><p><strong>Seconds to minutes</strong> — the operational dispatch layer. Decisions about which generation sources contribute, how much storage discharges or absorbs, which loads are served at full capacity and which are throttled, when fuel-based generation engages. The controller executes against dispatch rules; EstateAI proposes adjustments to the rules based on conditions the controller does not have visibility into. This is the timescale at which the day-to-day character of the system is determined.</p></div> <div class="la-scanlist__item"><p><strong>Minutes to days</strong> — the planning and optimization layer. Forecasting solar generation, anticipating household loads, scheduling discretionary loads against generation availability, maintaining storage state-of-charge against islanded-readiness targets, planning the cadence of any grid-supplementary engagement. This is the timescale at which the family’s objectives are translated into operational behavior, and where EstateAI is doing its most consequential work.</p></div> </div> <p>The three timescales share the same physical equipment and the same data, but they have different decision authorities and different consequences. A protection trip at the sub-second timescale prevents equipment damage and personal hazard. A dispatch decision at the seconds-to-minutes timescale determines whether the household notices anything happen. A planning decision at the minutes-to-days timescale determines whether the system has the storage and generation it needs for the next forecast weather event. The architecture handles all three by separating their concerns cleanly: the controller owns sub-second protection autonomously; the controller and EstateAI share authority at seconds-to-minutes; EstateAI and the operator share authority at minutes-to-days.</p> <h2>The seven objectives of sovereign-estate dispatch</h2> <p>What distinguishes sovereign-estate dispatch from any other class of energy management is what the dispatch is optimizing for. Utility dispatch optimizes against cost and bulk reliability. Industrial-facility dispatch optimizes against process continuity. Sovereign-estate dispatch optimizes against a multi-dimensional objective function whose composition is itself a deliberate choice the family makes. Seven objectives are typically present, with the priorities set explicitly by the family rather than assumed by the vendor.</p> <div class="la-scanlist"> <div class="la-scanlist__item"><p><strong>Reliability</strong> — the household never experiences a power interruption. Not minimized; eliminated. Reliability is the primary objective of sovereign-estate dispatch, and the others are weighted against it rather than balanced equally with it. The system that occasionally surprises the family with a flicker or a brief dropout is a system that has not been engineered to the standard the discipline requires.</p></div> <div class="la-scanlist__item"><p><strong>Sovereignty</strong> — the macro grid is treated as a buffer, not a backbone. Dispatch maintains the system in a posture where grid loss does not change household operation, where grid charges are minimized through self-supply, and where the option to operate fully independent is always available. Sovereignty is not maximized at the cost of reliability; it is pursued <em>within</em> the reliability constraint.</p></div> <div class="la-scanlist__item"><p><strong>Endurance</strong> — storage state-of-charge is maintained at levels that satisfy the family’s islanded-design intent. If the family has specified seven days of islanded endurance at full operation, the dispatch logic maintains storage state-of-charge sufficient to deliver that endurance whenever islanded operation begins. Endurance is the second-order reliability metric — reliability against not just the current moment but against scenarios the family has chosen to be ready for.</p></div> <div class="la-scanlist__item"><p><strong>Asset preservation</strong> — battery cycle life, equipment longevity, the multi-decade horizon. Dispatch chooses storage cycling depth, discharge rate, and operating temperature ranges with the fifteen-to-twenty-year service life in mind. A dispatch that meets all the other objectives by cycling the batteries hard for short-term gain produces a system that needs replacement sooner than the engineering intent.</p></div> <div class="la-scanlist__item"><p><strong>Cost</strong> — relevant but ranked below the four above. Where the utility offers meaningful time-of-use rates, dispatch shifts loads to favorable intervals and exports surplus during high-price periods. Where the utility provides demand-response payments, dispatch can participate. Where neither applies, cost is largely an emergent property of optimizing the higher-priority objectives. Sovereign-estate dispatch is not a utility-arbitrage operation; it is a self-supply operation in which cost-optimization is opportunistic.</p></div> <div class="la-scanlist__item"><p><strong>Household preference</strong> — the family’s actual patterns and priorities, learned over time. EstateAI’s memory layer holds the household’s expressed preferences (climate setpoints, scheduled loads, the timing of vehicle availability, hospitality patterns), and dispatch operates against these as constraints rather than as suggestions. The family does not wait for the energy system to figure out what they want; the energy system serves what the family has said they want, while optimizing within that intent.</p></div> <div class="la-scanlist__item"><p><strong>Environmental</strong> — emissions, ecological consequence, the implicit values an estate built on renewable foundations carries. The environmental objective is largely an emergent consequence of optimizing the others — a portfolio built around solar, storage, and renewable-where-viable supplements produces low emissions as a structural property. Where the dispatch has discretion that affects environmental outcomes (which sources to dispatch first, when to run fuel-based backstops), the environmental preference is set deliberately by the family rather than assumed.</p></div> </div> <p>The objective function is configured during system commissioning and refined over the residence’s first year of operation. The relative weights are not arbitrary technical choices; they are expressions of the family’s actual values about what kind of estate this is. A family that values absolute energy independence weights sovereignty differently than a family that treats the grid as a useful tool. A family that wants the lowest carbon footprint weights environmental differently. The discipline is to set the weights deliberately, with the family’s active participation, rather than accepting the vendor’s default optimization for cost and emissions that may not match what the family actually wants.</p> <h2>Forecasting as the input layer</h2> <p>Dispatch decisions across all three timescales depend on forecasting — on knowing, as well as possible, what is going to happen next. The forecasting capability is itself a substantial component of the energy management system and worth understanding as the foundation the rest of the dispatch logic operates against.</p> <p>Four forecast streams feed sovereign-estate dispatch.</p> <div class="la-scanlist"> <div class="la-scanlist__item"><p><strong>Generation forecast</strong> — how much electricity the portfolio will produce, when, with what confidence. Solar production is forecast from weather data, season, time of day, and the estate’s own historical performance. Wind production where applicable is forecast similarly. Geothermal and fuel-based generation are dispatchable rather than forecast. The generation forecast is updated continuously, with confidence intervals that the dispatch logic uses to make probabilistic decisions about how much storage to maintain in reserve.</p></div> <div class="la-scanlist__item"><p><strong>Load forecast</strong> — how much electricity the residence and the fleet will consume, when, with what confidence. The forecast draws on historical patterns (the household’s typical Tuesday in November), current information (occupancy, scheduled events, anticipated arrivals and departures), and EstateAI’s learned model of the family’s actual behavior. Vehicle charging needs are forecast against anticipated trip plans and fleet utilization. The load forecast is the demand side of the dispatch optimization.</p></div> <div class="la-scanlist__item"><p><strong>Weather forecast</strong> — broader than the generation forecast, includes the conditions that drive both generation (cloud cover, wind speed) and load (temperature affecting HVAC, severe weather affecting outdoor operations). The weather forecast is the source of the lookahead that allows dispatch to prepare for multi-day events before they begin.</p></div> <div class="la-scanlist__item"><p><strong>Grid forecast</strong> — on grid-connected estates, the macro grid’s anticipated state. Time-of-use rate intervals, demand-response signals where applicable, anticipated grid maintenance windows, severe-weather grid outage probabilities. The grid forecast feeds the cost-optimization objectives and the islanded-readiness posture.</p></div> </div> <p>The four forecast streams are not independent. Weather affects both generation and load; grid conditions affect when self-supply is most valuable; load patterns interact with vehicle availability. The dispatch optimization treats them as a joint forecast, with the uncertainties properly propagated, rather than as four separate inputs handled sequentially. The forecasting itself is a substantial AI/ML capability that benefits from improvements in EstateAI’s reasoning layer over the system’s life.</p> <h2>EstateAI as the optimization layer</h2> <p>The microgrid controller is the dispatcher; <a href="estate-ai.html">EstateAI</a> is the optimization layer above it. This distinction has to be precise because it is where the human-AI-controller architecture across the energy system becomes most consequential.</p> <p>The microgrid controller executes dispatch rules at the sub-second-to-minute timescale. The rules are well-defined deterministic logic — if generation exceeds load, charge storage; if storage approaches full charge, curtail solar; if grid frequency deviates beyond threshold, transition to islanded operation; if the operator has authorized vehicle fast-charging, allocate storage capacity to absorb the peak. The controller is good at executing rules reliably; it does not know what the rules <em>should</em> be in a given context.</p> <p>EstateAI operates above the controller, at the minute-to-day timescale, optimizing the rules and proposing adjustments based on the broader context the controller does not have visibility into. The household’s schedule for tomorrow that affects which vehicles will be charging. The weather forecast that affects whether solar will be producing. The principal’s upcoming travel that affects whether the residence’s load profile will be different than typical. The household’s learned preferences about which loads matter most. These are inputs the controller cannot reason about; EstateAI can.</p> <p>The interaction between EstateAI and the controller takes three forms, each with its own architectural implications.</p> <div class="la-scanlist"> <div class="la-scanlist__item"><p><strong>Rule updates</strong> — EstateAI adjusts the controller’s dispatch rules in response to changing conditions. The storage state-of-charge target raised because severe weather is forecast in two days. The discretionary load shedding threshold lowered because the household will be away and the islanded-readiness can relax. The grid-export schedule shifted to favor different time-of-use intervals because the utility’s rate structure has changed. Rule updates are continuous, autonomous within authorized parameters, and visible on the <a href="estate-ops.htmloperations-console/">operations console</a> as a stream of system adjustments.</p></div> <div class="la-scanlist__item"><p><strong>Action proposals</strong> — EstateAI surfaces proposed actions for operator review when the actions are outside the autonomous-authorization envelope. Run the fuel-based backstop tomorrow afternoon to top up storage before a forecast severe-weather event. Schedule the eVTOL turnaround to begin charging at 2pm to coincide with peak solar. Pre-condition the principal’s vehicle two hours earlier than usual because their meeting moved. The operator reviews, approves, modifies, or rejects. The proposals appear in the operations console’s triage queue with the reasoning that produced them.</p></div> <div class="la-scanlist__item"><p><strong>Forecasting and reporting</strong> — EstateAI produces the forward-looking analysis that the operator and the family see. Tomorrow’s expected generation, the week’s anticipated load patterns, the trends worth watching (storage cycling, generation degradation, equipment runtime approaching service), the recommendations for the next planned change or seasonal adjustment. This is the slowest-timescale work and the most consequential for the household’s long-term view of the system.</p></div> </div> <p>The architectural rule that holds: the controller acts at speed against rules it does not question; EstateAI optimizes the rules and proposes the work beyond rules; the operator approves what EstateAI proposes and sets the policies that constrain what both can do autonomously. This separation is what allows the system to be both fast (controller) and intelligent (EstateAI) and accountable (operator) at once.</p> <div class="la-pullquote"> <p>The microgrid controller acts at speed against rules it does not question. EstateAI optimizes the rules and proposes the work beyond rules. The operator approves what EstateAI proposes and sets the policies that constrain what both can do autonomously.</p> </div> <h2>Grid interaction as one tactic among many</h2> <p>Grid interaction — selling electricity back to the macro grid, participating in demand-response programs, time-of-use arbitrage, virtual power plant participation — is a topic that the residential solar industry often elevates to the central organizing concept of energy management. On a sovereign estate, it occupies a different position: a useful tactic where the utility supports it economically, never the primary objective the system is optimized against.</p> <p>The reasoning is structural. A residence that organizes its energy management around grid interaction is a residence whose energy posture is dictated by the utility’s rate structures and program rules. The utility changes its tariffs (which utilities do regularly); the residence’s economics change; the dispatch rules have to be reconfigured. A residence that organizes around self-supply, with grid interaction as opportunistic, is a residence whose energy posture is its own — grid interaction adds value where it exists and is irrelevant where it does not.</p> <p>Three grid-interaction modes appear in sovereign-estate dispatch.</p> <div class="la-scanlist"> <div class="la-scanlist__item"><p><strong>Self-supply with surplus export</strong> — the baseline mode. The estate generates and consumes its own electricity; surplus is exported to the grid where net metering or feed-in tariffs make it economically meaningful. The dispatch logic optimizes for self-consumption first, with export as a secondary benefit. This is the dominant pattern.</p></div> <div class="la-scanlist__item"><p><strong>Time-of-use arbitrage</strong> — where the utility offers meaningful rate differences between intervals (typically peak afternoon hours at substantially higher rates than overnight), the dispatch shifts discretionary loads to favorable intervals and discharges storage during peak hours to avoid grid import. The arbitrage is genuine economic value where the rate structure supports it, but it is a tactic the dispatch employs rather than the strategy the system is built on.</p></div> <div class="la-scanlist__item"><p><strong>Demand response and grid services</strong> — where the utility offers payments for the estate to reduce demand during grid stress events, or for the estate’s storage to provide frequency regulation or other ancillary services, the dispatch can opt into participation. The opt-in is deliberate and bounded; the estate’s primary objectives (reliability, sovereignty, endurance) constrain how much participation is allowed. An estate that allows the utility to discharge its storage for grid stabilization during a heat wave is an estate that has compromised its own islanded readiness for grid revenue, which is a tradeoff to be made consciously if at all.</p></div> </div> <p>Grid interaction is configured during commissioning, reviewed annually as the utility’s offerings change, and adjusted as the family’s priorities evolve. It is a real tactic, capable of producing real value, but it is not the center of sovereign-estate dispatch.</p> <h2>The dispatch decisions in operation</h2> <p>What the dispatch logic actually does, day to day, is best understood through what the system handles invisibly. A representative day on a fully operating sovereign-estate dispatch:</p> <p>At 4 AM, the system is in a steady state — storage at high state-of-charge from yesterday’s production, residence at minimum night-time consumption, vehicles connected and topped up, the operations console quietly displaying nominal operation. EstateAI has updated the day’s forecast overnight: clear morning, partial afternoon clouds, normal household schedule, the principal departing for the office at 8:15, the spouse leaving for an event at 6 PM, an anticipated return around 10 PM.</p> <p>At 6 AM, generation begins as the sun rises. The dispatch logic shifts the system from storage-discharge mode (which served the night) to storage-recharge mode. Solar production rises through the morning; the residence’s morning loads (climate, kitchen, household routines) are served from generation as it comes online; surplus charges storage. At 8:15, the principal’s vehicle is pre-conditioned and ready. The pre-conditioning event was scheduled by EstateAI an hour earlier to coincide with the rising solar production, drawing from generation rather than storage.</p> <p>At noon, solar is at peak production, exceeding household and operational load. Storage is approaching full charge. EstateAI proposes running the working garage’s air handler at high speed to pre-cool the space for the principal’s afternoon work session, and starting the pool heating cycle that has been pending. Both are discretionary loads that benefit from being served during surplus generation. The operator approves; the loads run. Storage continues to charge against the remaining surplus.</p> <p>At 3 PM, the forecast partial clouds arrive. Solar production drops by 40 percent. The dispatch logic transitions storage from charging mode to a maintenance posture. Household loads continue from the combined generation and storage; the working garage’s pre-cooling is allowed to coast on stored thermal mass; the pool heating cycle completes on schedule. Nothing in the residence experiences any change.</p> <p>At 5:30 PM, the spouse begins preparing to leave. EstateAI flags the vehicle for pre-conditioning at 5:45. Storage discharges to handle the brief pre-conditioning peak. The operations console shows the planned vehicle departure and storage state.</p> <p>At 7 PM, solar production has ended; storage is the primary source. The residence’s evening loads (climate, kitchen, entertainment) are served from storage. The dispatch logic monitors storage state-of-charge against the day’s remaining anticipated load (including the spouse’s 10 PM return and vehicle charging). The trajectory is comfortable; no intervention needed.</p> <p>At 10:30 PM, the spouse returns, the vehicle connects to the charger. The dispatch logic schedules the recharge against the overnight period, prioritizing slower charging to favor battery longevity and to avoid drawing storage state-of-charge too low overnight. The household’s evening winds down; loads decrease; storage approaches its overnight minimum target.</p> <p>At 2 AM, the system is again at steady state. Storage at the overnight target, low residence load, vehicles charging or charged. The dispatch logic has executed thousands of small decisions across the day, the operator has reviewed perhaps four EstateAI proposals, the family has noticed nothing about the energy system because nothing has happened that warranted their attention. The day is the dispatch logic operating correctly.</p> <h2>The architectural decisions that matter</h2> <p>Four decisions in sovereign-estate dispatch and energy management have consequences worth surfacing at the principal and family-office level.</p> <p>The first is <strong>the objective function configuration</strong>. The relative weighting of the seven objectives is set deliberately by the family during commissioning, with the operator and the energy designer translating the family’s expressed priorities into the configuration the dispatch logic actually uses. A family that values absolute energy independence configures differently than a family that treats the grid as a useful tool. The default configurations vendors provide are rarely wrong for typical residential use; they are rarely <em>right</em> for the sovereign estate’s actual posture. The discipline is to configure deliberately.</p> <p>The second is <strong>the autonomy envelope for EstateAI</strong>. What dispatch adjustments EstateAI is authorized to make autonomously, versus what must be proposed for operator approval. The envelope is set conservatively at first — minor adjustments within established bounds, with anything consequential requiring approval — and expanded over time as the family develops confidence in EstateAI’s judgment. The envelope is also reviewed periodically as the household’s patterns evolve and as EstateAI’s capabilities improve.</p> <p>The third is <strong>the forecasting integration</strong>. The forecast streams that feed dispatch (generation, load, weather, grid) must be reliable, current, and properly weighted in the optimization. Weather services with reliable forecasting at the estate’s specific location; load forecasting that learns the household’s actual patterns rather than relying on generic residential models; grid-condition forecasting where the utility provides data feeds. The integration architecture is set during design and refined during commissioning.</p> <p>The fourth is <strong>the platform decision</strong>. Sovereign-estate energy management platforms range from integrated stacks (the microgrid controller vendor provides the dispatch logic, the platform, and the integration with EstateAI as one product) to open architectures (the controller, the optimization layer, EstateAI, and the operations console are best-of-breed components integrated by the estate’s technical team). The integrated-stack approach has lower integration risk and faster commissioning; the open architecture has more flexibility to evolve. As with similar decisions in the rest of the energy system, the choice depends on the family’s posture toward technology dependence and is worth being explicit about during design.</p> <h2>When to specify it</h2> <p>Dispatch and energy management is specified at design alongside the microgrid architecture, with the platform selection settled by design development and the configuration work performed during construction and commissioning. By feasibility, the energy management platform direction is established. By schematic design, the integration between the microgrid controller, EstateAI, and the operations console is architected. By design development, the specific platform and the integration approach are settled.</p> <p>The configuration work — setting the objective function weights, configuring the forecasting feeds, defining the autonomy envelope, calibrating the household’s preferences — is performed during commissioning, with the family’s active participation. This is not vendor work performed in isolation; it is collaborative work between the energy designer, the operator, EstateAI’s architect, and the family. The result is a dispatch logic that reflects the family’s actual priorities rather than a vendor’s defaults.</p> <p>The system enters operation with a deliberately conservative autonomy envelope, with most consequential decisions requiring operator approval. Across the first year of operation, the envelope expands as the family develops confidence, EstateAI refines its understanding of the household, and the operator establishes the working relationship with the system. By the end of the first full year, the dispatch logic is operating against a well-calibrated objective function with appropriate autonomy bounds, and the residence is operating as the family intended from design.</p> <div class="la-callout"> <span class="la-eyebrow">EstateOps</span> <p>Dispatch and energy management is where the energy system becomes operational rather than just installed. The controller executes; EstateAI optimizes; the operator approves and tunes. The dispatch logic is the place where the engineering of the rest of the energy section meets the lived life of the household it serves.</p> <a href="estate-ops.html">Explore EstateOps</a> </div> <p>The energy system has the equipment described in the preceding pages. What it does with that equipment, moment to moment and day to day, is the dispatch logic operating against the family’s objectives, learning the household’s patterns, anticipating the next event, and producing the steady-state operation in which the residence is powered reliably, the fleet is ready, the storage is maintained, and the family notices nothing because nothing is happening that warrants their attention. That nothing-to-notice is the dispatch logic operating correctly. The work is invisible because the engineering is right.</p> </div> <div class="la-related"> <span class="la-eyebrow la-related__label">Related in Energy</span> <div class="la-related__links"> <a href="estate-microgrids.html">Microgrid Architecture</a> <span class="la-related__sep">|</span> <a href="estate-energy-generation.html">Generation</a> <span class="la-related__sep">|</span> <a href="energy-autonomy.htmlstorage/">Storage</a> <span class="la-related__sep">|</span> <a href="estate-charging-infrastructure.html">Charging Infrastructure</a> <span class="la-related__sep">|</span> <a href="estate-lifestyle-hobby-loads.html">Lifestyle & Hobby Loads</a> <span class="la-related__sep">|</span> <a href="estate-power-resilience.html">Resilience</a> <span class="la-related__sep">|</span> <a href="energy-autonomy.html">Energy overview</a> </div> </div> </article>  <footer class="la-footer"> <div class="la-footer__inner"> <div> <div class="la-footer__wordmark">Luxe<span>Autonomy</span></div> <div class="la-footer__tagline">The Future, Elevated.</div> </div> <div class="la-footer__cols"> <div class="la-footer__col"> <a href="estate-ops.html">EstateOps</a> <a href="energy-autonomy.html">Energy</a> <a href="mobility-autonomy.html">Mobility</a> <a href="intelligence-autonomy.html">Intelligence</a> <a href="estate-environment.html">Environment</a> <a href="estate-experience.html">Experience</a> <a href="estate-journal.html">Journal</a> </div> <div class="la-footer__col"> <a href="about-contact.html">About & Contact</a> <a href="legal-policy.html">Legal & Policy</a> <a href="sitemap.html">Sitemap</a> </div> </div> <div class="la-footer__network"> <span>© <script>document.write(new Date().getFullYear());</script> LuxeAutonomy</span> <span>A SiliconPlans network property</span> </div> </div> </footer>  <button class="la-totop" aria-label="Back to top"> <svg viewBox="0 0 24 24" fill="none"><path d="M12 19V5M5 12l7-7 7 7" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/></svg> </button> <script src="includes/luxeautonomy.js" defer></script> </body> </html>