The box that runs the site. Not a black box.

What it is

A controller running an Ubuntu and Docker stack of around fifteen services, installed on site. It does not need the cloud to operate. If the internet goes away, the site keeps running exactly as it was — the connection is for visibility and configuration, not for control.

That distinction is the whole design. Control lives at the site, where the latency is microseconds and the failure modes are local. Supervision lives in the cloud, where it is convenient. The two never swap roles.

Safety architecture

This is the part worth reading carefully, because it is the difference between a controller you can put on a commercial site and one you cannot.

Every setpoint passes a clamp pipeline

No exceptions, no fast path, no override flag. Each setpoint is clamped in order by:

• State-of-charge floor and ceiling.
• The limits the battery's own BMS declares — re-read fresh on every write, not cached from startup.
• The hardware rating of the equipment.
• A ramp-rate limit.
• A time-to-live, so a stale command expires rather than persisting.

Effects are verified, not assumed

A command acknowledgement means the device received the instruction. It does not mean the instruction happened. The EMS checks the observed effect against what it asked for, and when the two diverge in a sustained way it trips SafeFallback: setpoint zero, latched, until an operator clears it. It does not retry hopefully and it does not quietly continue.

Two things it will never do

• Write to the battery BMS. The BMS is the authority on the battery; the EMS reads it and obeys it.
• Automatically reset faults. A fault that clears itself is a fault nobody investigated.

Both are enforced inside the protocol client rather than being a rule people are expected to follow.

Deterministic by design

No randomness anywhere in the decision path. The same inputs produce the same decision, and any decision can be replayed and explained after the fact. When something unexpected happens on a site, you can find out precisely why — which is not a property you get from a system that optimises by inference.

The cloud cannot send it a setpoint

Not "is not permitted to" — cannot. No setpoint command type exists in the protocol. The only cloud-to-controller channel is a bounded set of configuration scopes and four actions, HMAC-signed with replay protection. A compromised cloud account cannot drive a battery.

Control strategies

• Self-consumption. An incremental PI controller drives grid power toward zero, with automatic anti-windup. This is the strategy that matters most under net billing, because it is the one that keeps energy on site instead of exporting it at the wholesale rate.
• Time-of-use dispatch. Charge off-peak, discharge at peak, with state-of-charge floors respected throughout.
• Custom rule engine. Versioned rule sets with sustained-for timers, applied hot without restarting the controller.
• Manual mode with a dead-man re-arm, so a manual override cannot be left running by accident.

Peak shaving is implemented but ships disabled by default. It is available on request rather than being something we put in a headline.

Battery telemetry and honest reporting

The controller reads deeply from the battery: state of charge, state of health, cell voltage minimum, maximum and average, cell temperatures, and cumulative charge and discharge, with battery-health reporting built on top.

Its savings reports have a property worth stating plainly: the system never fabricates money. If there is no usable import price available, the report carries no monetary figures at all. It does not fall back to a national average and present the result as though it were measured.

When connectivity drops

Telemetry is buffered on the box with store-and-forward, backoff on retry, and replay when the link returns. An outage costs you visibility for its duration, not the data.

What you see locally, and from the cloud

The controller serves its own web UI on site: dashboard, control, devices, alarms, rules, history, reports, savings, battery health, diagnostics, tariff configuration and a commissioning wizard. An engineer standing at the cabinet has everything without needing a connection.

From the Helios Platform you additionally get the site in fleet view, a live EMS panel, alarms and events, the signed configuration and action channel, and a per-minute watchdog on the controller itself.

Supported hardware

Today the EMS supports CNTE PCS and BMS equipment, and the Huawei SmartLogger. Further PV-system and battery integrations are implemented per project, for hardware that supports it.

We do not claim it works with any battery. Battery integration is specific work against a specific protocol, and anyone who tells you otherwise is describing a sales position rather than an engineering one. If you have a site in mind, tell us the equipment and we will tell you whether it is supported today or what integrating it would involve.

Availability

The Edge EMS is commercially ready and orderable. Hardware and integration are scoped per project; the linked platform monitoring for industrial and commercial sites is covered on the pricing page.

Read next

The Helios Platform is the cloud side — fleet monitoring, savings reporting and the installer CRM. Net billing in Cyprus explains why self-consumption control is now where the economics of a battery site sit.