Does Helios switch my assets directly?

No. Helios recommends. A command moves only after operator approval, and your gateway enforces site safety interlocks before any field write. Live control sits behind authentication, audit, approval, and rollback.

Helios Dispatch Interface · HDI 1.0

Build one gateway. Deploy on every Helios site.

HDI is the open, versioned contract between Helios and your site assets. Implement it once and certify a bridge that turns Helios energy decisions into the protocols you already run.

Request sandbox access → Certify in a lab

schema helios.dispatch.command.v1 contract REST source access not required

Shift Load. Cut Power Costs.

AI is bound by megawatts. Not by hardware.

Scalytics Helios turns grid signals, market pricing, and weather forecasts into workload placement. Modulate your data center load to match intermittent renewable energy over a standard telemetry backbone.

Book your call

Why HDI

One contract instead of an API per customer

Helios plans energy-aware operations across batteries, electrolyzers, flexible loads, and grid programs. Your gateway translates Helios energy semantics into Modbus, OPC UA, SunSpec, MQTT, BACnet, OpenADR, or vendor APIs. You do not embed inside Helios.

One contract

Single schema

helios.dispatch.command.v1, not a bespoke API for every site or customer.

Field layer

You own it

Auditable

By design

Every command carries command_id, status_history, and closed-loop feedback.

Delivery

Pull or push

Poll the REST endpoint or consume a JSONL or Kafka outbox. Same envelope either way.

No hardware

Certify in a lab

A reference gateway completes the full lifecycle with no Modbus or OPC hardware.

Who this is for

If you already connect to industrial assets, you are one gateway away

Storage

Battery and inverter OEMs

DERMS and PCS setpoints for charge and discharge limits.

Sites

EMS and SCADA integrators

Site loads, electrolyzers, and hydrogen storage behind one normalized contract.

Grid

Utility and DR vendors

OpenADR events, dynamic export limits, and grid-operator signals.

Compute

HPC and workload schedulers

Shift deferrable compute into renewable-surplus windows as one flexible load.

Onboarding

Four steps from registration to feedback

Your gateway registers its adapters, polls for delivered commands, executes against your protocol behind site interlocks, then reports the outcome back to Helios. The same loop is what you certify.

1Register

Declare your gateway

Tell Helios which adapters, protocols, and delivery mode your bridge supports.

PUT /api/v1/sites/{site_id}/dispatch/gateway

→

2Poll

Pull commands

Read commands where status is delivered and adapter_id matches your bridge.

GET /api/v1/sites/{site_id}/dispatch/commands

→

3Ack and execute

Map and write

Acknowledge, map action and recommended_kw to your protocol, enforce interlocks, write.

POST /api/v1/dispatch/commands/{id}/ack

→

4Feedback

Report the outcome

Post execution result with the same command_id for closed-loop provenance.

POST /api/v1/feedback/dispatch

pending→ delivered→ acknowledged→ executing→ executed failed / expired / cancelled

A certification pass is delivered to acknowledged to executed, with a matching command_id in feedback and the correct status_history transitions.

What Helios sends you

Energy semantics, not raw registers

Helios emits a semantic action such as discharge_battery at 40 kW, not register 40001 equals 4000. Your gateway owns the mapping to the physical point.

// helios.dispatch.command.v1
{
  "action": "discharge_battery",
  "adapter_id": "derms-battery",
  "asset_id": "battery-main",
  "recommended_kw": 40.0,
  "horizon_start": "2026-06-24T18:00:00Z",
  "horizon_end": "2026-06-24T18:15:00Z",
  "command_id": "550e8400-e29b…",
  "status": "delivered"
}

Action	Typical mapping
charge_battery / discharge_battery	Inverter or DERMS kW setpoint
produce_hydrogen	Electrolyzer power or start
cap_flexible_load / shift_load	EMS load cap or shift window
respond_demand_response / reduce_export	Utility DR or export limit
shift_gpu_workload_here / away	Scheduler routing or deferral
curtail_last_resort	Site controller interlock

Certify in a lab

No Modbus required

Helios ships a reference pull gateway. It registers, polls, logs simulated protocol mappings, acknowledges, and posts feedback, proving the full lifecycle before you connect real hardware.

# run the reference sim-gateway
export HELIOS_JWT_SECRET=your-secret
export HELIOS_BASE_URL=https://sandbox.helios.example
python scripts/hdi_sim_gateway.py --register --once

# registers, polls GET /dispatch/commands,
# logs simulated Modbus writes (no fieldbus I/O),
# acks each delivered command, posts feedback

Gateway id chosen and documented for your customers
supported_adapters list matches your product scope
Poll, ack, feedback loop implemented with command_id linkage
Failed and interlock paths return outcome failed with notes
Sim-gateway run recorded as certification evidence
Production mapping documented per action

API at a glance

Four endpoints, role-scoped

Every protected route expects a Bearer JWT and the zero-trust headers Authorization, x-tenant-id, x-site-id, x-role, and x-correlation-id.

Step	Method	Endpoint	Role
Register	PUT	/api/v1/sites/{site_id}/dispatch/gateway	dispatch:gateway
Poll	GET	/api/v1/sites/{site_id}/dispatch/commands	plan:read
Ack	POST	/api/v1/dispatch/commands/{command_id}/ack	dispatch:gateway
Feedback	POST	/api/v1/feedback/dispatch	dispatch:gateway

FAQ

Integrator questions

No. HDI is a small versioned REST contract. You implement against helios.dispatch.command.v1 and keep your register maps, scaling, and safety interlocks inside your own gateway. Any integrator can build a bridge without Helios source access.

No. The reference sim-gateway completes register, emit, poll, ack, and feedback in a lab and logs simulated protocol writes with no fieldbus I/O. You replace the simulated mapping with real protocol writes for production.

Helios emits energy semantics, not registers. Your gateway maps them to Modbus, OPC UA, SunSpec, MQTT, BACnet, OpenADR, or vendor APIs. One contract comes in, your protocols go out, and the same envelope works for pull or push delivery.

No. Helios recommends. A command moves only after operator approval, and your gateway enforces site safety interlocks such as battery reserve, electrolyzer safety state, grid emergency signals, and breaker or PCS fault bits before any field write. Live control sits behind authentication, audit, approval, and rollback.

Get started

Request sandbox access and certify in your own lab

We provide the Helios API endpoint, a tenant, and dispatch:gateway credentials. Run the sim-gateway in your CI, then submit your gateway profile and certification evidence.

Request sandbox access → Back to Helios