meters.topology (version 1)
How a building's EOS meters (energy, water, waste) are connected: every meter with its carrier and whether it counts in the building total, the sub-meter tree (parent → child; a parent's consumption includes its children's, and the part no child measures is not sub-metered), what each virtual meter is calculated from with its factor, and overlappingBuildingMeters: virtual building meters fed by another building meter of the same building and carrier, or by its sub-meters, which EOS (like its dashboard) counts both, so the building total includes that consumption twice. Use it to explain a building's metering, to break a total down by sub-meter, and before trusting a building total.
bearerAuthorizationBearer <JWT>A signed-in Relynk user's access token: OAuth 2.0 authorization code with PKCE at https://auth.relynk.io/authorize and https://auth.relynk.io/oauth/token, with audience https://ai.relynk.io/builder. The caller sees exactly what that user may see.
tenantId?stringThe tenant to read. May be left out when the caller belongs to exactly one tenant; GET /me lists them.
uuidapplication/json- body
buildingId*stringA building id (from buildings.list)
^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$uuidcarriers?array<>Only these carriers; omit for all
1 <= items <= 7The function output
application/json- response
buildingId*stringmeters*array<>The building's meters, and the meters elsewhere its virtual meters are fed from
subMeters*array<>virtualSources*array<>overlappingBuildingMeters*array<>curl -X POST 'https://ai.relynk.io/builder/v1/meters.topology/v1' \ -H 'Content-Type: application/json' \ -d '{ "buildingId": "fee3295a-6e55-45b0-a091-7b4de7e39de7"}'{ "buildingId": "string", "meters": [ { "id": "string", "name": "string", "typeKey": "string", "carrier": "electricity", "unit": "kWh", "isBuildingMeter": true, "isVirtual": true, "buildingId": "string", "consumedForUse": "string", "wasteFraction": "string" } ], "subMeters": [ { "parentId": "string", "childId": "string" } ], "virtualSources": [ { "virtualMeterId": "string", "sourceMeterId": "string", "factor": { "kind": "implicit", "value": 0, "areaKey": "string", "derivedFromId": "string", "derivedFromName": "string" } } ], "overlappingBuildingMeters": [ { "virtualMeterId": "string", "carrier": "electricity", "sourceMeterIds": [ "string" ] } ]}meters.list (version 1) POST
EOS meters (energy, water and waste metering: electricity, district heating and cooling, gas, water, waste) with their carrier, unit, whether they count in building totals (building meters) or are sub-meters, virtual (calculated from other meters) or tenant (lease) meters, what they are used for, and until when EOS has processed them. Filter by building, carrier, id, name, buildingMetersOnly or virtual. Feed the ids to consumption.meters; for a building total use consumption.buildings, which sums exactly the building meters. Pages by id: pass nextCursor back until it is null.
consumption.buildings (version 1) POST
Energy, water and waste consumption of buildings from EOS, exactly as the EOS dashboard shows it: per building and carrier (electricity, heating, cooling, gas, water, waste), the sum of the building's building meters (physical and virtual; sub-meters never), per Oslo-time bucket over [from, to), with cost, estimated share, coverage and confidence per bucket and in total. Use this for any building or portfolio consumption, cost or comparison; never add up raw meter points for that. Values are already consumption per hour (not meter readings), in kWh (energy), L (water) or kg (waste); never add different carriers together. null means no data for the bucket, not zero. Omit buildingIds for every building with EOS data. day, week and month buckets need from and to at Oslo midnight; hour buckets up to 62 days, others up to 1100 days, and buildings × carriers × buckets up to 50000.