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
- Lesen Sie den
deviceTypedes Zielgeräts aus Geräte auflisten (auf Englisch). - Finden Sie das entsprechende Profil in Gerätetypdefinitionen auflisten (auf Englisch).
- Bieten Sie den transparenten Durchlauf nur an, wenn
supportedOperationsdevice.rs485.transceiveenthält. - Wenn eine Baudratenkonfiguration erforderlich ist, verlangen Sie separat
device.rs485.baudRate.setund lesen Sie den aktuellen Wert aus Gerätekonfiguration abrufen (auf Englisch). - Senden Sie die rohe Anfrage mit einem neuen
Idempotency-Keyund speichern Sie die zurückgegebene Befehls-ID. - Analysieren Sie
command.result.responseHexerst nachSUCCESS. Wenn der StatusSENTist, 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 Sieresult.responseHexgemäß 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
| Zweck | Referenz |
|---|---|
| Gerätefähigkeiten bestätigen | Gerätetypdefinitionen auflisten (auf Englisch) |
| Rohe Daten über REST senden | RS485-Übertragungsbefehl (auf Englisch) |
| Rohe Daten über WebSocket senden | RS485-Übertragung (auf Englisch) |
| Baudrate konfigurieren | RS485-Baudrate festlegen (auf Englisch) |
| Aktuelle Konfiguration lesen | Gerätekonfiguration abrufen (auf Englisch) |
| Unangeforderte Daten empfangen | RS485-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
TIMEOUTals 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
- Ratenbegrenzungen und Wiederholungsversuche (auf Englisch)
- Befehlsergebnis abrufen (auf Englisch)
- RS485-Datenereignis über WebSocket (auf Englisch)
