> 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/alpha-ess.md). # AlphaESS Our EMS supports the **AlphaESS STORION-LC-TB125(-EX)**, an all-in-one commercial battery energy storage system built around the **AlphaESS EMS 5.0** controller. The STORION-LC-TB125 is not addressed cabinet by cabinet. A single **Modbus TCP** connection to the EMS drives the entire system, including up to **25 parallel PCS and battery units**. Because everything is reached through that one connection, our EMS exposes the installation as one parent device with several logical child devices. {% hint style="warning" %} The EMS must be switched to **remote dispatch** before our EMS can control the system. This is a setting in the AlphaESS user interface and cannot be enabled over Modbus. See the setup guide below. {% endhint %} ### Supported devices | Model | Rated power | Role | | ------------------- | ----------- | ------------------------- | | STORION-LC-TB125 | 125 kW | All-in-one battery system | | STORION-LC-TB125-EX | 125 kW | All-in-one battery system | The integration communicates over **Modbus TCP** (default port `502`). ## How the integration works One STORION-LC-TB125 is modelled as a single parent device with three child devices, all served by the same Modbus connection: * **PCS (battery inverter)**: the parent device. Receives the charge and discharge setpoints and reports the system active and reactive power. * **BMS**: reports the aggregate state of charge (SOC), state of health (SOH), chargeable and dischargeable energy, cell voltages and temperatures, and the charge and discharge permissions. * **PV**: reports the combined PV production and yield. The PV is DC-coupled and aggregate-only. * **Grid meter**: the system's head meter, aggregated by the EMS into its own register block and read over the same connection. There is no extra wiring or additional Modbus device to add: the child devices are created automatically from the parent when the device is added. ### Control approach We steer the system through the EMS dispatch interface. Every control cycle the requested setpoints are written again, so the system keeps following our EMS as long as the connection is alive: * **Battery setpoint**: a direct charge and discharge power setpoint, clamped to the system rated power and to the real-time maximum charge and discharge power reported by the device. * **Reactive power setpoint**: a separate reactive power command. * **Dispatch timeout**: the system falls back to its own behaviour when our EMS stops writing, so a lost connection never leaves the battery on an old setpoint. {% hint style="info" %} The PV of this product is DC-coupled and aggregate-only. The dispatch interface exposes no PV curtailment register, so the PV child device is **monitoring-only** and is never curtailed by our EMS. {% endhint %} ### What is read back * **Battery**: state of charge, state of health, chargeable and dischargeable energy, maximum charge and discharge power, total charged and discharged energy, maximum and minimum cell voltage and temperature, charge and discharge permissions, and the forced-charge request on undervoltage. * **PCS**: start/stop state, fault state, DC voltage, current and power, active and apparent power, power factor, grid frequency and ambient temperature. * **PV**: actual production, total generation and installed capacity. * **Grid meter**: per-phase voltages and currents, total active, reactive and apparent power, power factor, and cumulative imported and exported energy. * **System**: on-grid or off-grid work mode and the normal, warning or fault work status. Faults reported by the PCS and by the battery management system are raised as incidents on the device. ## Setup {% stepper %} {% step %} ### Prepare the network Give the EMS a fixed IP address in the same subnet as the Voltmasters controller, and make sure port `502` is reachable between the two. {% hint style="warning" %} Do **not** use `192.168.1.x` or `192.168.2.x` for the dispatch network. Those ranges are already used inside the system: `192.168.1.x` by the internal PCS and BMS bus on ETH1, and `192.168.2.x` by the built-in Wi-Fi access point. Using them makes the dispatch connection unreliable or impossible. {% endhint %} {% endstep %} {% step %} ### Enable remote dispatch on the EMS In the AlphaESS user interface, go to **Control Strategy → Basic Settings** and set: * **Operation Mode**: `Remote Control Mode` * **Local/Remote**: `Remote` * **Dispatch Protocol**: `MODBUS-TCP` {% hint style="warning" %} On EMS 5.0 this is a user-interface setting only. It cannot be switched over Modbus, and the System Mode register keeps reporting `Local_auto` even while dispatch is active. Confirm the setting on the screen, not in the register. {% endhint %} {% endstep %} {% step %} ### Add the device in Voltmasters Add a new device of type **Battery system (PCS)**, brand **AlphaESS**, model **STORION-LC-TB125(-EX)**, and fill in the IP address, port and slave id of the EMS. The battery management system, PV and grid meter are added automatically as child devices. Set the battery capacity and the minimum and maximum state of charge on the battery child device; the rated power defaults to 125 kW on the PCS. {% endstep %} {% step %} ### Verify Check on the device page that the state of charge, the PV production and the grid meter values come in, and that the system follows a manual charge or discharge setpoint. {% endstep %} {% endstepper %} ## Validation status The integration is implemented against the **Alpha EMS ModbusTCP Protocol Point Table V1.6.0** and the **AlphaESS C\&I Modbus TCP dispatch manual V2.0**. Additional functionality may be added over time as integration capabilities evolve. --- # 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/alpha-ess.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.