BESS Remote Monitoring: What Must Continue When the Internet Fails?
BESS offline control and remote monitoring are different functions. Losing an internet connection may remove a dashboard or remote dispatch path, while protective functions and approved local operation should follow their own defined behaviour. A buyer needs to know exactly which functions remain available, which stop and how the system returns to connected operation.
That requirement cannot be inferred from a communication-port list. The EPC should separate the battery’s local protection, site dispatch, remote visualisation and remote commands in the design and acceptance plan. This guide explains the evidence to request and uses a hypothetical stale-command example to show why recovery needs as much attention as disconnection.
Key Takeaways
- Distinguish internet loss from loss of a required local measurement or controller.
- Define command expiry, local alarms and stored records before enabling remote dispatch.
- Test reconnection against current site conditions, not an old command queue.
On this page
- Map four functions before discussing connectivity
- Specify disconnected operation as an observable state
- A stale charging command can change site demand
- Product interfaces identify questions, not guarantees
- Local visibility must remain useful
- Test recovery without losing the event record
- Ownership continues after handover
Map four functions before discussing connectivity
Start with local protective functions. Identify the relevant BMS, PCS and other protective devices and the approved behaviour when measurements or equipment conditions become unacceptable. These functions have a different purpose from a cloud portal. The design should show their actual dependencies rather than assume they all use the same communication path.
Next, map site dispatch. The EMS may use a local connection meter, operating schedule, source status and reserve rules to issue power requests. State which functions are configured locally and which depend on remote input. A local controller can still depend on a failed local link even while the internet remains available.
Remote visualisation is a third function. It presents measurements, status and alarms to users, but its absence does not by itself establish whether local operation stopped. The owner needs a local way to determine current state when the remote portal cannot be reached.
Remote commands form the fourth function. They can change the site’s power flow or operating priorities. Define who can issue them, which limits constrain them and how they expire. The BMS, EMS and PCS explanation provides background; the procurement drawing should turn those roles into a project-specific dependency map.
Specify disconnected operation as an observable state
For each connectivity event, state what the operator should see and what equipment may do. Internet loss, loss of the cloud service, loss of the site meter, loss of an inverter link and loss of a local controller are separate cases. Combining them under “offline mode” hides material differences.
A written state table can make those differences clear:
| Event | Buyer must establish | Acceptance evidence |
|---|---|---|
| Internet unavailable | Local operating functions and visible alarm | Witnessed disconnected-mode response |
| Remote platform unavailable | Command treatment and local access | Defined timeout and operator indication |
| Site measurement stale | Permitted fallback and connection-limit treatment | Approved meter-loss test |
| Equipment link lost | Local limits, isolation or other authorised response | Model-specific control evidence |
| Connection restored | State reconciliation and command validity | Recovery test and event log |
The table does not prescribe a universal fallback. The appropriate response depends on the site objective, connection agreement and approved protection design. Require the supplier to populate it for the actual offered configuration.
The DOE solar cybersecurity guidance discusses connected distributed-energy controls and their exposure. Treat that as a reason to define dependencies and access carefully. An internet-connected system should not be described as cyber-certified without applicable evidence.
A stale charging command can change site demand
Assume a hypothetical site has a 200 kW import ceiling and a 150 kW building load. A permitted remote charging request of 50 kW would bring the conceptual import to 200 kW. The example assumes that charging request is supported by the selected equipment and approved site design.
Now suppose the remote link fails and building demand rises to 180 kW. Retaining the old 50 kW charging request without a current local constraint would imply 230 kW import. The problem is the stale command and changed load, not a shortage of battery energy.
An approved local rule could constrain or stop economic charging when the necessary information is unavailable. If the example’s charging request becomes zero, building demand alone would be 180 kW. That arithmetic illustrates a possible condition; it does not prescribe the correct fallback for every site. The responsible designers must determine the actual rule.
When the remote link returns, replaying the old charging request would recreate the conflict if the building still consumes 180 kW. Specify command timestamps, validity windows, acknowledgement and reconciliation against current measurements. Recovery should treat an old request according to the approved policy, rather than automatically giving it fresh authority.
| Illustrative condition | Building demand | Charging request | Conceptual grid import |
|---|---|---|---|
| Original state | 150 kW | 50 kW | 200 kW |
| Changed load, stale request retained | 180 kW | 50 kW | 230 kW |
| Example charging request removed | 180 kW | 0 kW | 180 kW |
These are invented planning values. A live acceptance test needs approved methods and the actual site’s measurement and operating limits.
Product interfaces identify questions, not guarantees
The BOOSTESS brochure specifies a 125 kW / 261 kWh liquid-cooled cabinet with CAN, Ethernet and RS485 interfaces and CAN2.0 and Modbus TCP/RTU protocols. Those are documented communication options. They do not, by themselves, establish cloud dependency, offline scheduling, data retention or cybersecurity performance.
Request the offered configuration’s control architecture and sequence of operations. Identify which device reads the connection meter, where reserve settings reside and which functions continue when internet access disappears. Obtain evidence for local operator access and the handling of remote requests. The answers need to match the installed software and equipment revisions.
The cabinet’s nominal energy and rated output also do not establish outage behaviour. A communication failure and a grid outage are different events. If the owner expects backup operation during either or both, verify the supported modes, switching arrangement and load requirements separately. Keep connectivity tests distinct from power-source tests.
A system integration brief should therefore include the dependency table and required evidence. This turns “remote monitoring included” into a set of verifiable functions, while keeping unsupported capabilities out of the procurement commitment.
Local visibility must remain useful
Ask how staff can determine the system’s state without the remote portal. The agreed local interface should identify availability, active restrictions, relevant alarms and whether the last remote command remains valid. Define which actions staff are authorised to take and which require technical support.
Alarm routing needs an offline case too. A message that relies entirely on internet delivery may not reach anyone during the failure that matters. Establish the relevant local indication and escalation route through the site’s operating plan. Do not assume a cloud notification service supplies that function.
Data retention is another practical boundary. Request the available local history, storage duration, behaviour when space fills and method for recovering records. After reconnection, the owner should be able to distinguish missing intervals from zero energy or normal operation. An uninterrupted chart can be misleading if its gaps are silently filled.
The NREL building resilience guidance discusses controls and monitoring in resilience planning. For this project, assign the operator the specific information needed during a disconnection. The source does not establish a particular cabinet’s offline capability or retention period.
Test recovery without losing the event record
An acceptance programme should include authorised loss of each relevant communication path, verification of the agreed local state and controlled recovery. Record which path was interrupted. Disconnecting the internet does not test loss of a local meter cable or an inverter communication link.
During recovery, check current-state reconciliation, expired commands, duplicate requests, clock alignment and alarm acknowledgement. Verify that the controller uses the approved limits before resuming economic dispatch. The owner should be able to see the transition and understand any service still unavailable.
Review exported records from the same event. They should identify timestamps, data quality or gaps where supported, command history and relevant alarms. Establish what the system actually records rather than assuming every useful field exists. If a field is unavailable, document the limitation and agreed alternative evidence.
The grid-connected versus off-grid explanation describes a separate operating distinction. Reconnection testing should stay tied to communication recovery unless the approved programme also includes electrical source transitions. Keep test results precise about what they demonstrate.
Record whether a proposed software change affects monitoring alone or also alters local control and command handling. For the documented cabinet, supported communication interfaces provide connectivity options, but the tested behaviour belongs to the installed configuration. An apparently small gateway replacement can change timestamps, command acknowledgement or timeout treatment. Review those functions and preserve a rollback plan through the authorised change process before relying on the new connection during unattended operation.
Ownership continues after handover
Assign responsibility for accounts, remote access, software changes and dependency documentation. A monitoring platform update or new dispatch provider can alter the original architecture. Review those changes before enabling new command rights, and repeat affected acceptance scenarios where needed.
Give the operator an incident record template: time detected, affected connection, local state, active restrictions, actions taken and recovery evidence. The record helps distinguish a remote-service failure from an equipment or measurement problem. It also preserves the information suppliers need to investigate the event.
Can a BESS operate without the internet?
That depends on its configured architecture and intended function. Obtain and test the local operating sequence. A communication-port list or dashboard demonstration cannot answer the question completely.
Should old commands resume after reconnection?
Only according to the approved validity and recovery policy. Current limits, measurements and operating state must be reconciled. The owner should be able to verify how expired or conflicting requests were handled.
What is the essential quotation requirement?
Require a dependency map, disconnected-state table, local visibility description and recovery test plan for the offered configuration. Those documents give the buyer a concrete basis for assessing offline operation and remote monitoring without relying on unverified platform claims.
