In short. Generator remote monitoring collects operating data from the genset controller, usually over Modbus through a gateway, and delivers it to a BMS, SCADA or cloud platform that drives alarms, trends and service decisions. A useful scheme is designed backwards from the decisions it must support: is the set ready to start, is it running within limits, did the last outage sequence complete, and is anything trending towards failure. Monitoring is not control; link loss must be alarmed.
Start with the decisions, not the dashboard
Most monitoring projects begin with a list of every register the controller can expose. The better starting point is a short list of questions the facility needs answered without sending someone to the generator room. In our experience four questions cover most of the value.
- Is the set ready to respond to an outage right now? That needs the controller mode, battery voltage, charger status, fuel level, coolant temperature if a heater is fitted, and the absence of latched alarms.
- When it runs, is it running within limits? That needs voltage, frequency, kW, kVA, current per phase, oil pressure, coolant temperature and load percentage.
- Did the last event go as designed? That needs a timestamped event log of mains failure, start, proving, transfer, retransfer, cooldown and stop, with any alarms in between.
- Is anything drifting towards failure? That needs trends of battery voltage during cranking, oil pressure at operating temperature, coolant temperature against ambient and load, and running hours against service intervals.
A register that supports no decision is noise.
The communication path
Almost every genset controller made in the last fifteen years has a serial port speaking Modbus RTU over RS-485, and most current models also offer Modbus TCP over Ethernet. A gateway converts whatever the controller speaks into what the destination needs and, for cloud platforms, adds a cellular or site-network uplink.
| Element | Typical choice | Points to confirm |
|---|---|---|
| Controller interface | Modbus RTU on RS-485, Modbus TCP on Ethernet | Port available, register map published, firmware version |
| Gateway | Protocol converter with cellular or Ethernet uplink | Powered from the set’s DC supply, buffer during link loss, secure by default |
| Network | Site OT network, separate VLAN, or cellular | Who owns it, firewall rules, no direct exposure to the internet |
| Destination | BMS, SCADA, DCIM, vendor cloud platform | Data ownership, alarm routing, retention period |
| Time source | NTP or GPS at the gateway or controller | Event timestamps consistent across the site |
For a site that already runs a building management system, the choice of protocol and the integration method are described in SCADA, BMS and DCIM integration, and the protocol detail is covered under Modbus, IEC 61850, DNP3 and industrial power communications.
The register map problem
Two devices that both speak Modbus do not automatically understand each other. Modbus carries numbers in addressed registers; what each number means, its scaling, its units and its sign convention are defined by the controller maker’s register map and must be configured at the receiving end. Common errors are a kW value read with the wrong scaling factor so that 250 kW displays as 25 or 2,500, an alarm word decoded with the bits in the wrong order so that a high coolant temperature appears as a low oil pressure, and a signed value read as unsigned so that a small reverse power shows as an enormous export. Every point is verified against the controller’s own display with the set running and loaded, and the verified point list is a handover document.
Alarms need owners
An alarm that goes to a screen nobody watches is a notification, not an alarm. Each alarm in the scheme needs a named recipient, a response expectation and an escalation path if there is no acknowledgement. Not-in-auto, fail-to-start, low fuel, low battery, charger fail and communication loss are the alarms that matter between outages, because they are the ones that mean the set will not respond when needed. Shutdown alarms during running matter during an outage. The rest are events, useful for trending but not for waking anyone. The service response that follows an alarm is a separate agreement, and it should be written down, as described under generator AMC.
Communication loss is an operating state
The link will fail, whether through a cellular outage, a site network change or a power cut to a switch. Three things must be true when it does. The set continues to operate on its own local logic with no dependence on the link. The monitoring platform recognises stale data and raises a communication-loss alarm rather than displaying the last good value as though it were current. And the gateway buffers events locally so that the sequence of a transfer that happened during the outage is recovered when the link returns.
Monitoring is not control
Reading data and sending commands are different scopes with different consequences. Remote start, remote stop, remote mode change and remote breaker operation each raise the question of what happens if the command arrives while a technician is inside the enclosure or working on the switchgear. If remote control is wanted, it is engineered deliberately: the local controller retains a lockout that remote commands cannot override, the permission to issue commands is restricted to named users with an audit trail, the set announces an impending remote start locally, and the function is tested from the remote end with a person at the set. Where remote operation is justified, the wider control philosophy is set out in local, remote, automatic and supervisory control philosophy.
Data that earns its keep
Beyond alarms, a few trends change how a fleet is maintained. Cranking battery voltage recorded at every start shows battery decline months before a failed start. Load percentage over time shows whether a set is chronically under-loaded and at risk of wet stacking, or whether site growth has eaten the margin. Comparing kW and kVA exposes power-factor and non-linear-load problems that a kW-only display hides. Running hours and fuel consumption per hour against load support both service scheduling and fuel reconciliation, which on rental fleets is often the first evidence of fuel theft. The maintenance planning guide shows how these trends feed service intervals.
Security
Connecting a generator to a network connects it to everything on that network. Keep the gateway on a segregated VLAN or a dedicated cellular link, change default passwords, disable unused services, avoid exposing Modbus TCP directly to the internet, and know who owns the network and the platform.
Related photographs and videos
More related media (1)
Common mistakes
- Assuming a controller with a Modbus port means the site has monitoring. Without a gateway, a verified point list, alarm routing and a named recipient, nobody is watching anything.
- Skipping point-by-point verification against the controller display. Scaling and bit-order errors produce confident, wrong readings that are trusted until an outage proves otherwise.
- Routing every controller event as an alarm. Operators are flooded, silence the feed, and miss the not-in-auto alarm that mattered.
- Displaying stale data without a communication-loss indication. The dashboard looks healthy during the exact period when the set has stopped reporting.
What to send us
Send the make and model of each genset controller and a photograph of its communication ports, a note on the site network or whether cellular is preferred, the destination system such as a BMS, SCADA or a vendor platform, and the list of questions you want the monitoring to answer. For a fleet, include site locations and the number of sets at each. Use the application engineering enquiry for monitoring and integration schemes.
Questions engineers ask
Can an old generator be remotely monitored?
Yes. If the controller has a serial or Ethernet port, a gateway connects to it directly. If the panel is relay-based with no data interface, a small I/O module can read contacts for running, fault and mode and analogue signals for fuel level and battery voltage, or the controller can be upgraded, which also improves the local logic.
What protocol should I use for generator monitoring?
Modbus is the practical default because almost every genset controller supports it and every BMS and SCADA reads it. Use Modbus TCP where an Ethernet port and a site network exist, and Modbus RTU over RS-485 through a gateway otherwise. SNMP suits IT-managed sites, and IEC 61850 is normally reserved for larger switchgear integration.
Does remote monitoring reduce the need for site visits?
It reduces unnecessary visits and makes necessary ones better prepared, because the technician arrives knowing the alarm history and trends. It does not replace physical inspection of fuel, coolant, belts, hoses and connections, and it does not replace periodic load testing.
How do I know if the monitoring itself has failed?
The platform must raise a communication-loss alarm when data stops arriving within a defined interval, and the gateway should send a heartbeat so that silence is detected within minutes rather than days. Test this by unplugging the gateway during commissioning and confirming the alarm reaches its owner.
Technical content reviewed by Srinivas Reddy, Managing Partner, Reddy Generators. Last updated 19 October 2026.