Skip to content

RS-485-Peripherie integrieren

Anwendungsfall

Verwenden Sie dieses Muster, wenn ein RS-485-fähiges WLTE-Gerät rohe Bytes mit Peripherie austauschen muss. OpenAPI stellt einen transparenten Durchlauf (Passthrough) bereit; es implementiert nicht automatisch einen vollständigen Modbus-Protokollstapel.

Ihr Dienst ist dafür verantwortlich, die Anwendungsprotokoll-Nutzlast, bei Bedarf die CRC, zu erstellen, die Antwort zu interpretieren und geräteseitige Wiederholungsregeln anzuwenden.

Empfohlener Ablauf

  1. Lesen Sie den deviceType des Zielgeräts aus Geräte auflisten (auf Englisch).
  2. Finden Sie das entsprechende Profil in Gerätetypdefinitionen auflisten (auf Englisch).
  3. Bieten Sie den transparenten Durchlauf nur an, wenn supportedOperations device.rs485.transceive enthält.
  4. Wenn eine Baudratenkonfiguration erforderlich ist, verlangen Sie separat device.rs485.baudRate.set und lesen Sie den aktuellen Wert aus Gerätekonfiguration abrufen (auf Englisch).
  5. Senden Sie die rohe Anfrage mit einem neuen Idempotency-Key und speichern Sie die zurückgegebene Befehls-ID.
  6. Analysieren Sie command.result.responseHex erst nach SUCCESS. Wenn der Status SENT ist, fragen Sie das Befehlsergebnis ab.

Schrittweise Umsetzung

1. Fähigkeiten und Konfiguration prüfen

Leiten Sie die RS-485-Unterstützung nicht aus dem Gerätenamen oder einem anderen Modell ab. Verwenden Sie supportedOperations. Baudratenänderungen erfordern device:config; der transparente Durchlauf erfordert device:control.

Der Baudraten-Endpunkt akzeptiert den Bereich und die Einheiten, die in RS485-Baudrate festlegen (auf Englisch) dokumentiert sind. Peripherie und Gerät müssen denselben Wert verwenden.

2. Rohe Anfrage erstellen

Senden Sie über REST requestHex an RS485-Übertragungsbefehl (auf Englisch). Der aktuelle Vertrag akzeptiert eine zusammenhängende Hex-Zeichenkette von 1 bis 30 Bytes, ohne Leerzeichen, 0x-Präfix oder Trennzeichen.

Wenn die Peripherie Modbus RTU verwendet, muss Ihre Anwendung Adresse, Funktion, Daten und CRC-Bytes erstellen. OpenAPI leitet die Bytes weiter und gibt rohe Antwort-Bytes zurück; es validiert keine Modbus-Register oder Funktionssemantik.

3. Befehlsergebnis behandeln

  • SUCCESS: Analysieren Sie result.responseHex gemäß dem Peripherieprotokoll.
  • SENT: Fragen Sie über Befehlsergebnis abrufen (auf Englisch) ab.
  • FAILED: Anhalten und den bestätigten Fehler anzeigen.
  • TIMEOUT: Innerhalb des Zeitfensters ist keine entsprechende Antwort eingetroffen. Nehmen Sie nicht an, dass der Schreibvorgang auf der Peripherie fehlgeschlagen ist.

Bei Verwendung von WebSocket erscheinen die entsprechenden Daten in der Vorgangsantwort. Verspätete oder unangeforderte RS-485-Daten können über device.rs485.received (auf Englisch) eintreffen, das keine Verlaufswiedergabe hat.

Wichtige Schnittstellen und Ereignisse

ZweckReferenz
Gerätefähigkeiten bestätigenGerätetypdefinitionen auflisten (auf Englisch)
Rohe Daten über REST sendenRS485-Übertragungsbefehl (auf Englisch)
Rohe Daten über WebSocket sendenRS485-Übertragung (auf Englisch)
Baudrate konfigurierenRS485-Baudrate festlegen (auf Englisch)
Aktuelle Konfiguration lesenGerätekonfiguration abrufen (auf Englisch)
Unangeforderte Daten empfangenRS485-Datenereignis (auf Englisch)

Fehler und Wiederherstellung

  • Verwenden Sie den ursprünglichen Idempotenzschlüssel nur wieder, wenn Sie dieselbe Übertragungsanfrage nach einem unbekannten HTTP-Ergebnis oder einer Ratenbegrenzung wiederholen.
  • Behandeln Sie TIMEOUT als unklares Endergebnis für den ursprünglichen Befehl; die Wiederverwendung seines Schlüssels sendet die Daten nicht erneut. Generieren Sie nur dann einen neuen Schlüssel, wenn ein weiterer physischer Versuch für den Peripheriebefehl sicher ist.
  • Prüfen Sie in Ihrem eigenen Parser Antwortlänge, Protokollprüfsumme, Adresse und Funktion, bevor Sie Daten anwenden.
  • Speichern Sie unangeforderte oder verspätete Daten sofort dauerhaft, wenn ihr Verlust nicht akzeptabel ist; WebSocket-Ereignisse werden nicht erneut zugestellt.
  • Beachten Sie Ratenbegrenzungen auf Ebene des Gerätevorgangs, statt parallele Übertragungsanfragen an dasselbe Gerät zu senden.

Überlegungen für die Produktion

  • Führen Sie eine einzige koordinierte Anfragewarteschlange pro physischem RS-485-Bus oder -Gerät.
  • Verbergen Sie sensible Nutzlasten, wenn rohe Busdaten geheime Werte enthalten können.
  • Protokollieren Sie Befehls-ID, Idempotenzschlüssel, Anfrage- und Antwortlängen, Endstatus und requestId; vermeiden Sie das Protokollieren von Zugangsdaten oder Access Token.
  • Testen Sie Timeout-Verhalten und doppelte Antworten an echter Peripherie, bevor Sie automatische Wiederholungsversuche aktivieren.

Nächste Schritte

Docs buildVersion v1.5.8-20260814-180545-84
Copyright © 2026 WLTE