RS-485周辺機器を統合

ユースケース

このパターンは、RS-485に対応したWLTEデバイスが周辺機器と生バイトをやり取りする必要がある場合に使います。OpenAPIはデータの透過送信（パススルー）を提供しますが、完全なModbusプロトコルスタックを自動的に実装するわけではありません。

アプリケーションプロトコルのペイロード構築、必要に応じたCRC、レスポンスの解釈、デバイス固有のリトライルールの適用は、あなたのサービス側の責任です。

デバイス一覧の取得（英語）から対象デバイスの deviceType を読み取ります。
デバイスタイプ定義一覧の取得（英語）で対応するプロファイルを探します。
supportedOperations に device.rs485.transceive が含まれている場合のみパススルーを公開します。
ボーレート設定が必要な場合は、別途 device.rs485.baudRate.set を要求し、現在の値をデバイス設定の取得（英語）から読み取ります。
新しい Idempotency-Key とともに生のリクエストを送信し、返されたコマンドIDを保持します。
SUCCESS の後にのみ command.result.responseHex を解析します。ステータスが SENT の場合は、コマンド結果を照会します。

デバイス名や他の機種からRS-485対応を推測しないでください。supportedOperations を使ってください。ボーレートの変更には device:config、パススルーには device:control が必要です。

ボーレートエンドポイントは、RS485ボーレートの設定（英語）に記載されている範囲と単位を受け付けます。周辺機器とデバイスは同じ値を使う必要があります。

RESTでは、requestHex をRS485透過送信コマンド（英語）に送信します。現在の契約では、スペース、0x プレフィックス、区切り文字を含まない、1〜30バイトの連続した16進数文字列を受け付けます。

周辺機器がModbus RTUを使用する場合、アドレス、ファンクション、データ、CRCバイトはあなたのアプリケーションが構築する必要があります。OpenAPIはバイトを転送し、生のレスポンスバイトを返しますが、Modbusのレジスタやファンクションのセマンティクスを検証するわけではありません。

WebSocketを使用する場合、一致したデータは操作の返信に含まれます。遅延した、または要求していないRS-485データは、履歴の再生がないdevice.rs485.received（英語）経由で届く場合があります。

元の冪等性キーを再利用するのは、不明なHTTP結果やレート制限の後に、同一の透過送信リクエストを再試行する場合のみにしてください。
TIMEOUT は元のコマンドにとって不確実な最終結果として扱ってください。そのキーを再利用してもデータは再送されません。周辺機器へのコマンドとして別の物理的な試行が安全な場合にのみ、新しいキーを生成してください。
データを適用する前に、自分のパーサーでレスポンス長、プロトコルのチェックサム、アドレス、ファンクションを検証してください。
失うことが許容できない場合は、要求していない、または遅延したデータを速やかに永続化してください。WebSocketイベントは再送されません。
同じデバイスに対して並行して透過送信リクエストを発行するのではなく、デバイス操作単位のレート制限を守ってください。

物理的なRS-485バスまたはデバイスごとに、1つの調整されたリクエストキューを維持してください。
生のバスデータに機密の値が含まれる可能性がある場合は、ペイロードをマスキングしてください。
コマンドID、冪等性キー、リクエストとレスポンスの長さ、最終ステータス、requestId を記録してください。認証情報やアクセストークンはログに残さないでください。
自動リトライを有効にする前に、実際の周辺機器でタイムアウトと重複レスポンスの挙動をテストしてください。