1.
...
Inhaltsverzeichnis
Table of Contents | ||||
---|---|---|---|---|
|
...
2.
...
Allgemein
2.1
...
Geräte
Die Darstellung der Geräte wird durch ihre eindeutigen Seriennummern identifiziert. Diese Datenobjekte enthalten eine Untergruppe von Informationen sowie eine Liste von SensorIds für Datensenken, die Messdaten enthalten. Mit dem angegebenen API-Schlüssel werden der Benutzer und die verknüpften Geräte identifiziert.
2.2
...
Sensors represent a data sink holding the data of a run. Each sensor has a start and end date. Its sensor id is unique and links to measurements, geolocation and occurrence data.
...
Sensoren
Sensoren stellen eine Datensenke dar, in der die Daten eines Laufs gespeichert werden. Jeder Sensor hat ein Start- und Enddatum. Seine Sensor-ID ist eindeutig und verknüpft mit Messungen, Geolocation und Ereignisdaten.
Sobald das Gerät neu gestartet wird, wird eine neue Sensordatensenke mit einer neuen ID erstellt.
2.3
...
Wortlaut
...
Physical device
A physical device is identified by a serial number and has 1 to n channels.
Each channel can be configured independently (e.g. own measurement interval) and has one or more sensors, which can provide 1 to m different sensor values.
For example;
...
one value: temperature (for a Temperature-Sensor)
...
two-tuples of: relative humidity and temperature (for a rH-sensor)
...
Physikalisches Gerät
Ein physisches Gerät wird durch eine Seriennummer identifiziert und hat 1 bis n Kanäle.
Jeder Kanal kann unabhängig konfiguriert werden (z.B. eigenes Messintervall) und hat einen oder mehrere Sensoren, die 1 bis m verschiedene Sensorwerte liefern können.
Zum Beispiel;
ein Wert: Temperatur (für einen Temperatursensor)
zwei Tupel von: relative Feuchte und Temperatur (für einen rH-Sensor)
Drei-Tupel von: status, #changes, relative on (for a für einen DI-sensorSensor)
Virtual representation with alarming
In elproCLOUD we have a one to one mapping of device and channel.
For the values of a sensor we have an one to n mapping to virtual sensors.
A virtual sensor is created for every configuration of a real sensor and is used to attach different type of alarms to the same sensor valueVirtuelle Darstellung mit Alarmierung
In elproCLOUD haben wir eine Eins-zu-Eins-Zuordnung von Gerät und Kanal.
Für die Werte eines Sensors haben wir eine eins-zu-n-Zuordnung zu virtuellen Sensoren.
Ein virtueller Sensor wird für jede Konfiguration eines realen Sensors erstellt und dient dazu, verschiedene Arten von Alarmen mit demselben Sensorwert zu verbinden.
2.4
...
Note that any JSON accepted and returned by the API must follow the JSON standard as defined in the ECMA-404 standard with the following amendments.
...
JSON property names are case invariant and no guarantee can be made regarding the casing of names, which are returned by the API. This means that no difference is made between uppercase and lowercase letters in property names.
...
Datenformat
Beachten Sie, dass jedes JSON, das von der API akzeptiert und zurückgegeben wird, dem JSON-Standard entsprechen muss, wie er in der ECMA-404 Standard mit den folgenden Änderungen.
JSON-Eigenschaftsnamen sind case invariant und es kann keine Garantie für die Groß- und Kleinschreibung von Namen gegeben werden, die von der API zurückgegeben werden. Das bedeutet, dass kein Unterschied zwischen Groß- und Kleinbuchstaben in Eigenschaftsnamen gemacht wird.
Die relative Reihenfolge der JSON-Namen in Antworten kann nicht garantiert werden. Das bedeutet, dass Sie sich beim Parsen und Verarbeiten von Antworten nicht auf die Reihenfolge der Eigenschaften in den Antworten verlassen sollten.
...
3. REST-API
...
The client can request information from elproCLOUD via Der Client kann über die REST-API . The communication runs typically in the following sequence:
The device will send its data and occurences in defined fix inteval to the elproCLOUD.
There are mechanisms, where the device will send its data directly to the elproCLOUD and will not wait for the next communication interval.
The customer app requests the data from elproCLOUD via the REST-API on demand or in a self defined intervall. This interval should be defined based on a risk-assesment.
Info |
---|
Please be aware that some query results are limited |
Specification:
...
Informationen von elproCLOUD anfordern. Die Kommunikation läuft typischerweise in der folgenden Reihenfolge ab:
Das Gerät sendet seine Daten und Vorkommnisse in einem festgelegten Zeitintervall an die elproCLOUD.
Es gibt Mechanismen, bei denen das Gerät seine Daten direkt an die elproCLOUD sendet und nicht auf das nächste Kommunikationsintervall wartet.
Die Kunden-App fordert die Daten von elproCLOUD über die REST-API bei Bedarf oder in einem selbst definierten Intervall an. Dieses Intervall sollte auf der Grundlage einer Risikoeinschätzung festgelegt werden.
Info |
---|
Bitte beachten Sie, dass einige Abfrageergebnisse limitiert sind |
Spezifikation:
Der Endpunkt REST API URL https://apibridge.elpro.cloud
The API token is provided by ELPRO
Das API-Token wird von ELPRO bereitgestellt
Für Entwickler ist die technische Spezifikation von OpenAPI als Swagger UI verfügbar https://apibridge.elpro.cloud/swagger
3.1
...
The client can request different data sets, including
...
Measurements
...
Geodata
...
Occurences
...
Datensätze und allgemeines Abfrageschema
Der Kunde kann verschiedene Datensätze anfordern, darunter
Messwerte
Geodaten
Occurences
Abweichungen
3.1.1
...
Initially, ELPRO sets up an API key for a dedicated user of an organization.
...
Art des Sicherheitssystems
Zunächst richtet ELPRO einen API-Schlüssel für einen bestimmten Benutzer einer Organisation ein.
Geben Sie Ihren API-Autorisierungscode im Anfrage-Header als Schlüssel und Wert an:
EAPI-ELCLV2 | 123a45b67_SAMPLE_ |
...
f12345ab6c789d0 |
Im Falle eines Fehlens oder einer Nichtübereinstimmung wird eine Fehlermeldung mit dem HTTP-Status 401 "Unauthorized" zurückgegeben.
3.1.2
...
Benutzerumfang
Die abgerufenen Daten fallen in den Bereich der Organisation des authentifizierten API-Benutzers. Sie werden mit dem HTTP-Statuscode 200 (Success) zurückgegeben.
3.1.3 Http
...
-Fehler-Codes
400 Bad |
request |
z. |
B. fehlender obligatorischer Parameter |
401 Unauthorized |
Ungültiger oder fehlender API-Schlüssel |
404 Resource not found |
Ungültige Seriennummer oder ID | |
406 Not Acceptable | Accept Header |
sollte nur application/json lauten |
410 License exhausted |
Anzahl der verbrauchten Abfragen oder Datentransfers |
500 Server Error |
Unerwartete interne Ausnahme |
503 Service Temporarily Unavailable |
Service down due to maintenance or update
3.2 Version of the REST-API
For the REST-API a versioning mechanism is implemented.
The versioning includes a Major and a Minor number.
Major numbers will provide an interface to the elproCLOUD and will be increased, if the functionality of the interface is dramatically changed. Minor numbers will be increased, if information is added to the returned data structure.
...
Dienst aufgrund von Wartung oder Update nicht verfügbar |
3.2 Konfigurations-API
Die REST-Schnittstelle bietet einen sehr einfachen Endpunkt für die Konfiguration von LIBERO Gx-Geräten.
Konfigurationsvorlage erstellen und hochladen
Verwenden Sie den Wizard in elproCLOUD, um eine Konfigurationsvorlage für einen LIBERO Gx zu erstellen
Wählen Sie den richtigen LIBERO Gx-Typ (die ersten drei Ziffern der Seriennummer sind wichtig)
Füllen Sie die Formulare des Wizard aus, bis Sie die Übersichtsseite erreicht haben
Alt+Klick auf die Schaltfläche "Sensor kaufen und starten".
Ein Dateidownload wird angezeigt
Speichern Sie die Datei unter einem passenden Namen (z.B. LIBERO_GH_longlive_freezer.json)
Verwenden Sie den Endpunkt POST /api/v1/Templates, um den Inhalt der gespeicherten Konfigurations-JSON-Datei hochzuladen
Wichtig: Die Konfiguration muss JSON-escaped sein. Tun Sie dies programmatisch oder verwenden Sie ein Online-Tool
Das Anfrageobjekt wird in der Swagger UI beschrieben
Optional: Verwenden Sie den Endpunkt GET /api/v1/Templates, um alle verfügbaren Vorlagen aufzulisten
Konfigurieren Sie die Vorlagen
Verwenden Sie den Endpunkt PUT /api/v1/Device/{deviceSerialNumber} zur Konfiguration der Geräte
Ein Aufruf pro Gerät, verwenden Sie ein Skript, um diesen Prozess zu automatisieren
Drei mögliche Nutzdaten, die durch $type angegeben werden
Weitere Informationen zu den spezifischen Objekten finden Sie in der Swagger UI
DeviceConfigurationRequestByTemplateId und DeviceConfigurationRequestByTemplateName können zur Konfiguration eines Geräts verwendet werden
Optional: Bereitstellung von Metadaten, siehe Swagger UI für weitere Informationen zu Platzhaltern
DeviceConfigurationRequestClearPending kann verwendet werden, um eine ausstehende Konfiguration für Geräte zu löschen, die noch nicht mit der Organisation gepaart worden sind
3.3 Version der REST-API
Für die REST-API ist ein Versionierungsmechanismus implementiert.
Die Versionierung umfasst eine Major- und eine Minor-Nummer.
Major-Nummern stellen eine Schnittstelle zur elproCLOUD zur Verfügung und werden erhöht, wenn die Funktionalität der Schnittstelle signifikant verändert wird. Minor-Nummern werden erhöht, wenn der zurückgegebenen Datenstruktur Informationen hinzugefügt werden.
Die wichtigsten REST-API-Versionen werden weiterhin über die URL verfügbar sein.
elprocloud_request_url/api/v1/… ... (for für v1 of the der REST-API)
elprocloud_request_url/api/v2/… ... (for für v2 of the der REST-API)
Major Major.Minor Versioning will be included in the returned JSON responseVersionierung wird in der zurückgegebenen JSON-Antwort enthalten sein.
Code Block | ||
---|---|---|
| ||
{ "version": "<Major.Minor>", } |
...
4.
...
Nachrichten Queue (AMQP)
...
A “Customer-Queue” is provided using AMQ protocol which is reachable under Es wird eine "Kunden-Queue" mit dem AMQ-Protokoll bereitgestellt, die erreichbar ist unter amqp.elpro.cloud.
The Der Queue-Name is the name of the explicitly provisioned RabbitMQ Queue. Queue and Users are managed by ELPRO.
Furthermore a unique username and password for every customer is provided. See below in this document for an example implementation.
Every customer can use his AMQP client of choice to read and acknowledge on the list of message types.
The connection is TLS only (Port 443)
In Production the Time to live (TTL) of queue data is set to three days.
4.1 Message Models
The Queue Messages will have following basic payload as JSON:
...
Fieldname
...
Type
...
Description
...
type
...
String
...
Name ist der Name der explizit bereitgestellten RabbitMQ-Queueu. Queueu und Benutzer werden von ELPRO verwaltet.
Außerdem eine einzigartige Benutzername und Passwort für jeden Kunden zur Verfügung gestellt wird. Siehe unten in diesem Dokument für eine Beispiel-Implementierung.
Jeder Kunde kann einen AMQP-Client seiner Wahl zum Lesen (read) und Bestätigen (acknowledge) gemäss der Liste der Nachrichtentypen nutzen.
Die Verbindung ist TLS (Port 443)
Auf der Produktivumgebung ist die Time To Live (TTL) der Warteschlangendaten auf drei Tage festgelegt.
4.1 Nachrichtenmodelle
Die Warteschlangen-Nachrichten haben folgende grundlegende Nutzdaten im JSON-Format:
Feldname | Typ | Beschreibung |
type | String | Mögliche Nachrichtentypen:
|
|
| |
data | JSON |
-Object |
Innere JSON-Darstellung einer Info-Nachricht, siehe Info-Datenmodelle weiter unten in diesem Dokument |
4.2
...
Nachrichtentyp
Jeder Typ repräsentiert eine spezielle JSON-Nutzlast innerhalb des Data JSON-Objekts. So weiß ein Verbraucher, welches Datenmodell verwendet wird.
eapi_measurement_new
eapi_geodata_new
eapi_occurrenceEreignis_newneu
eapi_deviation_enter
eapi_deviation_leave
4.3
...
Datenmodelle
Die Daten-Nutzdaten sind für jeden Typ unterschiedlich.
4.3.1
...
Messwerte
Feldname |
Typ |
Beschreibung | ||
sensorId | Int64 | Id |
für die Sensordaten, die eine Datensenke darstellen. | |
deviceId | String |
Kennung des Geräts | |
value | Decimal |
Numeric value of the measure
Numerischer Wert der Maßnahme | ||
timeStamp | DateTimeOffset | DateTime |
der Messung als Zeitzone utc | ||
error | String | Fehlermeldung des jeweiligen Sensors |
status | Decimal | Status des jeweiligen Sensors |
unit | String |
Einheit Token |
Mögliche Werte: K,°C,°F, % | |
unitType | String |
Typ der Einheit als Text: |
|
| ||
tiltAngle | Decimal | Numerischer Wert des Neigungswinkels vom Gerät |
4.3.1.1
...
Beispiel-Messungen
Daten mit Typ: "eapi_measurement_new”new"
Code Block | ||
---|---|---|
| ||
{ "type": "eapi_measurement_new", "data": { "sensorId": "5368" "deviceId": "951FF00000340", "timeStamp": "2022-10-11T16:21:27+00:00", "value": 24.6 "error": "Short Circuit", "status": 0, "unit": "°C", "unitType": “temperature", "deviceId "value": "951FF00000340", "sensorId": "5368" 24.6, "tiltAngle": 2.4, } } |
4.3.2
...
GeoDaten
Feldname |
Typ |
Beschreibung | |
sensorId | Int64 |
ID für die Sensordaten, die eine Datensenke darstellen. | |
deviceId | String |
Kennung des Geräts | |
latitude | Double |
Breitengrad mit 8 Ziffern Genauigkeit | |
longitude | Double |
Längengrad mit 8 Ziffern Genauigkeit | ||
timestamp | DateTimeOffset | datetime in |
der Zeitzone UTC | |
accuracy | Decimal |
Genauigkeit in |
Metern |
4.3.2.1
...
Beispiel GeoDaten
Daten mit Typ: "eapi_geodata_new” new"
Code Block |
---|
{ "type": "eapi_geodata_new", "data": { "timeStamp": "2022-10-11T15:21:24+00:00", "latitude": 47.19999075, "longitude": 9.50875282, "accuracy": 2316, "deviceId": "951FF00000340", "sensorId": "5369" } } |
4.3.3
...
Occurence
Feldname |
Typ |
Beschreibung | |
sensorId | Int64 |
ID für die Sensordaten, die eine Datensenke darstellen. | |
deviceId | String |
Identifikation des Geräts | |
timeStamp | DateTime |
Datumund Zeitpunkt des Auftretens als Zeitzone UTC | ||
typeName | String | "LoggerStatusChange" |
previousState | String |
Mögliche Werte: "Undefined", "Init", "Shelflife", "Pairing", "Start", "LogDelayed", "LogTransit", LogPaused", "LogArrived", "StopStopped", "StopSleep", "Calibration", "EmergencyReadOut", "FatalError", "ProductionCalibration" | |
newState | String |
4.3.3.1
...
Beispiel Occurence
Data with type “eapiDaten mit dem Typ "eapi_occurrence_new” new"
Code Block | ||
---|---|---|
| ||
{ "type": "eapi_occurrence_new", "data": { "timeStamp": "2022-10-11T15:21:24+00:00", "typeName": "LoggerStatusChange", "previousState": "Start", "newState": "LogDelayed", "deviceId": "951FF00000340", "sensorId": "5369" } } |
4.3.4
...
Abweichung
Feldname |
Typ |
Beschreibung | ||
sensorId | Int64 | Id |
für die Sensordaten, die eine Datensenke darstellen. | |
deviceId | String |
Kennung des Geräts | ||
timestamp | DateTimeOffset | DateTime |
der Abweichung als Zeitzone utc | |
historyType | String |
Type of Deviation describring begin or end of deviation.
Possible values:
“enter”“leave”
Typ der Abweichung beschreibt den Beginn oder das Ende der Abweichung. Mögliche Werte: "enter" | |
deviationType | String |
Abweichungstyp, mögliche Werte: "battery", | |
reason | String |
Abweichung Erklärung Code | |
limitzone | String (opt.) |
Limit Zone code for a limit deviation
Grenzwert Zonencode für eine Grenzwertabweichung Mögliche Werte: L1,L2,L3, H1,H2, |
H3... |
4.3.4.1
...
Beispiel Abweichung aufgetreten
Daten mit dem Typ "eapi_deviation_enter” enter"
Code Block |
---|
{ "type": "eapi_deviation_enter", "data": { "deviceId": "951FF00000340", "sensorId": 5763, "timeStamp": "2022-10-26T17:00:22+00:00", "historyType": "enter", "deviationType": "limit", "reason": "upper_limit_alarm" } } |
4.3.4.
...
2 Beispiel Abweichung verlassen
Daten mit dem Typ "eapi_deviation_leave”leave"
Code Block | language | json
---|
{ "type": "eapi_deviation_leave", "data": { "deviceId": "951FF00000340", "sensorId": 5763, "timeStamp": "2022-10-26T18:00:22+00:00", "historyType": "leave", "deviationType": "limit", "reason": "upper_limit_alarm" } } |
4.4
...
AMQP
...
-Nachrichten verwenden
4.4.1
...
Beispiel-Client-Code
...
mit RabbitMQ in C#
Example Code how to connect to a Queue with .NET and RabbitMQ nuget library Beispielcode für die Verbindung zu einer Warteschlange mit .NET und der Nuget-Bibliothek RabbitMQ:
Code Block |
---|
public ObservableCollection<MessageModel> Messages { get; private set; } public static IConnection connection; public static IModel channel; public static EventingBasicConsumer consumer; public void Read() { var serverName = "amqp.elpro.cloud" var queueName = "398ab9ae90efce88dcf623cc49e302e1"; bool autoACK = true; try { // Prepare var factory = new ConnectionFactory() { HostName = serverName, UserName = "user", Password = "password", Port = 443, Ssl = new SslOption() { Enabled = true, ServerName = serverName } }; connection = factory.CreateConnection(); channel = connection.CreateModel(); var routingKey = $"*.eapi_*"; //*.eapi_measurement_new e.g. Console.WriteLine(" [*] Waiting for msgs."); // Consumer consumer = new EventingBasicConsumer(channel); consumer.Received += (model, ea) => { var body = ea.Body.ToArray(); var messageText = Encoding.UTF8.GetString(body); var message = new MessageModel(ea.RoutingKey, messageText); Dispatcher.Dispatch(() => Messages.Add(message)); }; // Subscribe channel.BasicConsume(queue: queueName, autoAck: autoACK, consumer: consumer); } catch (Exception ex) { Console.WriteLine($"Error at RabbitMQ.Test: {ex.Message}"); } } |
...
5.
...
Verbindungsdetails und technische Spezifikation
Endpunkt REST API URL https://apibridge.elpro.cloud
AMQP-Server: amqp.elpro.cloud
For Developers the OpenAPI technical specification as Für Entwickler die technische Spezifikation von OpenAPI als Swagger UI https://apibridge.elpro.cloud/swagger
...