Solis inverter on Octopus Agile: how 1app.energy works

Octopus Agile can be a good tariff for homes that can move electricity use into cheaper half-hours. A solar and battery home is exactly the kind of home that should be able to respond to those price signals.

But for a Solis inverter customer, the important question is not just "am I on Agile?"

The real question is:

Can my home understand the Agile price, the battery state, solar generation, EV charging demand and inverter control limits at the same time?

That is where 1app.energy fits.

This guide explains how 1app.energy works for a Solis inverter or Solis hybrid inverter home on Octopus Agile, based on how our backend actually handles tariff data, Solis telemetry and customer-enabled battery control.

The quick version: Solis inverter and Octopus Agile

For a supported Solis home on Octopus Agile, 1app.energy is designed to provide:

• A clearer customer view of solar, battery, grid, EV and tariff behaviour in one place.
• Octopus Agile tariff detection when the customer connects Octopus.
• Half-hour import price rows from Octopus, stored as live tariff data rather than forced into a fixed off-peak schedule.
• A dashboard tariff summary that can show the current Octopus Agile rate, source, support state and next tariff context where the data is available.
• Solis battery and inverter context where the Solis integration is connected and reporting usable telemetry.
• A clear separation between tariff visibility and battery automation, so the customer can see Agile pricing even when smart control is not yet ready.
• Tariff-aware battery behaviour only where the site supports Solis control, the customer enables it, telemetry is fresh enough and the smart-control setup gates pass.

That last point matters.

1app.energy should not pretend that every Agile home is automatically controllable. Agile visibility and Agile battery automation are related, but they are not the same thing.

Why Octopus Agile is different from a fixed off-peak tariff

Many battery setups are built around a simple idea: charge the battery overnight when electricity is cheap, then use the battery during the day.

That works naturally with a fixed time-of-use tariff such as a predictable overnight cheap window.

Octopus Agile is different.

Octopus describes Agile as a tariff with half-hourly prices tied to wholesale electricity prices and updated daily. Octopus also explains that the next day's rates are normally published between 4pm and 8pm. That means Agile is not a single off-peak window. It is a moving set of prices across the day. (Official Octopus Agile page, checked 10 May 2026.)

On some days, Agile may have very cheap or even negative-price periods. On other days, the expensive periods can be much higher. That is why a battery home needs more than a fixed timer.

A useful Agile battery setup needs to know:

• What is the current import price?
• What prices are coming next?
• Is the battery already full?
• Does the home need the battery later?
• Is the EV about to charge?
• Is export enabled, allowed and financially sensible?
• Is the Solis inverter control path verified for this installation?

Without those checks, "charge when cheap" sounds simple but can create poor behaviour.

How 1app.energy reads Octopus Agile prices

When a customer connects Octopus, the backend inspects the active electricity agreement and classifies the tariff. If the tariff code contains Agile, the tariff is treated as an Agile-style live-pricing tariff.

The important design decision is this:

1app.energy does not copy Agile into fake peak and off-peak settings.

For dynamic Octopus import tariffs such as Agile, the backend stores the actual half-hour import prices in tariff rate rows. The fixed import fields, such as peak rate, off-peak rate and off-peak start/end time, stay neutral instead of pretending Agile has a normal overnight window.

That is deliberate.

If Agile prices move every half hour, the honest source of truth is the live Octopus rate data. A fixed "off-peak" field would be too blunt and could mislead the customer or the control logic.

The dashboard can then use the backend tariff summary rather than trying to calculate tariff state in the browser. That summary can include the tariff label, source, current rate, support level, import/export rates where available, standing charge and next tariff context.

This is the same source-of-truth principle we explain in Can you trust your home energy dashboard? Start with the source of truth.

Three layers: visibility, readiness and control

For an Agile customer, it helps to separate 1app.energy into three layers.

The first layer is tariff visibility.

If Octopus is connected and the backend has valid Agile rate rows, the app can show the customer the Agile tariff context. That can be useful even before any battery control is active.

The second layer is control readiness.

This checks whether the installation is actually ready for smart battery control. For a Solis home, that includes Solis connection status, supported control profile, customer settings, battery capacity evidence, state of charge and fresh enough telemetry.

The third layer is a live battery command.

That only happens when the first two layers are good enough and the current control cycle has a clear reason to charge, hold, idle or export. If the tariff data, Solis telemetry or setup gate is incomplete, the safer behaviour is to show the state and avoid sending a battery command.

This is why a customer may see Octopus Agile prices in the dashboard before they see automated battery behaviour. That is not a contradiction. It means the tariff layer is available, while the control layer is still waiting for the conditions needed to act safely.

What the customer sees in the dashboard

For a Solis and Agile home, the customer should not have to jump between several apps just to understand the basic situation.

1app.energy aims to show the customer:

• The current tariff context, such as Octopus Agile where detected.
• The current import rate where Octopus has synced valid live pricing rows.
• Import, export and standing-charge context where available.
• Battery state of charge and battery power from the connected inverter data.
• Solar, grid and home-load context from the backend's combined energy view.
• EV charging context where a supported EV charger is connected.
• A Nexus-style whole-home power-flow view where the backend has a coherent snapshot.

The key word is "coherent".

For live energy flow, the backend should prefer a whole-home picture over a broken partial diagram. If one device reports slightly later than another, 1app.energy should avoid making the customer believe the home is doing something physically impossible. We covered that wider issue in the Solis software gap and why UK homes need a smarter energy app.

What happens when Solis is connected

Solis is the inverter and battery side of the picture.

When Solis is connected, 1app.energy can use Solis data for battery state, inverter behaviour and battery control eligibility where the model and control path are supported.

But the backend does not treat every Solis-looking installation as safe to control.

Solis control depends on things such as:

• A connected Solis device for the right installation.
• Usable Solis telemetry.
• A supported or verified Solis control profile.
• Battery capacity and state of charge evidence where the selected smart mode needs it.
• Customer settings that allow grid charging or export optimisation where those behaviours are required.
• Fresh enough data to make a sensible control decision.

If those conditions are not met, the safer behaviour is to pause, idle or show configuration status rather than send confident battery commands.

That is important for end users. 1app.energy is not trying to "force" a Solis inverter into a behaviour it cannot safely support. The product should explain the state honestly and only automate where the backend has enough evidence.

If you are still setting up Solis, the practical starting point is how to connect SolisCloud to 1app.energy.

What battery control can do on Agile, where supported

When the Solis control path is supported, customer-enabled and the smart-control gates pass, 1app.energy can use Agile price rows as part of battery decisions.

The backend reads the current import price from the live tariff rate rows. For value-aware modes, it can also look ahead at upcoming import and export rows inside the optimisation horizon.

That means the decision can be based on real Agile prices rather than a hard-coded cheap window.

There is one important current boundary to understand.

Because Agile is a live-pricing tariff, 1app.energy keeps fixed peak and off-peak settings neutral. That is the correct tariff representation. Battery control still has setup gates, so if the control layer says tariff configuration or control readiness is required, the backend should idle rather than make a command from incomplete setup.

So the public promise should be:

Agile visibility is available when Octopus rate data is valid. Agile battery automation is conditional and only runs where the installation is ready for it.

The behaviour also depends on the selected smart control mode.

Visibility-only state on Octopus Agile

Some customers may use 1app.energy for visibility first.

In this state, the app can still help explain the home:

• What the current Agile price is.
• Whether Solis is reporting battery and inverter data.
• Whether the Nexus flow looks coherent.
• Whether the EV charger is affecting the home energy picture.
• Whether tariff or control setup is still incomplete.

No battery command should be sent just because the tariff is connected. That is the right behaviour when the customer has not enabled smart control or the backend has not verified the Solis control path.

Home First mode on Octopus Agile

Home First is the public name for the backend's self-sufficiency mode.

Its main goal is to help the home use the battery sensibly for the household, rather than chasing every possible export opportunity.

Home First is most naturally suited to a home-first battery strategy. Where the Solis control path, tariff setup and settings allow it, a cheap or negative Agile period can be treated as a possible charge opportunity. If the battery is already full, it avoids unnecessary charging.

Home First also uses battery capacity and state-of-charge evidence to decide whether charging is needed. If battery capacity is missing for a mode that requires it, the backend pauses rather than guessing.

During expensive prices, Home First does not automatically export just because the price is high. It is designed to protect home coverage. That matters because a customer may still need the battery later in the evening.

Autopilot Value mode on Octopus Agile

Autopilot is the mode most aligned with dynamic tariffs such as Agile, where the price shape changes through the day.

For dynamic prices, the backend can derive charging and expensive-price thresholds from upcoming rate rows. In plain English, it looks at the Agile price curve and works out what looks cheap and what looks expensive for that upcoming period.

It does not simply assume that every low-price slot is enough time to refill the battery.

The control logic considers things such as:

• Current battery state of charge.
• Battery capacity.
• Charge current capability.
• The amount of cheap time remaining.
• Protected reserve for the home.
• Whether export optimisation is enabled.
• Whether export is actually profitable.
• Whether there is enough future cheap energy to refill safely after export.

That means a short cheap Agile window is treated carefully. If there is only a small amount of cheap time available, the backend should not pretend the battery can magically refill from empty.

Autopilot can also consider export, but only with the right permissions and data. It needs export optimisation enabled, positive export context, enough battery above protected reserve and a refill picture that does not create a worse import problem later.

So Autopilot is not "sell the battery whenever Agile is expensive". It is a controlled charge, hold, idle or export decision based on the whole home.

Time-based Control on Octopus Agile

Time-based Control is the simplest mode. It is strongest when the customer has a clear cheap tariff window and wants to charge to a chosen target without optimiser-led export.

That makes it a natural fit for fixed-window tariffs such as Go or some manually configured tariffs.

Agile is different because it does not have one fixed cheap window. For a pure Agile setup, Time-based Control should not be described as the best default. It may still be useful in some configured sites, but the customer should understand that Agile's strength is dynamic pricing, and Autopilot is the more natural value-aware mode where supported.

Time-based Control also keeps export optimisation off by design.

If you are choosing between the modes, start with which 1app smart control mode should you use.

Which 1app.energy mode should an Agile customer choose?

The simple answer is:

• Choose visibility-only if you mainly want to understand Solis, battery, EV and Agile tariff behaviour before enabling control.
• Choose Home First if your priority is keeping battery energy for the home and avoiding optimiser-led export.
• Choose Autopilot if you want the system to respond more intelligently to Agile price movement, where the installation supports it and the customer enables it.
• Choose Time-based Control if you want a simpler charge-to-target style and your tariff setup gives the backend a clear cheap period to work from.

For many Agile customers, the sensible journey is not to jump straight to maximum automation. Start with visibility, confirm the Solis and Octopus data is coherent, then enable the right control mode only when the site is ready.

Practical examples for a Solis home on Octopus Agile

Here are some plain-English examples of how the system is intended to behave.

These are not savings promises. They are behaviour examples based on the control logic and gates.

Example 1: Agile price is cheap and the battery is low

If the current Agile price is below the configured or dynamic charge threshold, the battery is not full, Solis control is available and all setup gates pass, 1app.energy can decide that charging is sensible.

The backend can then choose a charge current based on the available cheap window, current battery state, battery size and configured control limits.

If the setup is not ready, the system should not guess. It should idle or show that configuration is required.

Example 2: Agile price goes negative

Negative Agile prices can happen when there is excess electricity on the grid.

If the battery is not full and control is safely available, the backend can treat a negative import price as a strong reason to charge. If the battery is full, there is no useful battery charging to do.

This is one of the reasons Agile can be attractive for a flexible battery home. But it only helps if the home can act on the signal in a controlled way.

Example 3: Agile price is high in the evening

High Agile prices do not automatically mean "export the battery".

In self-sufficiency mode, the system is more likely to preserve battery energy for the home. In Autopilot Value, export can be considered only if export optimisation is enabled, export pricing is positive, the Solis control path allows it, the battery is above protected reserve and the future refill picture is acceptable.

That is the difference between useful optimisation and reckless optimisation.

Example 4: The EV starts charging during the day

An EV charger can look like a large household load. If the battery simply responds to household demand, it may discharge into the EV.

That can be frustrating on Agile. The customer may think the car used cheap grid electricity, while the battery quietly supplied part of the session.

Where a supported EV charger is connected, 1app.energy can give the customer EV context in the same view as the Solis battery and Agile tariff. That helps explain whether EV charging is affecting the battery. We explain this conflict in more detail in why Octopus EV charging can drain a home battery.

Example 5: Octopus is connected but Solis control is not ready

The dashboard may still show Agile tariff context, current pricing and whole-home visibility where data is available.

But smart battery control should remain paused or configuration-required until the Solis side is ready. That can happen if the Solis integration is not connected, the model control path has not been verified, telemetry is stale, battery capacity is missing, or the customer has not enabled the required control settings.

Example 6: No export tariff is available

If Octopus does not provide usable export tariff rows, the backend should not invent an export credit.

In that situation, export rate context stays neutral. Export optimisation should not be promoted as available just because the import tariff is Agile.

Example 7: Solar is genuinely zero

If it is night-time or the weather means solar generation is zero, showing zero solar is fine.

The problem would be showing a broken or physically confusing picture because one part of the telemetry chain arrived late. That is why 1app.energy tries to distinguish genuine zero values from incomplete data.

Why Agile visibility may appear before Agile automation

This is an important point for customers.

The app may be able to show Octopus Agile tariff visibility before battery automation is fully active.

That is normal.

Tariff visibility depends mainly on Octopus connection and valid tariff rate rows. Battery automation depends on more conditions: Solis control readiness, customer permissions, inverter telemetry, battery capacity, smart-control settings and safety gates.

If any of those are missing, 1app.energy should not hide the tariff. It should still help the customer understand the Agile price, while making it clear that smart battery control is not yet ready.

This is better than pretending everything is active when it is not.

What customers should check before relying on Agile control

Before relying on automated Solis battery behaviour with Agile, a customer should check:

• Octopus is connected and the tariff is detected as Agile.
• The current tariff rate is visible and marked as coming from Octopus sync.
• Solis is connected and reporting current battery state.
• Battery capacity is known or configured where the selected mode needs it.
• Smart control is enabled by the customer.
• Grid charging is allowed where the chosen behaviour requires battery charging from the grid.
• Export optimisation is only enabled if the customer wants it and export data is available.
• The selected mode matches the customer's goal: visibility, home coverage, adaptive value or simple target-based charging.

This is the practical difference between a dashboard and an energy control system. The dashboard can explain what is happening. The control system should only act when the required evidence is present.

What 1app.energy will not do

For a Solis inverter home on Octopus Agile, 1app.energy will not:

• Guarantee savings, because tariffs, weather, usage and hardware behaviour vary.
• Treat Agile as a fixed off-peak tariff.
• Invent export earnings when no usable export tariff data exists.
• Enable export optimisation without the required customer settings and positive export context.
• Send Solis battery commands when the control path is unavailable or unsafe.
• Assume every Solis model supports the same control method.
• Ignore stale or incomplete telemetry just to make the dashboard look confident.

That is not cautious marketing. It is the right product boundary for a customer-facing energy app.

Wrong energy behaviour is worse than a clear "not ready yet" state.

How this helps a Solis customer on Agile

The value for the customer is clarity first, automation second.

A Solis and Agile customer wants to know:

• What is my current Agile price?
• Did my battery charge when it was cheap?
• Did my battery preserve energy for the evening?
• Did my EV charging session drain the battery?
• Did my export behaviour make sense?
• Is my inverter and tariff setup ready for smarter control?

1app.energy is designed to bring those answers into one customer app for solar, battery, EV and tariff.

For Solis homes, that matters because the hardware may be working correctly while the customer still lacks a clear joined-up view. That is the software gap 1app.energy helps close.

If you are comparing Agile with a fixed overnight tariff, read Octopus Agile vs Go for home battery owners. Agile can be more flexible, but only if the home can respond properly.

Common questions about Solis inverter homes on Octopus Agile

Does 1app.energy support Octopus Agile?

Yes, where the customer connects Octopus and valid Agile tariff rows are available. The backend detects Agile-style tariffs and stores the half-hour import prices as live tariff data.

Battery automation is separate. It depends on supported Solis control, customer settings, telemetry and smart-control readiness.

If Agile is supported, why might smart control still say setup is required?

Because tariff support and battery-control readiness are separate.

The app can support Agile pricing as live half-hour tariff data while still pausing battery commands if the Solis control path, telemetry, battery capacity, customer permissions or smart-control setup gates are not ready.

That is safer than sending commands from incomplete information.

Why are my fixed peak and off-peak fields blank or zero on Agile?

Because Agile is not a fixed peak/off-peak tariff.

For Agile-style live pricing, 1app.energy keeps the fixed import fields neutral and uses the actual Octopus rate rows as the source of truth. That avoids presenting a fake off-peak window.

Will 1app.energy always charge my Solis battery at the cheapest Agile slot?

No.

The cheapest slot is not always enough by itself. The backend also needs to consider battery state, battery capacity, charge current, cheap-window length, home reserve and whether Solis control is available.

If the setup is incomplete, it should pause instead of guessing.

Which 1app.energy mode is best for Octopus Agile?

For a customer who wants adaptive tariff behaviour, Autopilot is the most natural Agile mode where supported.

For a customer who wants calmer home-first behaviour, Home First may be a better fit. For simple fixed-window charging, Time-based Control is easier to understand, but Agile is not really a fixed-window tariff.

The right mode depends on whether the customer wants visibility only, home coverage, adaptive value, or simple target-based charging.

Can 1app.energy export my battery during expensive Agile periods?

Only where export optimisation is enabled, supported and financially sensible.

Agile is primarily an import price signal. Export behaviour depends on export tariff data, customer settings, Solis control capability, battery reserve and safety checks. In self-sufficiency mode, high import price alone does not mean automatic export.

Does Agile mean the app ignores standing charge or daily cost?

No.

Agile changes the import unit rate, but a customer's bill also depends on standing charge, export credit where available, total import, total export and household behaviour. The dashboard tariff summary can include standing charge and export context where the backend has that data.

Do I need a Zappi charger for this to work?

No, a Solis and Agile home can still benefit from tariff visibility and battery context without a Zappi.

Zappi or another supported EV charger becomes useful when the customer wants EV charging context in the same whole-home view. If Zappi CT mapping is involved, it needs to be configured correctly because CT roles affect the energy picture. See Zappi CT mapping for solar, battery and home energy dashboards.

What happens if Octopus prices fail to sync?

If there is no valid current price row and no safe fallback, the smart-control layer should not invent a price. It should idle rather than make a battery decision from missing tariff data.

The dashboard should make the tariff state visible so the customer understands whether Octopus data is fresh.

What happens if I change tariff away from Agile?

When Octopus sync runs again, the backend should detect the active import agreement and update the tariff support state. Fixed-window tariffs and live-pricing tariffs are represented differently, so the app should not keep using old Agile assumptions after the tariff changes.

Final thought on Solis and Octopus Agile

Octopus Agile can be powerful for a flexible home, but it also makes the home more dependent on good software.

A Solis inverter, a battery, an EV charger and an Agile tariff can all be useful on their own. The customer benefit comes when those parts are explained and, where supported and customer-enabled, controlled as one home.

That is the role of 1app.energy: one app for solar, battery, EV and tariff, with honest visibility first and safe automation where the installation supports it.

Visit 1app.energy to start early-access onboarding.