Integration approach
Four logins, four schemas, four reporting templates. Or one platform that reads them all.
A multi-OEM portfolio means multiple inverter brands, multiple BESS vendors, sometimes switchgear from a third manufacturer, and a DG controller from a fourth. Each comes with its own portal, its own alarm philosophy, its own historian, and its own report format. Operators stitch the picture together by hand. Owners see a different version. Lenders see a third. LumeTrax® reads all of them, on the protocols the field already speaks, and renders one truth.
No specific vendor names on this page until written no-objection / partnership permission is in place. Industry protocols are listed below.

Why protocol-first instead of per-vendor adapters
If we built a custom adapter for every OEM, we’d be selling integration tax — not a platform.
OEM ecosystems publish their data over a small set of industrial protocols. We chose to engineer once against those protocols, deeply, instead of selling a per-vendor ‘connector’ library that customers have to keep buying every time the field changes. New ecosystems are added when the field needs them. The integration isn’t a paywall.

The protocols the field actually speaks.
| Protocol | What it covers |
|---|---|
| Modbus TCP / RTU | The lingua franca of industrial control — most inverters, BESS PCS, tracker controllers, weather stations, and meters |
| IEC 61850 | Substation automation, switchgear, protection relays — required for utility interconnection in many jurisdictions |
| SunSpec | Standardised data model for solar inverters, meters, and BESS — vendor-independent within the standard |
| MQTT | Lightweight pub-sub for distributed-asset telemetry, often used at the edge / gateway layer |
| OPC UA | Modern industrial connectivity, increasingly common in newer-build BESS and modern PCS |
| OEM APIs | Where the vendor exposes a documented API beyond the standard protocols above — used per ecosystem as the field needs |
The protocol set above covers every major OEM ecosystem we have encountered in renewable assets. New ecosystems are added when the field requires them. The Core questionnaire confirms scope per asset.
Three principles
Protocol-first. Standards-aligned. Documented per deployment.
Protocol-first
Standards-aligned
Documented per deployment
Where ingestion runs
Hardened on-site or near-site, sized to the deployment.
Core ships with an industrial-grade edge gateway that handles ingestion, local supervisory functions, offline buffering during network outages, and tenant-side data normalization before sync. Hardware is sized to the deployment in the Core questionnaire — environmentally rated, redundant-power, often dual-NIC for OT/IT segregation. The gateway is a real industrial control device, not a Raspberry Pi.
| Variant | When to use it |
|---|---|
| Single-site gateway | Standalone plant; gateway pinned to local OT network with one upstream sync path |
| Multi-site gateway with regional aggregation | Portfolio of plants with regional infrastructure; gateways aggregate to a regional historian before central tenant sync |
| High-availability (HA) gateway pair | Mission-critical sites where gateway redundancy matters — failover handled at the OT layer |
| Air-gapped gateway | No upstream connectivity; full operations run inside the customer perimeter |
What "normalised" actually means
Same hierarchy. Same KPI definitions. Same event taxonomy. Across every plant, every vendor.
The LumeTrax tenant hierarchy — Client Organization → Portfolio → Plant → Subsystem → Asset → Tag/Point/Event — is enforced at ingestion. Vendor-specific data shapes are normalised into this hierarchy at the gateway. The platform sees one consistent data model regardless of which vendor's equipment generated the source telemetry. Cross-portfolio comparisons work because the comparison happens at the model level, not at the wire-protocol level.
What we connect to.
| Class | Protocols typically used |
|---|---|
| PV inverters | SunSpec · Modbus TCP / RTU · OEM APIs (per vendor) |
| BESS / PCS | Modbus TCP · OPC UA · IEC 61850 · OEM APIs |
| Switchgear / protection relays | IEC 61850 (GOOSE, MMS) · Modbus TCP / RTU |
| Trackers | Modbus RTU / TCP · OEM APIs |
| Met stations / weather sensors | Modbus RTU · MQTT · OEM APIs |
| Meters | Modbus TCP / RTU · IEC 61850 · DLMS (where applicable) |
| DG / genset controllers | Modbus RTU · CAN · OEM APIs |
| PPC / plant-level controllers | IEC 61850 · OPC UA · Modbus TCP |
| Existing SCADA / historian | OPC UA · ODBC · API export · CSV import (transition only) |
Per-asset connector confirmed in the Core questionnaire. Where a vendor's documented protocol coverage is partial, the questionnaire surfaces what data is and isn't extractable.
Data out, on your terms.
- REST API — read access to KPIs, events, work orders, audit log per tenant
- Webhook events — push notifications on configurable triggers (alarm, work-order state change, KPI threshold)
- Scheduled exports — CSV / Parquet to customer-owned storage per documented cadence
- SIEM integration — audit-log export to customer security infrastructure
- Data warehouse sync — for customers running their own analytics stack on top of LumeTrax operating data
Where downstream integration is in scope (CMMS, ERP, BI, lender reporting), the integration design is part of the engagement scope and documented in the runbook.
When the standard set isn't enough.
Where a deployment requires a connector outside the standard protocol set — a closed proprietary protocol, a legacy serial protocol, or a vendor-specific API extension — a custom connector is sized at engagement and quoted separately. The connector is documented (input format, normalised output, fail-safe behaviour, supported version range), maintained as part of the platform, and made available to other customers if the connector becomes broadly applicable.
Custom connectors are not the default path; they're the considered path when the asset's economic value justifies the engineering investment. The questionnaire surfaces whether a deployment needs one before commercials are agreed.
What integration actually takes.
| Stage | Typical duration |
|---|---|
| Scoping (Core questionnaire) | 2–4 weeks |
| Engineering design (per-asset register maps, protocol commissioning plan, OT/IT segmentation, gateway sizing) | 4–8 weeks |
| Field commissioning (gateway install, protocol commissioning per asset, control-loop verification, alarm-and-event sign-off) | 2–6 weeks per site |
| Operator hand-off (training, runbook delivery, support tier activation) | 1–2 weeks |
Standard utility-scale single-OEM plants with documented register maps commission inside weeks. Mixed-OEM brownfield assets with undocumented field devices take longer — the questionnaire surfaces those variables before commercials.
Architecture review