This guide organizes the raw interface documentation into a "run it first, then extend" sequence: discover the device first, then read state, and finally perform control and pass-through. It is best suited for first-time integration: anyone who wants to quickly ingest EMS data into their own application, dashboard, gateway, or platform.

• Applies to AECC EMS local interface integration scenarios.
• Supports HA JSON data interface, energy control parameters interface, Modbus RTU pass-through interface, and Modbus TCP interface.
• For the first joint debug, it is recommended to open only one interface and get the read working first, then extend to settings and pass-through.

If you don't know which interface to start with, follow the sequence below — it saves time.

• Device is powered on and connected to the network successfully.
• Dev machine or gateway is on the same LAN as the EMS device.
• Get the device IP first; the default port is TCP 8080.
• Read first to confirm the message format and response structure, then write.
• Prepare a TCP debug tool, mDNS tool, and Modbus tool.

1. Discover the device via mDNS and record s_ip and s_port.
2. Establish a TCP connection, default port 8080.
3. Send a read-only JSON request first, e.g. get device parameters.
4. Check the response for key fields such as Response, SerialNumber, Target.
5. Once read is confirmed, try energy control parameters.
6. Finally perform settings or Modbus pass-through.

The most important fields in a JSON request are: Get / Set / Response / SerialNumber / CommandSource / Target.

Example request:

{
  "Get": "EnergyParameter",
  "SerialNumber": 1,
  "CommandSource": "Web"
}

mDNS answers two questions: where the device is, and what this device is.

7.1 mDNS Fields

7.2 mDNS Data Example

{
  "_http._tcp": "SXD-mDNS-IF-NKYWLTS011",
  "SXD-mDNS.local": "8080",
  "s_sn": "NKYWLTS011",
  "s_ip": "192.168.3.206",
  "s_port": "8080",
  "s_type": "131"
}

This interface is best suited for monitoring, dashboards, and first-time connectivity tests. Get "device parameters" working first, then expand fields gradually.

It is recommended to look at top-level summary fields first, then expand device lists. This makes debugging easier — is it network, message, or field parsing?

8.1 Minimum Request for Device Parameters

{
  "Get": "EnergyParameter",
  "SerialNumber": 1,
  "CommandSource": "Web"
}

8.2 Response: Top-Level Summary + Multiple Device Lists

{
  "Response": "EnergyParameter",
  "SerialNumber": 1,
  "Target": "Web",
  "Storage_list": [{
    "DevAddr": 1,
    "StorageSN": "ZL-2502250374-00039",
    "StorageStatus": 1,
    "PvChargingPower": 0,
    "AcChargingPower": 0,
    "BatterySoc": 100,
    "BatteryDischargingPower": 50,
    "AcInActivePower": -350,
    "OffGridLoadPower": 0,
    "BatteryChargingPower": 0,
    "PvStringCount": 0,
    "Pv1Power": 0,
    "Pv2Power": 0,
    "Pv3Power": 0,
    "Pv4Power": 0
  }],
  "SSumInfoList": {
    "ControlEnableStatus": 1,
    "MeterTotalActivePower": 0,
    "TotalPVPower": 4,
    "TotalPVChargePower": 0,
    "TotalACChargePower": 0,
    "TotalSmartLoadElectricalPower": 0,
    "AverageBatteryAverageSOC": 60,
    "TotalBatteryOutputPower": 9,
    "TotalGridOutputPower": -35,
    "TotalBackUpPower": 0,
    "TotalChargePower": 0
  },
  "ChargerInfoList": [{
    "DevAddr": 55,
    "lsThirdParty": 0,
    "FansDevType": 0,
    "lsInterconnect": 1,
    "ChargerSN": "SXDI78C594",
    "ChargerStatus": 1,
    "Connector1Status": 0,
    "Connector1Power": 0,
    "Connector2Status": 0,
    "Connector2Power": 0,
    "ConnectorElectricity": 0
  }],
  "PlugInfoList": [{
    "DevAddr": 110,
    "lsThirdParty": 0,
    "FansDevType": 6,
    "lsInterconnect": 1,
    "PlugSN": "NKPG1DDC40",
    "PlugStatus": 0,
    "PlugActvePower": 0,
    "PlugVol": 2359,
    "PlugCurrent": 0,
    "PlugRatePower": 2000,
    "PlugElectricity": 0
  }],
  "HotInfoList": [{
    "DevAddr": 150,
    "lsThirdParty": 0,
    "FansDevType": 6,
    "lsInterconnect": 1,
    "HotSN": "SXDI7A47B8",
    "HotStatus": 1,
    "HotActvePower": 0,
    "HotActvePowerMAX": 1200,
    "HotTEMP": 258,
    "HotTEMPMAX": 470
  }]
}

8.3 Top-Level Key Fields

8.4 Common List Fields

Group by list first, then look at business fields in detail — easiest to stay oriented.

8.5 SSumInfoList Field Details

8.6 Storage_list Field Details

8.7 PlugInfoList Field Details

8.8 ChargerInfoList Field Details

8.9 HotInfoList Field Details

This interface is the entry point for reading and setting control strategies: power limits, time-period strategies, SOC control, and linkage control.

Before writing parameters, read the original values back and save them — especially for power periods, SOC thresholds, and peak/valley strategies.

9.1 Read Request & Response

Request:

{
  "Get": "EnergycontrolparametersList",
  "SerialNumber": 1,
  "CommandSource": "Web",
  "RegControlField": [
    "PhaseRecognitionTrigger",
    "MeterSelector",
    "SystemMaxPowerLimit",
    "PowerRegulationOperatingPoint"
  ]
}

Response:

{
  "Response": "EnergycontrolparametersList",
  "SerialNumber": 1,
  "Target": "Web",
  "ControlInfoField": {
    "EnergyManagement": "0",
    "ScheduledModeEnabled": "1",
    "PhaseRecognitionTrigger": "0",
    "MeterSelector": "1",
    "SystemMaxPowerLimit": "10800,3600,3600,3600",
    "PhaseRecognitionPowerMultiplier": "50",
    "PowerRegulationOperatingPoint": "10",
    "DeviceGridInputPowerLimit": "800",
    "PeakShavingConfig": "0:0",
    "BaseDischargePower": "0",
    "PeriodValidTimestamp": "2024-09-20 00:00:00",
    "InstantControlPeriod": "255,20261231,0,00:00,23:59,800,0,6,100,10",
    "ValleyChargePowerStrategy": "0",
    "SystemAcChargePowerLimits": "4200,1400,1400,1400",
    "VppDispatchPeriod": "255,20261231,0,00:00,23:59,800,100,10,7000"
  }
}

9.2 Write Request & Response

Request:

{
  "Set": "EnergycontrolparametersList",
  "SerialNumber": 2,
  "CommandSource": "Web",
  "SetControlInfoField": {
    "PhaseRecognitionTrigger": "0",
    "MeterSelector": "1",
    "SystemMaxPowerLimit": "10800,3600,3600,3600",
    "PhaseRecognitionPowerMultiplier": "50",
    "PowerRegulationOperatingPoint": "10",
    "DeviceGridInputPowerLimit": "800"
  }
}

Response:

{
  "Response": "EnergycontrolparametersList",
  "SerialNumber": 2,
  "Target": "Web",
  "SetParametersField": {
    "PhaseRecognitionTrigger": "0",
    "MeterSelector": "1",
    "SystemMaxPowerLimit": "10800,3600,3600,3600"
  }
}

9.3 Common Field Reference

9.4 Time Period Fields

[时间段使能],[起始时间],[结束时间],[强制取/馈电功率限制],[允许取电功率限制],[功率控制模式],[充电最大 SOC],[放电最小 SOC]

"1,09:00,23:59,1000,500,0,100,10"

9.5 Other Combined Fields

If you already have standard Modbus RTU frames, there is no need to rewrite business logic — just pass them through.

This interface is suitable for forwarding existing RTU frames directly to EMS. Note that TransmittedData must be a complete RTU frame with CRC, and bytes are separated by spaces.

10.1 Pass-through Field Reference

10.2 Send Example

{
  "Set": "DataTransmission",
  "SerialNumber": 1,
  "CommandSource": "Web",
  "SetCommand": {
    "FunctionCode": 3,
    "TransmittedData": "01 03 FE 06 00 03 56 67"
  }
}

10.3 Response Example

{
  "Response": "DataTransmission",
  "SerialNumber": 1,
  "Target": "Web",
  "CommandResponse": {
    "FunctionCode": 3,
    "ControlState": "succeed",
    "TransmittedData": "01 03 06 00 01 02 03 04 05 2F CE"
  }
}

Modbus TCP is used to directly read EMS-accessed devices' registers, suitable for PLCs, gateways, and industrial hosts.

11.1 Standard Message Examples

Request (0x03):

00 01 00 00 00 06 01 03 FE 06 00 03

Response:

00 01 00 00 00 09 01 03 06 00 01 00 02 00 03