The intelligence never needs to know the brand.
Enertia is three layers: equipment adapters that describe what each device can really do, a control core on site that plans and acts, and a cloud platform for the fleet. Here is how they fit together, and how far along each one is.
Local where it matters. Cloud where it helps.
Fleet platform
Enertia controller
Whatever is already on site
Levers are not symmetrical.
Most controllers assume that if you can set a limit, the equipment obeys it. Real equipment is messier. On some systems an import limit does not stop the load from pulling from the grid, and the only thing that actually lowers demand is discharging the battery.
Enertia models each device by the levers it really has: what each one can move, in which direction, how fast, and at what cost. When a target cannot be met with the levers available, the solver says so and reports the gap. It does not pretend it succeeded. That is what lets one optimiser drive different brands without guessing.
Six steps, every cycle, on a fixed cadence.
- 01
Sense
Read telemetry from every device through its adapter, stamped with when it was measured, received and used.
- 02
Check
Sanity-check readings and their age. Stale or implausible data stops the cycle instead of steering it.
- 03
Plan
Apply the site objective and its constraints, such as the demand cap, battery reserve and charge windows.
- 04
Solve
Turn the plan into commands for the levers this particular equipment really has, and state honestly anything it cannot achieve.
- 05
Act or hold
In shadow mode, record the command and write nothing. When armed, write it within bounded validity so a lost connection cannot leave a stale command in force.
- 06
Verify & record
Read back what the equipment actually did, and log the whole cycle with its reasons.
What the plan sees.
The first strategies in the core are rules-based, verified against recorded site data. Receding-horizon optimisation (model predictive control) comes next: a 24 to 48 hour plan, re-solved every few minutes as forecasts change.
- Solar forecastPlanned
Bought-in irradiance data, turned into yield by our own plant model with per-site bias correction.
- Load forecastPlanned
Learned per site by day type and season.
- Tariff calendarPlanned
Eskom time-of-use tariffs such as Megaflex, plus municipal tariffs.
- Load-shedding schedulePlanned
So the reserve is in the battery before the outage, not after it.
- Demand stateBuilt
Notified maximum demand and the rolling twelve-month peak already registered.
What the plan is for.
- Bill minimisationShift energy to where the tariff is cheapest.
- Peak shavingHold grid import under a demand cap, half-hour by half-hour.
- Backup reserveGuarantee energy in the battery for outages and load-shedding.
- Self-consumptionUse your own solar before exporting or importing.
- VPP dispatchLater: respond to aggregated grid-service signals.
Peak shaving and scheduled battery charging are the first strategies ported into the core. The others follow the forecasting milestone.
A controller that keeps working when the internet does not.
The edge controller is in design. The table shows the target specification, not a finished product.
| Form factor | DIN-rail, fanless |
|---|---|
| Compute | Linux-class gateway (platform shortlist open) |
| Field buses | 2 × RS485 (inverter bus, meter bus) |
| Network | Ethernet, Wi-Fi, optional LTE fallback |
| Outputs | Dry-contact relays for loads such as geysers and pumps |
| Metering | CT-based site metering where no meter exists |
| Operation | Control loop runs fully offline |
Target specification · subject to change
Put a site in the pilot.
We are looking for a small number of South African sites with solar, batteries or both, where tariffs and demand charges carry real money. Pilot sites run Enertia in shadow mode first: it plans and explains, and it controls nothing until you agree to switch it on.