MQTT プロトコルを使用した DPS との通信
Azure IoT デバイス プロビジョニング サービス (DPS) により、デバイスは、以下を使用して DPS デバイス エンドポイントと通信できます。
- ポート 8883 上の MQTT v3.1.1
- ポート 443 で WebSocket を介して MQTT v3.1.1
DPS はフル機能の MQTT ブローカーではないため、MQTT v3.1.1 標準で指定されているすべての動作をサポートしているわけではありません。 この記事では、サポートされている MQTT 動作を使用して、デバイスと DPS の通信を行う方法について説明します。
DPS とのすべてのデバイス通信は、TLS/SSL を使用してセキュリティで保護する必要があります。 そのため、DPS では、ポート 1883 経由のセキュリティで保護されていない接続をサポートしていません。
Note
DPS では現在、MQTT プロトコル経由で TPM 構成証明メカニズムを使用しているデバイスをサポートしていません。
DPS の接続
デバイスでは、MQTT プロトコルを使用し、次のいずれかのオプションを利用して DPS インスタンスに接続できます。
- Azure IoT Provisioning SDK のライブラリ。
- 直接的な MQTT プロトコル。
MQTT プロトコルの直接使用 (デバイスとして)
デバイスでデバイス SDK を使用できない場合でも、MQTT プロトコルをポート 8883 で使用して、デバイスをパブリックのデバイス エンドポイントに接続できます。 CONNECT パケットの場合、デバイスでは次の値を使用する必要があります。
[ClientId] フィールドには、registrationId を使用します。
[Usename] フィールドには、
{idScope}/registrations/{registration_id}/api-version=2019-03-31
を使用します。ここで、{idScope}
は DPS の ID スコープで、{registration_id}
はデバイスの登録 ID です。Note
X.509 証明書認証を使用する場合、登録 ID はデバイス リーフ (エンド エンティティ) 証明書のサブジェクト共通名 (CN) によって提供されます。 [Username] の
{registration_id}
は共通名と一致する必要があります。[Password] フィールドには、SAS トークンを使用します。 SAS トークンの形式は、HTTPS プロトコルや AMQP プロトコルの場合と同じです。
SharedAccessSignature sr={URL-encoded-resourceURI}&sig={signature-string}&se={expiry}&skn=registration
ResourceURI は{idScope}/registrations/{registration_id}
の形式にする必要があります。 ポリシー名 (skn
) は、registration
に設定する必要があります。Note
X.509 証明書の認証を使用する場合は、SAS トークン パスワードは不要です。
SAS トークンの生成方法について詳しくは、DPS へのアクセス制御に関するページにあるセキュリティ トークンのセクションをご覧ください。
DPS 実装固有の動作を以下のリストに示します。
DPS では、永続的なセッションはサポートされていません。 CleanSession フラグの値に関係なく、すべてのセッションは非永続的として扱われます。 CleanSession を true に設定することをお勧めします。
デバイス アプリが QoS 2 を使用してトピックをサブスクライブしている場合、DPS は SUBACK パケットに最大の QoS レベル 1 を許可します。 その後、DPS は QoS 1 を使用してデバイスにメッセージを配信します。
TLS または SSL の構成
MQTT プロトコルを直接使用するには、クライアントは TLS 1.2 経由で接続する必要があります。 この手順をスキップすると、接続エラーで失敗します。
デバイスの登録
DPS 経由でデバイスを登録するには、デバイスで $dps/registrations/res/#
をトピック フィルターとして使用してサブスクライブする必要があります。 トピック フィルター内の複数レベルのワイルドカード #
は、デバイスがトピック名のその他のプロパティを受信できるようにするためにのみ使用されます。 DPS では、#
または ?
ワイルドカードを使用してサブトピックをフィルター処理できません。 DPS はパブリッシャーとサブスクライバー間の汎用メッセージング ブローカーではないため、ドキュメント化されたトピック名とトピック フィルターのみがサポートされます。
デバイスでは、$dps/registrations/PUT/iotdps-register/?$rid={request_id}
をトピック名として使用して、DPS に登録メッセージを発行する必要があります。 ペイロードには、JSON 形式のデバイス登録オブジェクトを含める必要があります。
成功するシナリオでは、$dps/registrations/res/202/?$rid={request_id}&retry-after=x
トピック名に対する応答がデバイスで受信されます。ここで、x は再試行後の値 (秒) です。
登録操作の状態のポーリング
デバイス登録操作の結果を受け取るため、デバイスで定期的にサービスをポーリングする必要があります。 デバイスが $dps/registrations/res/#
のトピックを既にサブスクライブしている場合、get operation status メッセージを $dps/registrations/GET/iotdps-get-operationstatus/?$rid={request_id}&operationId={operationId}
トピック名に発行できます。 このメッセージの操作 ID は、前の手順で RegistrationOperationStatus 応答メッセージで受信した値である必要があります。 成功した場合、サービスが $dps/registrations/res/200/?$rid={request_id}
のトピックで応答するようになります。 応答のペイロードには、RegistrationOperationStatus オブジェクトが含まれます。 retry-after 期間と同じ遅延の後に応答コードが 202 の場合、デバイスでサービスのポーリングを続行する必要があります。 サービスで状態コード 200 が返された場合は、デバイス登録操作は正常に実行されています。
WebSocket 経由の接続
WebSocket 経由で接続する場合は、mqtt
としてサブプロトコルを指定します。 RFC 6455 に従います。
次のステップ
MQTT プロトコルについて詳しくは、MQTT のドキュメントをご覧ください。
サンプル MQTT コードを参照するには、MQTT アプリケーションのサンプルに関するページを参照してください。
DPS の機能を詳しく調べるには、次のリンクを使用してください。