The BESS stops discharging. The PCS reports a DC-side problem, the EMS reports unavailable capacity, and the cloud portal sends several notifications together. Which message caused the shutdown? The last message on the phone may be a consequence, not the initiating event.
Useful BESS alarm troubleshooting starts by making the site safe and preserving the event record. Follow the manufacturer’s emergency instructions if there is smoke, unusual heat, damage or another hazardous condition; evidence collection must never delay protective action. For a non-emergency service investigation, export the available records before an authorised reset or configuration change.
First establish what stopped, and why operation was inhibited
Separate a warning, a power limitation, an equipment trip and an operator stop. A battery can remain connected while limiting discharge. An inverter can stop for a grid condition while the battery remains healthy. A communications failure can make the EMS report that equipment is unavailable without proving a battery hardware fault.
The distinction follows the different responsibilities explained in our BMS, PCS and EMS guide. Ask each subsystem for its local event record and operating state, rather than expecting an aggregated dashboard to explain the whole sequence.
Use the code list for the exact model and firmware. SMA’s Sunny Boy Storage event-message manual illustrates why this matters: it separates grid events, current limits, measurement issues and battery-related conditions. Its event numbers and corrective measures must not be applied to an HMX system or another inverter family.
Preserve the original clocks as well as the messages
A support package should retain each device’s original timestamp, time zone and available indication of clock quality. Do not silently move all records onto a common timeline and delete the originals. If clocks were not synchronised, document the uncertainty instead of presenting a precise causal sequence that the data cannot support.
Distinguish the time the device generated an event from the time a gateway received it and the time a cloud platform delivered a notification. Buffering and network outages can separate those events. A notification received after a shutdown may describe something that occurred before it.
| Feld | Aufzubewahrender Nachweis | Diagnostic value |
|---|---|---|
| Event identity | Device, serial number, code and original message | Supports model-specific interpretation |
| Time information | Device timestamp, zone and collection timestamp | Distinguishes event order from delivery order |
| Operating context | Grid or island mode and command immediately before the event | Explains which function was active |
| Limits and permissions | Battery charge/discharge permissions and current limits | Shows whether output was intentionally restricted |
| Konfiguration | Firmware, settings revision and recent changes | Identifies the documentation and baseline that apply |
Compare the requested action with the permitted action
The EMS may have requested discharge, but the battery may not have permitted it. The PCS may have received permission, but limited output for its own operating condition. A useful trace includes the requested power, effective battery limits, actual power and state feedback. If one of these is missing, state that limitation in the support ticket.
SunSpec Modbus provides common parameters for monitoring and controlling distributed energy equipment. Standardised naming can assist integration, but a “Modbus supported” claim does not prove which models, fields, update behaviour or vendor extensions are implemented. Obtain the delivered system’s register definitions and units before interpreting a raw value.
Für ein liquid-cooled energy storage installation, collect the thermal subsystem’s relevant events too. A cooling alarm deserves correlation with battery temperatures and limits; it is not automatically proof of cell damage. Avoid replacing hardware solely because a translated alarm label sounds severe.
A plausible sequence is not yet a proven diagnosis
Consider a hypothetical sequence, not an HMX field case: a temperature-related battery limit appears, the permitted discharge falls, the PCS reduces output, and the EMS later reports missed dispatch. This pattern would justify investigating the thermal condition first. It would not, on its own, establish whether the cause was cooling performance, a sensor issue, site conditions or another fault.
The correct next action is evidence-led and manufacturer-approved. Preserve temperature channels, cooling state and limit history; identify which measurements are available and credible. Do not change protective thresholds to make the alarm disappear, or run repeated restart attempts while an unresolved hazardous condition remains.
| Observation | Question to resolve | Anzufordernde Nachweise |
|---|---|---|
| Power falls before the main shutdown message | Was output limited before it was stopped? | Limit values and actual output history |
| Several alarms arrive together | Were they generated together or delivered in a batch? | Local logs and gateway receipt records |
| Problem follows a service visit | What settings or components changed? | Before/after configuration and work record |
| Restart succeeds but the fault returns | Did the initiating condition actually clear? | Recurrence trace under the approved observation plan |
| Remote dashboard is blank | Is equipment stopped or only telemetry unavailable? | Authorised local state confirmation |
Make the closure record more useful than “reset successful”
Der DOE BESS evaluation method assesses performance from measured charge and discharge data. That is different from fault diagnosis, but it reinforces the value of retaining operational evidence after recovery. A system being online again does not prove it has resumed the agreed energy service.
Define the supplier’s service deliverables when ordering commercial and industrial storage: exportable records, a model-specific code list, escalation contacts and a documented return-to-service decision. Agree access to those records before a cloud subscription or service arrangement changes.
Close the ticket with the identified cause, supporting evidence, approved action and any remaining uncertainty. If the cause remains unconfirmed, say so and agree the observation plan. That record protects the owner from repeated disruptions and gives the supplier a better basis for support than another screenshot of the same alarm.