Skip to content

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.

LumeTrax integration architecture — protocol-first ingestion across OEM ecosystems

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.

OT/IT boundary, ingestion, and unified platform

The protocols the field actually speaks.

ProtocolWhat it covers
Modbus TCP / RTUThe lingua franca of industrial control — most inverters, BESS PCS, tracker controllers, weather stations, and meters
IEC 61850Substation automation, switchgear, protection relays — required for utility interconnection in many jurisdictions
SunSpecStandardised data model for solar inverters, meters, and BESS — vendor-independent within the standard
MQTTLightweight pub-sub for distributed-asset telemetry, often used at the edge / gateway layer
OPC UAModern industrial connectivity, increasingly common in newer-build BESS and modern PCS
OEM APIsWhere 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

We connect over what the field publishes — not by paying for closed-OEM SDKs and bundling the cost into the licence. The integration cost is in the deployment plan, not in a custom-tier line item.

Standards-aligned

Where a standard exists (SunSpec, IEC 61850), we use it. Where a vendor exposes a documented API, we use that. Closed proprietary protocols are addressed only when the asset's economic value justifies a custom connector.

Documented per deployment

Every connector — protocol, polling cadence, register map, fail-safe behaviour, time-stamp source — is documented in the deployment runbook. The customer can read what they're getting.

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.

VariantWhen to use it
Single-site gatewayStandalone plant; gateway pinned to local OT network with one upstream sync path
Multi-site gateway with regional aggregationPortfolio of plants with regional infrastructure; gateways aggregate to a regional historian before central tenant sync
High-availability (HA) gateway pairMission-critical sites where gateway redundancy matters — failover handled at the OT layer
Air-gapped gatewayNo 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.

ClassProtocols typically used
PV invertersSunSpec · Modbus TCP / RTU · OEM APIs (per vendor)
BESS / PCSModbus TCP · OPC UA · IEC 61850 · OEM APIs
Switchgear / protection relaysIEC 61850 (GOOSE, MMS) · Modbus TCP / RTU
TrackersModbus RTU / TCP · OEM APIs
Met stations / weather sensorsModbus RTU · MQTT · OEM APIs
MetersModbus TCP / RTU · IEC 61850 · DLMS (where applicable)
DG / genset controllersModbus RTU · CAN · OEM APIs
PPC / plant-level controllersIEC 61850 · OPC UA · Modbus TCP
Existing SCADA / historianOPC 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 APIread access to KPIs, events, work orders, audit log per tenant
  • Webhook eventspush notifications on configurable triggers (alarm, work-order state change, KPI threshold)
  • Scheduled exportsCSV / Parquet to customer-owned storage per documented cadence
  • SIEM integrationaudit-log export to customer security infrastructure
  • Data warehouse syncfor 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.

StageTypical 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

Want to see the integration architecture against your portfolio?