Översättare

En översättare omvandlar en enhets rådata (eller en tidigare översättares utdata) till IoT-plattformens harmoniserade, kanoniska datamodell. Det här avsnittet är en lättviktig katalog, så att du eller en assistent snabbt kan hitta rätt en via tillverkare, enhetsmodell eller funktion.

Yggio levererar omkring 500 översättare, av två slag:

• Hårdvaruöversättare avkodar en sensors payload. Det finns ungefär 450 av dem, från tillverkare som Milesight, Dragino, Elsys, Adeunis, Decentlab, Watteco och Sensative. Det är dessa som listas i A-Ö-sidorna nedan.
• Logiköversättare är kedjade: de körs ovanpå en hårdvaruöversättares utdata för att beräkna, larma, analysera en trend eller forma om data. Omkring 100 av dem, och de finns inte i A-Ö-sidorna - varje sort har sin egen sida, listad under Kategorier.

Om din sensor inte finns bland dem går det att skriva och ladda upp en översättare utan att vänta på en release.

Hur den här katalogen är strukturerad

A-Ö-sidorna bär en post per hårdvaruöversättare, ordnade efter översättarnamn. Varje post är medvetet kort, och alltid i samma form:

### <translator-name>
**<Official name>** · <Type>
**Manufacturer:** <vendor>
**Models:** <ytterligare modeller / SKU:er>

<sammanfattning på en till tre meningar>

• translator-name - id:t du kopplar till en enhet, och rubriken att söka efter.
• Official name - tillverkarens eget namn på produkten.
• Type - vad det är: sensortyp och överföringssätt för en hårdvaruavkodare, eller logikkategorin för en kedjad översättare.
• Manufacturer - vem som tillverkar hårdvaran, så att katalogen kan bläddras per tillverkare. Där varumärket och tillverkaren skiljer sig ser du båda, som i Seeed (SenseCAP) eller Kerlink (Wanesy). Logiköversättare har ingen tillverkare.
• Models - finns med när en översättare täcker flera modeller eller en hel produktfamilj, och listar dem det officiella namnet inte redan anger.
• Summary - vad enheten mäter, eller vad en logiköversättare beräknar och när den ska användas, i enkla ord: temperatur, CO2, vattenläcka, personräkning.

Logiköversättare beskrivs mer utförligt på sina egna sidor, listade under Kategorier nedan. Deras poster i A-Ö-sidorna pekar dit i stället för att upprepa detaljerna.

Fullständiga detaljer finns i IoT-plattformen

Den här katalogen är ett sammanfattande index, medvetet hållet lätt så att den går snabbt att bläddra i. Den auktoritativa, fullständiga definitionen av varje översättare - de fullständiga avkodade utdatafälten, deras enheter och storheter (den fullständiga datamodellen / spec), versionen, matchningsreglerna och den fullständiga beskrivningen - finns i själva IoT-plattformen: via översättar-API:et (plattformens Swagger) och i enhets-/översättarvyerna. Använd den här sidan för att upptäcka vilken översättare du behöver; använd IoT-plattformen för den exakta, aktuella specifikationen.

För den fältnivåspecifika referensen och reglerna, se Translator API.

Kategorier

Hårdvaruavkodare

Omvandlar en enhets råa uppströmsdata till kanoniska fält. Särskiljs efter överföringssätt:

• LoRaWAN - majoriteten av sensorerna.
• NB-IoT - mobilnätsanslutna sensorer (taggade (NB-IoT)).
• Modbus - kabelanslutna mätare och styrenheter via en gateway (taggade (Modbus)).
• Cloud-to-cloud - enheter vars data anländer via en leverantörs moln, inte som ett rått radiopaket (taggade (Cloud-to-cloud)).
• wM-Bus - trådlösa M-Bus-mätare (taggade (wM-Bus)).
• Kameraanalys - kamera-/ACAP-appar som rapporterar antal eller hastigheter.

Vissa hårdvaruöversättare känner igen hela produktfamiljer/modellserier: en översättare avkodar ett helt produktsortiment (listat på dess Models-rad).

Logik-/kedjade översättare

Dessa körs ovanpå en annan översättare - de läser fält som redan avkodats uppströms (inte rådata) och lägger till härledda värden. De har ingen hårdvarumodell.

• Analytics - övergripande KPI:er och insikter (t.ex. energieffektivitet, förändringstakt, utnyttjandegrad, kvalitet vid ramförlust).
• Calculation - aritmetiska och enhetsomvandlingar, kalibreringar och periodvis aggregering (t.ex. förbrukning per dag/vecka/månad, daggpunkt, enhetsomvandlingar).
• Alarm - utlöser booleska larm utifrån tröskelvärden på ett avkodat fält (t.ex. hög/låg temperatur).
• State/occupancy - härleder ett tillstånd eller en närvaroflagga från avkodade fält.
• Data transfer - vidarebefordrar eller kopierar fält mellan noder.
• Utility - hjälpprogram, exempel, geofence-/timer- och konfigurationsöversättare.

Den kanoniska datamodellen (sammanfattning)

De flesta översättare ger ut samma harmoniserade, NGSI-LD-anpassade platta datamodell, konsoliderad från ~2000 ad hoc-egenskapsnamn till ett gemensamt vokabulär av kanoniska fältnamn. Den konsekvensen är det som gör att ett larm, en dashboard, en rapport eller en nedströms översättare fungerar över vilken enhet som helst.

• Namn - lowerCamelCase, platt, ingen tillverkarjargong: t.ex. temperature, relativeHumidity, batteryVoltage, batteryLevel, co2, location.
• Enheter - SI-symboler, deklarerade per fält: V, A, W, Hz, Pa, m, s, m/s, m^3, kWh, C, %. Antal, enums och flaggor är dimensionslösa ('') med en namngiven quantity.
• Typning - varje fält har {type, unit, quantity}, så att konsumenter vet hur de ska läsa och visa det.
• Temperaturmedium - anges i fältnamnet: temperature (luft/omgivning), waterTemperature, soilTemperature, surfaceTemperature, externalTemperature, internalTemperature.
• Indexerad / flervärdig - en enkel primär och sedan numrerade extra (temperature, temperature2, …), eller symmetriska kanaler numrerade från 1 (pulse1…pulse4).
• Larm - subjekt först med suffixet Alarm, booleskt (temperatureHighAlarm, tamperAlarm, leakageAlarm).
• Status - subjekt först, booleskt/enum (batteryLow, occupied, contact).
• Inga föråldrade alias - endast kanoniska namn (t.ex. relativeHumidity inte humidity, batteryLevel inte battery, location inte lnglat).

Det kanoniska vokabuläret är den enda sanningskällan i yggio-core-constants (src/translator-fields.ts); Translator API dokumenterar den fullständiga fältkatalogen och namnreglerna.

Versioner

En translators versionsnummer säger vad som ändrats, och därmed vad det kan gå sönder. De tre delarna är inte utbytbara.

Ändring	Exempel	Vad det betyder
Patch	1.0.0 till 1.0.1	En buggfix eller säkerhetsuppdatering. Samma fält, samma namn, samma betydelse. Inget nedströms behöver veta något
Minor	1.0.0 till 1.1.0	Ny funktionalitet, möjligen nya fält, men befintliga fält behåller sina namn och sin betydelse. Bakåtkompatibelt
Major	1.0.0 till 2.0.0	Datamodellen har ändrats: fält har bytt namn, bytt typ eller tagits bort. Allt som läser de gamla namnen måste peka om

Bara en major-version kan gå sönder för en konsument, så det är den Yggio frågar om. Ändrar du en version själv visas den nuvarande datamodellen vid sidan av den nya, med de fält som tas bort och läggs till markerade, och den väntar på din bekräftelse - se Select many.

En uppgraderingspolicy avgör hur långt en enhet följer nya versioner på egen hand, från ingen via patch och minor till alla. En policy som tillåter major-uppgraderingar tar dem utan att fråga, och därför bör den bara sättas där resultatet kan verifieras - se Versioner och uppgraderingspolicyer.

Ingenting korsar en major-gräns av sig själv. En enhet stannar på den version den har till någon väljer att flytta den, och ser vad som ändras innan det sker.