Enexa
Simulation Overview
  • Input SummaryAll configuration parameters
  • Simulation AlgorithmsReactive vs Smart EMS explained
  • Result OverviewSide-by-side comparison
Configuration
  • Location SetupEquipment specs & constraints
  • FinancialsCosts, income & margins
  • Solar ProductionPV generation profile
  • Charging SessionsEV demand profile
  • Not ModeledKnown gaps & limitations
Reactive BMS
  • BMS AlgorithmHow the reactive BMS works
  • BMS ReactiveRule-based simulation results
SmartEMS
  • SmartEMS AlgorithmHow the 2-layer optimizer works
  • SmartEMS ConfigPlanner tuning parameters
  • SmartEMS ResultsOptimized simulation output
  • SmartEMS DispatchingGate logic & energy flow rules
Solution Overview
  • Solution OverviewArchitecture & responsibilities
  • Comm ArchitectureAPI integration patterns
  • Middleware APITelemetry & command schema
  • Onboarding & ConfigMaster data & config API
  • Exception HandlingFallbacks & failure scenarios
Prototype
  • Site MonitoringReal-time telemetry dashboard
  • Dispatch LogsCommand execution & verification
  • Impact DashboardSavings & value demonstration
  • What-If ScenariosScenario analysis & comparison

Communication Architecture

API integration patterns between Enexa Platform and Amperio Middleware

Key Terminology

Enexa Platform

Cloud-based optimization platform that manages asset registry, configuration, and dispatch scheduling. Sends commands to Amperio Middleware and receives telemetry data.Enexa is responsible for the platform, dashboards, and optimization algorithms.

Amperio Middleware

Centralized backend that handles communication with ADS-TEC ChargePost hardware. Exposes REST API for Enexa integration and translates commands to Modbus/TCP registers.Amperio Team is responsible for the middleware and all ChargePost communication.

The Modbus/TCP communication between Amperio Middleware and ChargePost units is internal to Amperio's implementation. Enexa only interacts with the Amperio Middleware REST API.

Integration Architecture
Simplified API-based integration between Enexa and Amperio systems
Enexa PlatformEnexa-hosted

Asset Registry

Master data

Config Repository

Central settings

Optimization Engine

SOC / Arbitrage

Dashboards

Monitoring

REST API over HTTPS

Commands & Telemetry

Amperio MiddlewareAmperio-hosted

API Gateway

Enexa integration

Modbus Client

Register read/write

Watchdog Manager

2-60s heartbeat

Modbus/TCP (Internal)

Port 502, Function Codes 03/04/06/16

ADS-TEC ChargePost HardwareAmperio-managed

Ultrafast charging (up to 300kW), integrated battery storage (2x 110kW units), grid metering - all via Modbus interface v2.6

Clean Separation of Concerns

Enexa handles optimization, configuration, and UI. Amperio handles all IoT communication and hardware control. The integration point is a well-defined REST API between the two platforms.

API Communication Patterns
How data flows between Enexa and Amperio

API Ownership Guide

Hosted by Enexa

Enexa provides the API endpoint

Amperio calls these APIs to fetch data or push telemetry

api.enexa.io/*

Hosted by Amperio

Amperio provides the API endpoint

Enexa calls these APIs to dispatch commands

api.amperio.io/*

Dispatch Commands

Hosted by Amperio

Enexa calls Amperio's API to send commands

// Amperio hosts this endpoint

POST https://api.amperio.io/v1/dispatch

Authorization: Bearer {token}

{

"site_id": "SITE001",

"command": "set_battery_power",

"params": { "power_kw": -25 },

"timestamp": "2024-01-15T10:00:00Z"

}

Enexa initiates all commands
Amperio routes to correct site controller internally
Response includes acknowledgment status

Telemetry Data

Hosted by Enexa

Amperio calls Enexa's API to push telemetry

// Enexa hosts this endpoint

POST https://api.enexa.io/v1/telemetry

Authorization: Bearer {token}

{

"site_id": "SITE001",

"timestamp": "2024-01-15T10:00:01Z",

"battery": { "soc_pct": 65, ... },

"grid": { "import_kw": 35, ... }

}

Amperio aggregates data from site controllers
Push frequency: every 1 second
Enexa stores and processes for optimization

Configuration Sync

Hosted by Enexa

Amperio calls Enexa's API to fetch configuration

// Enexa hosts this endpoint

GET https://api.enexa.io/v1/config/{site_id}

Authorization: Bearer {token}

// Returns site configuration

{ "battery": {...}, "grid": {...} }

Enexa is master for configuration
Amperio polls on startup and periodically
Version tracking for change detection

Status & Health

Both systems host APIs

Each system exposes health endpoints

// Enexa hosts - Amperio calls to report status

POST https://api.enexa.io/v1/status

{ "site_id": "SITE001", "online": true }

// Amperio hosts - Enexa calls to check health

GET https://api.amperio.io/v1/health

Site online/offline status
Middleware health monitoring
Alert propagation
Master Data & Onboarding APIs
APIs for asset registry, controller settings, and onboarding process

Single Source of Truth: Enexa stores all asset master data, configuration, and firmware information. Amperio Middleware fetches this data via API, ensuring consistency across all sites and controllers.

Asset Registry APIs

Hosted by EnexaAmperio calls these to fetch master data
GET /v1/sites

List all sites accessible to the middleware

{ "sites": [{ "id": "SITE001", "name": "..." }] }

GET /v1/sites/{site_id}/assets

Get all equipment registered at a site

{ "battery": {...}, "chargers": [...], "meters": [...] }

GET /v1/controllers/{controller_id}

Get controller details and assigned assets

{ "id": "CTRL001", "assets": ["BAT1", "CHG1"] }

GET /v1/equipment/{type}/{id}/specs

Get equipment specifications (capacity, limits)

{ "capacity_kwh": 200, "max_power_kw": 100 }

Controller Settings APIs

Hosted by EnexaAmperio calls these to fetch/sync configuration
GET /v1/controllers/{id}/config

Fetch full controller configuration

{ "version": 5, "settings": {...}, "limits": {...} }

GET /v1/controllers/{id}/config/version

Check if config has changed (for polling)

{ "version": 5, "updated_at": "2024-01-15T..." }

GET /v1/firmware/latest/{device_type}

Get latest available firmware version

{ "version": "2.1.0", "url": "...", "sha256": "..." }

POST /v1/controllers/{id}/firmware/status

Report current firmware version to Enexa

{ "current_version": "2.0.5", "status": "ok" }

Onboarding APIs

Hosted by EnexaAmperio calls these during site setup
Step 1
POST /v1/controllers/register

Register new controller with Enexa, receive credentials

Request: { "serial": "...", "site_id": "..." }

Response: { "api_key": "...", "config_url": "..." }

Step 2
GET /v1/controllers/{id}/bootstrap

Fetch initial configuration for first-time setup

Response: { "config": {...}, "assets": [...] }

Step 3
POST /v1/controllers/{id}/activate

Confirm successful setup and go live

Request: { "status": "ready", "tests_passed": true }

Response: { "activated": true }

Security Requirements
Authentication and data protection

TLS Encryption

All API communication over HTTPS with TLS 1.3

OAuth 2.0 / API Keys

Bearer token authentication for all API calls

IP Allowlisting

Optional: restrict API access to known IPs

Token Expiry

Access tokens expire after 1 hour, refresh tokens for renewal

Audit Logging

All API calls logged with timestamp, source, action

Rate Limiting

API rate limits to prevent abuse (configurable)

API Error Handling
How to handle communication failures

Enexa Cannot Reach Amperio

  • - Retry with exponential backoff (1s, 2s, 4s, ...)
  • - Queue commands for later delivery
  • - Alert operators after 60 seconds
  • - Dashboard shows middleware status

Amperio Cannot Reach Enexa

  • - Continue with last known schedule
  • - Buffer telemetry locally (up to 24 hours)
  • - Switch to fallback mode after 60 seconds
  • - Replay buffered data when reconnected

Amperio Disconnection Handling

When Enexa API is unreachable, Amperio Middleware must buffer data locally:

1. Telemetry Buffering

  • - Continue collecting telemetry at normal intervals
  • - Store in local buffer with timestamps
  • - Maintain buffer for minimum 24 hours

2. Event Logging

  • - Log all EV session start/stop events
  • - Record fault occurrences with details
  • - Track mode changes and operator actions

3. Local Autonomous Mode

  • - Switch to fallback operation mode
  • - Use last known schedule if available
  • - Apply safety-first conservative limits

4. Reconnection Flush

  • - Transmit buffered telemetry in batches
  • - Send events in chronological order
  • - Confirm receipt before clearing buffer

Enexa Reconnection Procedure

When connection is re-established after an outage, Enexa must perform additional steps to ensure optimal operation:

1. State Synchronization

  • - Fetch current telemetry from all sites
  • - Compare actual SOC with expected SOC
  • - Identify any missed EV sessions or events

2. Schedule Re-evaluation

  • - Re-run optimization with current state
  • - Generate new dispatch schedule
  • - Account for time elapsed during outage

3. Command Re-dispatch

  • - Send updated setpoints to middleware
  • - Verify command acknowledgment
  • - Log reconciliation actions

4. Data Reconciliation

  • - Process buffered telemetry from Amperio
  • - Update historical records
  • - Recalculate metrics for reporting

Note: The re-planning process adds complexity as the optimizer must account for state drift during the disconnection period. If the actual SOC diverges significantly from the planned SOC, the new schedule may differ substantially from the original plan.

Standard HTTP Error Codes

200 OK

Success

401 Unauthorized

Invalid/expired token

429 Too Many Requests

Rate limited

503 Service Unavailable

System down

Summary
Simple REST API integration - No complex IoT protocols for Enexa to implement
Clear ownership - Amperio owns IoT/MQTT, Enexa owns optimization/UI
Enexa is master for configuration - Single source of truth for site settings
Standard security - HTTPS + OAuth 2.0, no special infrastructure
Graceful degradation - Both systems handle disconnection scenarios