Skip to main content
Allt som en arbetsorder pekar på bor här: platser (dina fysiska anläggningar, grupperade i regioner) och tillgångar (utrustning på en plats, klassificerade efter tillgångstyp, valfritt standardiserade av en tillgångsmodell, och instrumenterade med mätare). Alla exempel förutsätter:

Platser

Platser är mestadels läsbara via API:et:
Anmärkningar:
  • List-slutpunkten begränsar limit till 10 (de flesta list-slutpunkter tillåter 25). Planera pagineringsloopar därefter.
  • multiple/{ids} tar kommaseparerade id:n och utelämnar tyst varje id du saknar läsbehörighet för; kontrollera vilka id:n som kom tillbaka istället för att anta att alla gjorde det.
  • Den enda skrivningen är PATCH /v1/buyer/location/locations/{id}, och den läser endast locationTypeDetails från kroppen (anpassade fältvärden för platsens typ). Alla andra fält ignoreras.
Regioner grupperar platser: GET /v1/buyer/location/regions och GET /v1/buyer/location/regions/{id}.

Tillgångstyper

Tillgångstyper klassificerar utrustning (“Walk-in cooler”, “Rooftop unit”) och bär klassnivåns standardvärden, inklusive köldmedieinställningar.
  • name är det enda obligatoriska fältet. buyerCompanyId härleds från din nyckel och kan inte sättas.
  • applianceCategory, refrigerantTypeCode och fullChargeLb accepterar ett explicit null för att rensa klassnivåns standardvärde. fullChargeLb måste vara positivt när det anges.
  • Att skicka ett id uppdaterar en befintlig typ.
Läs med GET /v1/buyer/asset/asset_types och GET /v1/buyer/asset/asset_types/{id}.

Tillgångar

Skapa en tillgång med POST /v1/buyer/asset/assets. Krävs: name, assetTypeId, locationId, isActive, isLeased.
Beteende att känna till:
  • buyerFacilityId och buyerCompanyId härleds från platsen, aldrig från kroppen.
  • Köldmedieöverstyrningar kan rensas. refrigerantTypeCode, fullChargeLb, applianceCategory och refrigerantRequiresProcessShutdown är per-enhet-överstyrningar av tillgångstypens standardvärden. Att utelämna nyckeln behåller det lagrade värdet; ett explicit null (eller tom sträng) rensar tillbaka till att ärva från typen. isRefrigerantTracked beter sig liknande: utelämnat eller null behåller det lagrade värdet, och inskrivningen stängs endast av med ett explicit false.
  • Underliggande tillgångar. parentId gör detta till en underliggande tillgång. Det kräver att underliggande tillgångar är aktiverade för ditt företag, och barnet måste vara på samma plats som föräldern.
  • Att skicka ett id uppdaterar en befintlig tillgång.
Läsningar:
asset_lite är det billiga sättet att synka en tillgångsväljare: när du inte skickar några pagineringsparametrar returnerar den den opaginerade fulla mängden, med count lika med antalet returnerade poster. Den enskilda tillgångsläsningen hydratiserar mätare (höljets type läser ApiAssetWithMeter).

Tillgångsetiketter

Tillgångsetiketter är lätta taggar som ditt team definierar i OpenWrench-appen (ett namn plus en valfri färg), användbara för att dela upp tillgångslistan på sätt som de inbyggda fälten inte täcker. Via API:et kan du läsa katalogen och ersätta etiketterna som är applicerade på en tillgång. Att skapa eller redigera själva etiketterna sker fortfarande i appen. Bläddra i katalogen med GET /v1/buyer/asset/asset_labels, eller hämta en med GET /v1/buyer/asset/asset_labels/{id}. Listan är avgränsad till ditt företags etiketter och pagineras med 10 per sida som standard. Den accepterar search- och label-filter på etikettexten. Skicka no_pagination=true för att hämta hela katalogen i ett anrop (sorteringen gäller fortfarande).
Ersätt en tillgångs etiketter med PUT /v1/buyer/asset/assets/{assetId}/labels. Kroppen är { "ids": [...] } och det är en fullständig ersättning: etiketter som inte listas tas bort, och en tom array rensar dem alla. Svaret listar de etiketter som nu är aktiva på tillgången.
Beteende att känna till:
  • Ett saknat ids eller ett ids som inte är en array, eller ett id som inte är ett heltal, avvisas med 400.
  • Varje id måste vara en levande etikett från ditt företags katalog. Okända eller tenantöverskridande id:n svarar 400 med de felande id:na listade.
  • Skrivningen kräver skrivbehörighet för tillgångar. Ett okänt, raderat eller främmande tillgångs-id svarar med samma 400 som en nekad skrivning, inte en 404.

Tillgångsmodeller

Modeller standardiserar specifikationer och manualer per typ. POST /v1/buyer/asset/asset_models kräver modelName och assetTypeId, med valfria manuals- och specs-bilagor. Den ungefärliga matchningen är praktisk vid importer, när dina källdata har fritextmodellnamn:
GET /v1/buyer/asset/asset_models/fuzzy/{name}/{assetTypeId} returnerar den närmaste modellen inom tillgångstypen, eller 404 när inget är tillräckligt nära. Fall tillbaka på att skapa modellen vid 404.

Mätare och avläsningar

Mätare fäster en mätbar serie till en tillgång (temperatur, drifttimmar, cykelantal). Skapa mätaren en gång och registrera sedan avläsningar mot den:
Anteckningar:
  • valueType, valueUnit och locationId läses inte från kroppen vid skapande av mätare — de härleds på serversidan från den refererade tillgången och mätartypen, så att skicka dem har ingen effekt.
  • readingMode (omdöpt från seriesType) är antingen direct_reading, change_from_baseline eller compare_to_target; standardvärdet är direct_reading om det utelämnas.
  • Listnings- och räkningsslutpunkterna för avläsningar är inte begränsade till en enda mätare — de omfattar alla avläsningar för hela ditt köparföretag om du inte filtrerar med meterId.
  • När en mätares readingMode är change_from_baseline beräknas en hämtad avläsnings lastBaselineValue från den senaste tidigare avläsningen markerad isBaseline på den mätaren, per recordedAt; för övriga lägen är det null.

Synkroniseringsstrategi

För en nattlig tillgångssynkronisering: paginera asset_lite för id-uppsättningen, jämför mot ditt system och hämta sedan fullständiga poster via id endast för ändrade tillgångar. Det håller dig inom hastighetsgränsen (10 förfrågningar per 20-sekundersfönster) betydligt mer bekvämt än att paginera hela listningen med 25 per anrop.