> For the complete documentation index, see [llms.txt](https://docs.voltmasters.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.voltmasters.io/device-integrations/battery-systems/huawei-luna2000-215.md). # Huawei LUNA2000-215 Our EMS supports the **Huawei LUNA2000-215-2S10 Smart String ESS** — a complete C\&I battery cabinet that combines an integrated 108 kW PCS (PCS2000-108K-MB1) with a 215 kWh LFP battery pack behind a single Modbus TCP register map. Unlike the [SmartLogger Hybrid integration](/device-integrations/battery-systems/huawei-smartlogger-hybrid.md), this adapter connects directly to the ESS cabinet. There is no SmartLogger aggregating multiple inverters: one device entry in the EMS controls one physical cabinet. The cabinet exposes its battery and PCS state through a single Modbus TCP endpoint. {% hint style="info" %} This integration requires **controller version 0.0.278 or later**. For a Huawei installation that combines LUNA2000 batteries with SUN2000 inverters behind a SmartLogger, see the [SmartLogger Hybrid documentation](/device-integrations/battery-systems/huawei-smartlogger-hybrid.md). {% endhint %} ### Supported devices | Model | PCS rating | Battery capacity | | ----------------- | ---------- | ---------------- | | LUNA2000-215-2S10 | 108 kW | 215 kWh LFP | The integration communicates over **Modbus TCP**. The cabinet can be reached directly (ESS as the slave node) or via a SmartLogger acting as a Modbus gateway — in both cases the register map and the adapter configuration are identical. Use `config.ip`/`config.port` for the host and `config.slaveId` for the ESS unit address. When multiple cabinets share one SmartLogger gateway, configure each cabinet as a separate device entry with its own slave ID; they share the same pooled Modbus TCP connection. ## How the integration works The LUNA2000-215 is modelled in our EMS as one **PCS parent device** with one automatically created **BMS child device**: * **PCS** — the parent device. Receives the charge/discharge setpoint from the EMS and manages power-on/off of the cabinet. * **BMS** — a proxied child that reports the battery state: state of charge (SOC), bus voltage, bus current and temperature. Created automatically — no separate wiring is needed. ### Control approach #### Active power dispatch Each control cycle the EMS writes the active power setpoint to register `42915` (I32, kW, gain 1000). The device's sign convention is **positive = discharge**; the EMS uses **positive = charge**, so the value is negated on write. Before writing, the setpoint is clamped to the **live per-direction capability** reported by the cabinet (`actualChargingPowerCapability` / `actualDischargePowerCapability`, registers 33215/33217). These values derate with SOC and device state and are the tightest correct bound. Until they have been read, the EMS falls back to ±Pmax (register 32853). The setpoint is not written at all until at least one clamp bound has been read — this prevents an unclamped write at startup. #### Power-on management When the cabinet is idle or shut down (work status register 32034 not in a running or launching state), the EMS writes `1` (Run) to register `42000` to bring it online. The Run command is never sent when the work status is unknown or stale — re-asserting Run on a running unit causes a brief power interruption (verified on hardware), so the guard is strict. #### Reactive power Reactive power is dispatched via register `42914` (I16, % of apparent power, gain 100). The kVar setpoint is converted to a percentage using the cabinet's rated Pmax as the apparent-power base. The register is only written when a reactive setpoint is pending and Pmax has been read. ### What is read back * **Battery (BMS):** SOC, chargeable capacity, dischargeable capacity, rack voltage, rack current, state of health (SOH), highest and lowest pack temperature, BMS state (idle / charging / discharging / fault / offline). * **PCS:** Active power, reactive power, grid frequency, DC voltage, DC current, power factor, maximum charge and discharge power capability, accumulated energy charged and discharged. * **Alarms:** Battery pack faults, balancing module faults, BMU faults, RPCB faults, BCU faults, DCDC faults, PCS faults, safety/fire alarms, and cooling-system alarms — all mapped to individual incident types keyed by Huawei's stable alarm IDs. ### BMS state The proxied BMS state is derived from the work status register and the rack current: | Condition | BMS state | | ------------------------------- | ------------- | | Critical alarm active | `fault` | | Work status = offline (0xB000) | `offline` | | Work status not running | `idle` | | Running, rack current > 0.1 A | `charging` | | Running, rack current < −0.1 A | `discharging` | | Running, rack current near zero | `idle` | A critical alarm forces the BMS state to `fault` and is surfaced as an incident on the same control cycle it is first read. ## Configuration parameters The LUNA2000-215 PCS uses the standard battery device configuration. No extra parameters beyond the connection settings are required: the rated power defaults to 108 kW (derived from the model) and the proxied BMS child is created automatically. | Parameter | Description | | -------------- | ------------------------------------------------------------------ | | **IP address** | IP address of the ESS cabinet or the SmartLogger gateway. | | **Port** | Modbus TCP port (default 502). | | **Slave ID** | Modbus unit address of the ESS cabinet (configured on the device). | ## Validation status The integration is implemented against the LUNA2000B V200R024C00SPC401 Modbus Port Definitions ("C\&I Cabinet Subsystem", section 3) and validated on a LUNA2000-215-2S10 unit on live hardware (June 2026), including sign conventions for active power and rack current under commanded charge and discharge. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.voltmasters.io/device-integrations/battery-systems/huawei-luna2000-215.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.