AECC Open Documentation System Overview

AECC has opened five documentation sets around the same ecosystem of data loggers and energy management devices (CT meters, infrared meter readers, P1 meters, smart plugs, Linky meter readers, storage inverters, etc.), each addressed to a different integration party. This document helps developers quickly understand the positioning and applicable scenarios of each document, and choose the right way to integrate.

1. Documentation at a Glance

Document Access Method Target Users Key Capabilities Online Document
APP SDK Bluetooth (short-range, local) Mobile App developers who need provisioning / acquisition capability Device discovery, encrypted communication, WiFi provisioning, data logger register read/write, connectivity status monitoring View doc
Cloud API Internet · HTTP API Third-party servers that need active query and control Rated / real-time data query, single and batch parameter setting, storage operating mode, time-of-use tariff View doc
Cloud MQTT Internet · MQTT subscription Third-party platforms that need passive real-time data sync DMS data forwarding, topic subscription, continuous push of rated data and monitoring data View doc
LAN Local API LAN · TCP On-site in-house systems / gateways that need local device access mDNS discovery, JSON data read/write, energy control parameters, Modbus RTU/TCP passthrough View doc
HomeAssistant Integration LAN · HA integration Smart-home users running Home Assistant Device list, real-time power, energy flow diagram, control parameters and diagnostics (HA-EMS component) View doc

2. Document Details

1) APP SDK Documentation

A client-side integration solution for terminal App developers, letting their own App communicate directly over Bluetooth with AECC smart data loggers and the products built on AECC Bluetooth modules.

  • Applicable devices:AECC smart data loggers, plus products using AECC Bluetooth modules — CT meters, infrared meter readers, P1 meters, smart plugs, Linky meter readers, etc.
  • Core capabilities:Automatic device discovery, encrypted Bluetooth communication, WiFi provisioning (scan nearby WiFi → send SSID/password → check provisioning progress), reading and writing data logger registers via protocol commands, and monitoring the data logger's connection to the router / server.
  • Supported platforms:Android (AAR/JAR), iOS (framework), Flutter, UniApp.
  • Prerequisites:Please contact AECC officially to obtain the SDK development package, keys and authorization code.

2) Cloud API Documentation

A REST API integration guide for third-party servers, enabling active query and control of storage systems, meters and other devices over HTTP, with interfaces protected by signature authentication.

  • Authentication:The caller uses the platform-issued companyCode and a local signing key key; business parameters are sorted in ascending Unicode order and concatenated with a timestamp to compute an MD5 signature, and the server validates both the time window and the signature.
  • Dynamic tariff API/openApi/price/):Set the storage operating mode and query time-of-use tariffs; no device serial number required.
  • Device service API/openApi/device/):Query rated parameters and real-time data by device serial number, and set parameters for a single device or in batch; query interfaces do not require the device to be online, while set interfaces do.
  • Typical scenarios:Remotely configure storage / meter control strategies, query rated and real-time operating data, push parameters in batch, and obtain tariff data for intelligent scheduling.

3) Cloud MQTT Documentation

An MQTT data forwarding (DMS) integration guide for third-party servers, receiving device-reported real-time data passively by subscribing to topics.

  • Data flow:device → data logger → AECC DMS (MQTT Broker) → third-party platform, pushed with QoS 1.
  • Connection:Connect with the platform-issued mqttId / keyId / keySecret; default port 8091, TCP and SSL supported; topics are assigned by the platform and prefixed with SUB/.
  • Data model:Rated device data (sent once after power-on, type=1) and device monitoring data (pushed continuously at the reporting interval, type=2); the common outer fields include msgId for idempotent message deduplication.
  • Extension:Shared subscriptions $share/{consumer group}/{topic} are supported for load balancing across multiple instances.

4) LAN Local API Documentation

A LAN local interface protocol document for in-house systems, helping developers connect the EMS energy management system into their own application, dashboard, gateway or platform on the same network segment as the device — with no cloud account involved.

  • Integration flow:Discover devices via mDNS first, confirm connectivity by reading data over JSON, then read and write energy control parameters; devices that already speak an industrial protocol can use Modbus passthrough.
  • Protocol channels:Listens on TCP:8080 and supports both JSON and Modbus RTU/TCP passthrough; core JSON fields include Get / Set / Response.
  • Capabilities:Top-level summary data, device lists for storage / plugs / EV chargers / heat pumps, and energy control parameters such as the system maximum power limit, time-segmented power, SOC thresholds and peak shaving configuration.
  • Applicable devices:CT meters, infrared meter readers, P1 meters, smart plugs, Linky meter readers, storage systems, inverters, batteries, heat pumps, EV chargers, and products using the Energy Control Cloud WIFI module.

5) HomeAssistant Integration Documentation

An installation and usage guide for the Home Assistant integration (HA-EMS), bringing EMS devices into a local Home Assistant for visual monitoring.

  • How it works:Devices on the same LAN as Home Assistant are discovered via mDNS and polled in real time over TCP; it works within the LAN only and needs no cloud account.
  • Capabilities:Device list, connection status, real-time power, energy flow diagram, control parameters and diagnostic information.
  • Installation:Unzip the component package into /config, restart Home Assistant, then add the "HA EMS" integration under Devices & Services; manually registering dashboard and card resources is supported as a fallback.

3. Access Method Comparison

Dimension APP SDK Cloud API Cloud MQTT LAN Local API HomeAssistant Integration
Integration party Mobile App Third-party server / cloud platform Third-party server / cloud platform In-house local system / gateway Home Assistant
Network scope Bluetooth (short-range, local) Internet (WAN) Internet (WAN) LAN LAN
Direction Bidirectional (local acquisition & configuration) Active query / control Passive push reception Bidirectional (local read/write) Monitoring-first, control parameters readable / writable
Protocol / channel BLE + proprietary commands HTTP + signature authentication MQTT (TCP/SSL, QoS 1) TCP:8080 JSON / Modbus HA component (mDNS + TCP)
Cloud account required No (official SDK & authorization required) Yes Yes No No
Typical actions Provisioning, register read/write Mode setting, data query, parameter push Subscribe topics, receive device data JSON read/write + Modbus passthrough Install integration, add component, view panel

4. How to Choose

Compare your integration target and network environment against the table below to pick the corresponding document:

My scenario Please read
Our own App needs to provision devices and acquire data locally for users APP SDK Documentation
A self-developed App is already live and we want to add device management / data acquisition modules APP SDK Documentation
A third-party platform needs to remotely query and control storage / meters Cloud API Documentation
Automatically schedule storage charge / discharge based on time-of-use tariffs Cloud API Documentation (dynamic tariff API)
A third-party platform needs to passively and continuously sync device telemetry data Cloud MQTT Documentation
Building a generation / consumption monitoring dashboard on a third-party platform, or fault-code based alarms and O&M workflows Cloud MQTT Documentation (real-time telemetry + fault code fields)
On-site LAN integration at the customer site, without going through the cloud LAN Local API Documentation
Developing a smart gateway that discovers and manages multiple devices locally LAN Local API Documentation (mDNS discovery + JSON)
Private deployment where the customer requires data to stay inside the intranet LAN Local API Documentation
Viewing and controlling storage devices inside Home Assistant HomeAssistant Integration Documentation
Both active control and real-time data are required Use Cloud API + Cloud MQTT together

5. Credentials & Account Notes

The credentials required for cloud access are issued by the AECC platform; please apply through official channels:

Document Required Credentials Purpose
Cloud API companyCodekey Request header identity & local signing key
Cloud MQTT mqttIdkeyIdkeySecret MQTT connection identity & account secret
APP SDK SDK package, key, authorization code Client integration & authorization validation
LAN Local API / HA No cloud account required Direct device access within the LAN

6. Updates & Support

Each document is updated continuously along with product releases. If actual usage differs from the documentation, the latest online version prevails. For any question during integration, please reach us through the Contact Us page on our website.

Contact Us