Übersetzer

Ein Übersetzer wandelt die Rohdaten eines Geräts (oder die Ausgabe eines vorgeschalteten Übersetzers) in das harmonisierte, kanonische Datenmodell der IoT-Plattform um. Dieser Abschnitt ist ein leichtgewichtiger Katalog, damit Sie oder ein Assistent schnell den richtigen anhand von Hersteller, Gerätemodell oder Funktion finden können.

Yggio liefert rund 500 Übersetzer in zwei Arten:

• Hardware-Übersetzer dekodieren die Payload eines Sensors. Es sind etwa 450, von Herstellern wie Milesight, Dragino, Elsys, Adeunis, Decentlab, Watteco und Sensative. Diese sind in den A-Z-Seiten unten aufgeführt.
• Logik-Übersetzer sind verkettet: sie laufen auf der Ausgabe eines Hardware-Übersetzers, um zu rechnen, Alarme auszulösen, einen Trend zu analysieren oder Daten umzuformen. Rund 100 davon, und sie stehen nicht in den A-Z-Seiten - jede Art hat ihre eigene Seite, aufgeführt unter Kategorien.

Ist Ihr Sensor nicht dabei, lässt sich ein Übersetzer schreiben und hochladen, ohne auf ein Release zu warten.

Wie dieser Katalog aufgebaut ist

Die A-Z-Seiten tragen einen Eintrag je Hardware-Übersetzer, nach Übersetzernamen geordnet. Jeder Eintrag ist bewusst kurz und immer in derselben Form:

### <translator-name>
**<Official name>** · <Type>
**Manufacturer:** <vendor>
**Models:** <weitere Modelle / SKUs>

<Zusammenfassung in ein bis drei Sätzen>

• translator-name - die Id, die Sie einem Gerät zuweisen, und die Überschrift, nach der Sie suchen.
• Official name - der eigene Name des Herstellers für das Produkt.
• Type - was es ist: Sensorart und Übertragungsweg bei einem Hardware-Decoder, oder die Logik-Kategorie bei einem verketteten Übersetzer.
• Manufacturer - wer die Hardware herstellt, damit der Katalog nach Hersteller durchsucht werden kann. Wo Marke und Hersteller sich unterscheiden, sehen Sie beide, wie in Seeed (SenseCAP) oder Kerlink (Wanesy). Logik-Übersetzer haben keinen Hersteller.
• Models - vorhanden, wenn ein Übersetzer mehrere Modelle oder eine ganze Produktfamilie abdeckt, und listet jene, die der offizielle Name nicht schon nennt.
• Summary - was das Gerät misst, oder was ein Logik-Übersetzer berechnet und wann er zu verwenden ist, in einfachen Worten: Temperatur, CO2, Wasserleck, Personenzählung.

Logik-Übersetzer werden ausführlicher auf ihren eigenen Seiten behandelt, aufgeführt unter Kategorien weiter unten. Ihre Einträge in den A-Z-Seiten verweisen dorthin, statt die Details zu wiederholen.

Vollständige Details finden Sie in der IoT-Plattform

Dieser Katalog ist ein zusammenfassender Index, absichtlich schlank gehalten, damit er schnell zu durchsuchen ist. Die maßgebliche, vollständige Definition jedes Übersetzers - die vollständigen dekodierten Ausgabefelder, ihre Einheiten und Größen (das vollständige Datenmodell / spec), die Version, die Match-Regeln und die vollständige Beschreibung - ist in der IoT-Plattform selbst verfügbar: über die Translator-API (das Swagger der Plattform) und in den Geräte-/Übersetzer-Ansichten. Nutzen Sie diese Seite, um herauszufinden, welchen Übersetzer Sie brauchen; nutzen Sie die IoT-Plattform für die exakte, aktuelle Spezifikation.

Die feldgenaue Referenz und die Regeln finden Sie in der Translator API.

Kategorien

Hardware-Decoder

Wandeln den Roh-Uplink eines Geräts in kanonische Felder um. Unterschieden nach Übertragungsweg:

• LoRaWAN - die Mehrheit der Sensoren.
• NB-IoT - Mobilfunk-Sensoren (markiert mit (NB-IoT)).
• Modbus - verdrahtete Zähler und Controller über ein Gateway (markiert mit (Modbus)).
• Cloud-to-Cloud - Geräte, deren Daten über eine Hersteller-Cloud eintreffen, nicht als rohes Funk-Payload (markiert mit (Cloud-to-cloud)).
• wM-Bus - Wireless-M-Bus-Zähler (markiert mit (wM-Bus)).
• Kamera-Analytics - Kamera-/ACAP-Apps, die Zählungen oder Geschwindigkeiten melden.

Manche Hardware-Übersetzer erkennen ganze Produktfamilien/Modellreihen: ein Übersetzer dekodiert eine ganze Produktpalette (in seiner Models-Zeile aufgeführt).

Logik-/verkettete Übersetzer

Diese laufen auf einem anderen Übersetzer auf - sie lesen bereits vorgelagert dekodierte Felder (keine Rohdaten) und fügen abgeleitete Werte hinzu. Sie haben kein Hardware-Modell.

• Analytics - übergeordnete KPIs und Erkenntnisse (z. B. Energieeffizienz, Änderungsrate, Auslastung, Qualität bei Frame-Verlust).
• Calculation - arithmetische und Einheiten-Umrechnungen, Kalibrierungen und periodenweise Aggregation (z. B. Verbrauch pro Tag/Woche/Monat, Taupunkt, Einheitenumrechnungen).
• Alarm - löst boolesche Alarme anhand von Schwellenwerten auf einem dekodierten Feld aus (z. B. Temperatur zu hoch/niedrig).
• State/Occupancy - leitet einen Zustand oder ein Belegungs-Flag aus dekodierten Feldern ab.
• Data Transfer - leitet Felder zwischen Nodes weiter oder kopiert sie.
• Utility - Hilfsprogramme, Beispiele, Geofence-/Timer- und Konfigurations-Übersetzer.

Das kanonische Datenmodell (Zusammenfassung)

Die meisten Übersetzer geben dasselbe harmonisierte, NGSI-LD-orientierte flache Datenmodell aus, konsolidiert aus ~2000 Ad-hoc-Eigenschaftsnamen zu einem gemeinsamen Vokabular kanonischer Feldnamen. Diese Konsistenz ermöglicht es, dass ein Alarm, ein Dashboard, ein Report oder ein nachgelagerter Übersetzer über jedes Gerät hinweg funktioniert.

• Namen - lowerCamelCase, flach, kein Hersteller-Jargon: z. B. temperature, relativeHumidity, batteryVoltage, batteryLevel, co2, location.
• Einheiten - SI-Symbole, pro Feld deklariert: V, A, W, Hz, Pa, m, s, m/s, m^3, kWh, C, %. Zählungen, Enums und Flags sind dimensionslos ('') mit einer benannten quantity.
• Typisierung - jedes Feld trägt {type, unit, quantity}, damit Konsumenten wissen, wie sie es lesen und anzeigen sollen.
• Temperatur-Medium - im Feldnamen enthalten: temperature (Luft/Umgebung), waterTemperature, soilTemperature, surfaceTemperature, externalTemperature, internalTemperature.
• Indiziert / mehrwertig - ein nackter Primärwert, dann nummerierte Zusatzwerte (temperature, temperature2, …), oder symmetrische Kanäle ab 1 nummeriert (pulse1…pulse4).
• Alarme - Subjekt zuerst mit Alarm-Suffix, boolesch (temperatureHighAlarm, tamperAlarm, leakageAlarm).
• Status - Subjekt zuerst, boolesch/Enum (batteryLow, occupied, contact).
• Keine veralteten Aliase - nur kanonische Namen (z. B. relativeHumidity statt humidity, batteryLevel statt battery, location statt lnglat).

Das kanonische Vokabular ist die einzige verbindliche Quelle in yggio-core-constants (src/translator-fields.ts); die Translator API dokumentiert den vollständigen Feldkatalog und die Namensregeln.

Versionen

Die Versionsnummer eines Translators sagt, was sich geändert hat, und damit, was kaputtgehen kann. Die drei Teile sind nicht austauschbar.

Änderung	Beispiel	Was sie bedeutet
Patch	1.0.0 auf 1.0.1	Eine Fehlerbehebung oder ein Sicherheitsupdate. Gleiche Felder, gleiche Namen, gleiche Bedeutung. Nichts nachgelagert muss davon wissen
Minor	1.0.0 auf 1.1.0	Neue Funktionalität, möglicherweise neue Felder, aber die bestehenden Felder behalten Namen und Bedeutung. Rückwärtskompatibel
Major	1.0.0 auf 2.0.0	Das Datenmodell hat sich geändert: Felder wurden umbenannt, umtypisiert oder entfernt. Alles, was die alten Namen liest, muss umgestellt werden

Nur eine Major-Version kann einen Konsumenten brechen, also ist es die, bei der Yggio nachfragt. Ändern Sie eine Version selbst, wird das aktuelle Datenmodell neben dem neuen gezeigt, mit den entfernten und hinzugefügten Feldern markiert, und auf Ihre Bestätigung gewartet - siehe Select Many.

Eine Upgrade-Richtlinie bestimmt, wie weit ein Gerät neuen Versionen von selbst folgt, von keiner über Patch und Minor bis alle. Eine Richtlinie, die Major-Upgrades erlaubt, nimmt sie ohne Rückfrage, weshalb sie nur dort gesetzt werden sollte, wo das Ergebnis überprüfbar ist - siehe Versionen und Upgrade-Richtlinien.

Eine Major-Grenze wird nie von selbst überschritten. Ein Gerät bleibt auf der Version, die es hat, bis jemand es bewusst umstellt - und sieht vorher, was sich ändert.