Every monitoring platform claims "easy integration". Here is what that actually means on Attral — the whole path from a gateway on your site to a live dashboard, in one short read.
One token per site
When you create a site in the console, Attral issues a device token on the spot. That token is the only credential your gateway needs — no OAuth dance, no per-vendor SDK. Rotate the site, rotate the token.
One JSON endpoint
Whatever the hardware speaks on the wire — Modbus TCP/RTU, SunSpec, CAN off a BMS, a vendor API — your gateway or datalogger normalises it into a small JSON reading and POSTs it:
curl -X POST https://attral.energy/api/operate/ingest \
-H "Content-Type: application/json" \
-d '{"token":"dev_…","ac_kw":1200,"load_kw":800,
"soc":72,"batt_temp":31,"soh":97,"pr":0.8}'The body is deliberately small and flat — a handful of numeric fields, not a nested vendor schema. That keeps the gateway code trivial in any language and makes the payload cheap to send over a metered or marginal link.
Normalise at the edge, not in the cloud
The one job that stays on-site is normalisation: turning whatever the hardware speaks into that small JSON reading. A Modbus register map, a SunSpec model, a CAN frame off a BMS and a vendor REST call all look different on the wire, and they all reduce to the same set of numbers — AC power, load, state of charge, battery temperature, State of Health, performance ratio. Doing that translation at the edge means the cloud never has to know which brand produced a reading, and adding a new device type is a change to one small gateway mapping, not to the platform.
This is also what makes the platform genuinely vendor-neutral rather than vendor-neutral-in-marketing. The ingest contract is the same for a ₹40,000 rooftop inverter and a containerised grid-scale BESS. The hardware differences live in the connector, and stop at the gateway.
Batch, buffer and backfill
Field uplinks are not data-centre uplinks. A rural C&I site may lose its 4G link for minutes or hours. So the endpoint accepts either a single reading or a batch:
{"token":"dev_…","readings":[
{"ts":1721190000,"ac_kw":1180,"soc":71,"batt_temp":31, …},
{"ts":1721190060,"ac_kw":1204,"soc":72,"batt_temp":31, …},
… up to 5,000 readings …
]}Each reading carries its own timestamp, so a gateway can buffer locally while the link is down and flush the backlog when it returns — history backfills into the right place on the timeline instead of all landing at "now". A batch is capped at 5,000 readings per call, which is a comfortable margin for a site that samples every few seconds and reconnects after an outage. Because each reading is timestamped, re-sending an overlapping window is safe: the platform is ordering by time, not by arrival.
One credential, easy to rotate
The device token is intentionally the only secret on the gateway. There is no long-lived OAuth client, no per-vendor API key vault to manage on the edge device. A token maps to exactly one site, so a compromised or decommissioned gateway is contained to that site and revoked by rotating a single value in the console. Tokens travel over HTTPS only, and because they are scoped per site, the blast radius of any one of them is small by construction.
Alerts on every reading
Ingestion is not just storage — every stored reading passes through the alert engine immediately, while it is still fresh. The checks that matter for a battery asset run on each sample:
- Battery temperature limits — the earliest signal of a cooling or derating problem, and the one with real safety weight.
- Low state of charge — a pack sitting too low for too long is both a service risk and an aging accelerant.
- Performance-ratio checks that are daylight-aware — a PR alarm at midnight helps nobody, so the check understands when generation is actually expected.
Evaluating on ingest, rather than on a periodic batch job, is what turns "we noticed at the monthly review" into "someone got a push notification in the same minute." Duplicate suppression keeps one live issue as one alert instead of a hundred, so operators trust the alerts enough to act on them.
Seconds to the screen
The console and the native apps refresh the fleet view on a short interval. From the moment your gateway sends a reading, the number on the operator's phone is at most one refresh away — and the AI analyst reads the same stored data on its next pass, so its recommendations are drawn from the live fleet, not a stale export.
That is the whole integration story, and it is deliberately short: create a site, take the token, normalise your hardware into one small JSON shape, and POST it to one URL. Everything after that — storage, alerting, State of Health, the AI analyst, the native apps — is the platform's job, not yours. Try it against the demo console or talk to us about your fleet.