Hybrid Solar + Battery Performance
Last updated: July 22, 2026
How to read PV vs. battery contribution, and what's possible across inverter OEMs
Hybrid assets — sites where solar and a battery share a single connection to the home and grid — report their contribution differently depending on the equipment manufacturer (OEM). This page explains how to separate solar (PV) and battery contribution using existing telemetry, how energy typically flows through a hybrid system, and what's possible today across Enphase, Tesla, and FranklinWH APIs. (SolarEdge is intentionally out of scope for now — coverage is still being scoped.)
Why separate PV and battery contribution?
Knowing what the solar array did versus what the battery did — rather than a single blended number — matters for a few reasons:
Accurate event performance — a discharge event can look like it "didn't happen" when really solar was covering the export requirement and the battery had nothing left to do.
Better home-load estimates — once generation, battery, and grid flows are known separately, home consumption can be estimated as the remainder.
Telemetry points for PV vs. battery contribution
The split comes from three metered points that already exist for most hybrid sites, rather than one combined figure:
Metric | What it represents |
|---|---|
Generation | Solar (PV) production at the array/inverter. |
Battery production / consumption | What the battery discharged (production) or absorbed (consumption) over the period. |
Grid import / export | Net energy crossing the meter — what actually left to, or came in from, the grid. |
NOTE Home load is derived today, not directly metered on most sites. Home consumption is typically estimated as the difference once generation, battery, and grid flows are known: generation + battery discharge - battery charge - grid import = ~home load. A small number of OEM configurations expose a direct consumption/production meter, which removes the need to estimate. Texture is looking into optimizing this based on what’s available per OEM. |
These signals don't have to be reconciled from separate exports — Texture's platform plots them together in a single site-level energy flow view: solar generation, battery charge/discharge, and grid import/export layered as sources (above the zero line) and sinks (below it), with estimated other-source and other-load series filling in the remainder. Hovering any interval surfaces the exact kWh value for each signal at that timestamp, which is the fastest way to sanity-check the home-load estimate above against what the site was actually doing.
Is there a single inverter output, or are PV and battery reported independently?
PV power and battery power are reported as independent data points — there isn't a single inverter AC-output figure that nets the two together. The one place they do get netted together is at the meter — grid import/export reflects the combined result of both, after home load is subtracted.
How a hybrid system prioritizes energy flow
On a typical self-consumption day (no active dispatch event), energy is used in a fixed order:
Solar covers home load first. Whatever the home is drawing gets satisfied by solar production before anything else happens.
Leftover solar charges the battery. Once home load is covered, surplus solar goes to charging the battery.
Once the battery is full (or capped), remaining solar exports to the grid. Export is the last stop for solar, not the first.
When solar can't cover home load (mornings, evenings, cloudy periods, overnight), the battery discharges to cover it.
This default order can be overridden. Time-of-use (TOU) strategies prioritize battery dispatch against a rate schedule instead of solar; grid-services dispatch events can request specific power targets that reshuffle the order for the event window. Because of this, solar can fully satisfy a daytime export request with little or no battery discharge — that's expected behavior, not a sign the battery failed to respond.
What's possible across OEM APIs
Solar and battery visibility and control both vary meaningfully by manufacturer. At a glance:
OEM | PV / battery reported separately? | Can solar be actively controlled? |
|---|---|---|
Enphase | Yes — production and battery charge/discharge are distinct signals. | Yes, directly. Enphase owns the inverter, so a selected battery mode (e.g., charge from solar only, charge from surplus solar, discharge to home only, discharge with export) explicitly decides where solar and battery power are routed. |
Tesla | Yes — production and battery charge/discharge are distinct signals. | Indirectly. The site controller decides the solar/battery mix needed to hit a requested power target; curtailment can be observed but not directed by the operator. |
FranklinWH | Yes — production and battery charge/discharge are distinct signals. | No. Solar comes from a third-party inverter Franklin doesn't control — Franklin can only allow or block battery charging and grid export, not curtail production itself. |
Enphase
Enphase's battery modes make solar routing explicit rather than inferred — the mode itself determines whether solar charges the battery only, charges the battery with surplus export, or passes through to serve the home first.
Tesla
Tesla's site controller manages solar and battery as a single optimized system in service of a fleet- or site-level power target. Texture can see whether solar is being curtailed relative to available production, but the operator doesn't get a direct “route solar here, route battery there” control — Tesla's optimizer owns that decision during an event.
FranklinWH
Franklin treats solar as passive: it reads from the third-party inverter but has no production throttle. The controllable surface is the battery and whether grid export is enabled — solar keeps producing regardless of what the battery is doing, and any surplus either charges the battery or exports, depending on how export is configured.